Re: [PATCH drm-next 1/2] vmalloc: Add atomic_vmap

2025-03-09 Thread Ryosuke Yasuoka
On Fri, Mar 7, 2025 at 4:55 PM Jocelyn Falempe  wrote:
>
> On 06/03/2025 16:52, Simona Vetter wrote:
> > On Thu, Mar 06, 2025 at 02:24:51PM +0100, Jocelyn Falempe wrote:
> >> On 06/03/2025 05:52, Matthew Wilcox wrote:
> >>> On Thu, Mar 06, 2025 at 12:25:53AM +0900, Ryosuke Yasuoka wrote:
>  Some drivers can use vmap in drm_panic, however, vmap is sleepable and
>  takes locks. Since drm_panic will vmap in panic handler, atomic_vmap
>  requests pages with GFP_ATOMIC and maps KVA without locks and sleep.
> >>>
> >>> In addition to the implicit GFP_KERNEL allocations Vlad mentioned, how
> >>> is this supposed to work?
> >>>
>  +  vn = addr_to_node(va->va_start);
>  +
>  +  insert_vmap_area(va, &vn->busy.root, &vn->busy.head);
> >>>
> >>> If someone else is holding the vn->busy.lock because they're modifying the
> >>> busy tree, you'll corrupt the tree.  You can't just say "I can't take a
> >>> lock here, so I won't bother".  You need to figure out how to do something
> >>> safe without taking the lock.  For example, you could preallocate the
> >>> page tables and reserve a vmap area when the driver loads that would
> >>> then be usable for the panic situation.  I don't know that we have APIs
> >>> to let you do that today, but it's something that could be added.
> >>>
> >> Regarding the lock, it should be possible to use the trylock() variant, and
> >> fail if the lock is already taken. (In the panic handler, only 1 CPU remain
> >> active, so it's unlikely the lock would be released anyway).
> >>
> >> If we need to pre-allocate the page table and reserve the vmap area, maybe
> >> it would be easier to just always vmap() the primary framebuffer, so it can
> >> be used in the panic handler?
> >
> > Yeah I really don't like the idea of creating some really brittle one-off
> > core mm code just so we don't have to vmap a buffer unconditionally. I
> > think even better would be if drm_panic can cope with non-linear buffers,
> > it's entirely fine if the drawing function absolutely crawls and sets each
> > individual byte ...
>
> It already supports some non-linear buffer, like Nvidia block-linear:
> https://elixir.bootlin.com/linux/v6.13.5/source/drivers/gpu/drm/nouveau/dispnv50/wndw.c#L606
>
> And I've also sent some patches to support Intel's 4-tile and Y-tile format:
> https://patchwork.freedesktop.org/patch/637200/?series=141936&rev=5
> https://patchwork.freedesktop.org/patch/637202/?series=141936&rev=5
>
> Hopefully Color Compression can be disabled on intel's GPU, otherwise
> that would be a bit harder to implement than tiling.
>
> >
> > The only thing you're allowed to do in panic is try_lock on a raw spinlock
> > (plus some really scare lockless tricks), imposing that on core mm sounds
> > like a non-starter to me.
> >
> > Cheers, Sima
>

Thank you all for your comments.
I understand adding atomic_vmap is not possible as vmalloc is not compatible
with GFP_ATOMIC. I'll re-implement this by pre-allocating the page table and
reserve the vmap area while the kernel is alive. It'll might be
allocated in driver
codes so maybe I don't need to add any features in core mm code.

Best regards,
Ryosuke




[PATCH 1/4] drm/display: hdmi: provide central data authority for ACR params

2025-03-09 Thread Dmitry Baryshkov
From: Dmitry Baryshkov 

HDMI standard defines recommended N and CTS values for Audio Clock
Regeneration. Currently each driver implements those, frequently in
somewhat unique way. Provide a generic helper for getting those values
to be used by the HDMI drivers.

The helper is added to drm_hdmi_helper.c rather than drm_hdmi_audio.c
since HDMI drivers can be using this helper function even without
switching to DRM HDMI Audio helpers.

Note: currently this only handles the values per HDMI 1.4b Section 7.2
and HDMI 2.0 Section 9.2.1. Later the table can be expanded to
accommodate for Deep Color TMDS char rates per HDMI 1.4 Appendix D
and/or HDMI 2.0 / 2.1 Appendix C).

Signed-off-by: Dmitry Baryshkov 
---
 drivers/gpu/drm/display/drm_hdmi_helper.c | 164 ++
 include/drm/display/drm_hdmi_helper.h |   6 ++
 2 files changed, 170 insertions(+)

diff --git a/drivers/gpu/drm/display/drm_hdmi_helper.c 
b/drivers/gpu/drm/display/drm_hdmi_helper.c
index 
74dd4d01dd9bb2c9e69ec1c60b0056bd69417e8a..89d25571bfd21c56c6835821d2272a12c816a76e
 100644
--- a/drivers/gpu/drm/display/drm_hdmi_helper.c
+++ b/drivers/gpu/drm/display/drm_hdmi_helper.c
@@ -256,3 +256,167 @@ drm_hdmi_compute_mode_clock(const struct drm_display_mode 
*mode,
return DIV_ROUND_CLOSEST_ULL(clock * bpc, 8);
 }
 EXPORT_SYMBOL(drm_hdmi_compute_mode_clock);
+
+struct drm_hdmi_acr_n_cts_entry {
+   unsigned int n;
+   unsigned int cts;
+};
+
+struct drm_hdmi_acr_data {
+   unsigned long tmds_clock_khz;
+   struct drm_hdmi_acr_n_cts_entry n_cts_32k,
+   n_cts_44k1,
+   n_cts_48k;
+};
+
+static const struct drm_hdmi_acr_data hdmi_acr_n_cts[] = {
+   {
+   /* "Other" entry */
+   .n_cts_32k =  { .n = 4096, },
+   .n_cts_44k1 = { .n = 6272, },
+   .n_cts_48k =  { .n = 6144, },
+   }, {
+   .tmds_clock_khz = 25175,
+   .n_cts_32k =  { .n = 4576,  .cts = 28125, },
+   .n_cts_44k1 = { .n = 7007,  .cts = 31250, },
+   .n_cts_48k =  { .n = 6864,  .cts = 28125, },
+   }, {
+   .tmds_clock_khz = 25200,
+   .n_cts_32k =  { .n = 4096,  .cts = 25200, },
+   .n_cts_44k1 = { .n = 6272,  .cts = 28000, },
+   .n_cts_48k =  { .n = 6144,  .cts = 25200, },
+   }, {
+   .tmds_clock_khz = 27000,
+   .n_cts_32k =  { .n = 4096,  .cts = 27000, },
+   .n_cts_44k1 = { .n = 6272,  .cts = 3, },
+   .n_cts_48k =  { .n = 6144,  .cts = 27000, },
+   }, {
+   .tmds_clock_khz = 27027,
+   .n_cts_32k =  { .n = 4096,  .cts = 27027, },
+   .n_cts_44k1 = { .n = 6272,  .cts = 30030, },
+   .n_cts_48k =  { .n = 6144,  .cts = 27027, },
+   }, {
+   .tmds_clock_khz = 54000,
+   .n_cts_32k =  { .n = 4096,  .cts = 54000, },
+   .n_cts_44k1 = { .n = 6272,  .cts = 6, },
+   .n_cts_48k =  { .n = 6144,  .cts = 54000, },
+   }, {
+   .tmds_clock_khz = 54054,
+   .n_cts_32k =  { .n = 4096,  .cts = 54054, },
+   .n_cts_44k1 = { .n = 6272,  .cts = 60060, },
+   .n_cts_48k =  { .n = 6144,  .cts = 54054, },
+   }, {
+   .tmds_clock_khz = 74176,
+   .n_cts_32k =  { .n = 11648, .cts = 210937, }, /* and 210938 */
+   .n_cts_44k1 = { .n = 17836, .cts = 234375, },
+   .n_cts_48k =  { .n = 11648, .cts = 140625, },
+   }, {
+   .tmds_clock_khz = 74250,
+   .n_cts_32k =  { .n = 4096,  .cts = 74250, },
+   .n_cts_44k1 = { .n = 6272,  .cts = 82500, },
+   .n_cts_48k =  { .n = 6144,  .cts = 74250, },
+   }, {
+   .tmds_clock_khz = 148352,
+   .n_cts_32k =  { .n = 11648, .cts = 421875, },
+   .n_cts_44k1 = { .n = 8918,  .cts = 234375, },
+   .n_cts_48k =  { .n = 5824,  .cts = 140625, },
+   }, {
+   .tmds_clock_khz = 148500,
+   .n_cts_32k =  { .n = 4096,  .cts = 148500, },
+   .n_cts_44k1 = { .n = 6272,  .cts = 165000, },
+   .n_cts_48k =  { .n = 6144,  .cts = 148500, },
+   }, {
+   .tmds_clock_khz = 296703,
+   .n_cts_32k =  { .n = 5824,  .cts = 421875, },
+   .n_cts_44k1 = { .n = 4459,  .cts = 234375, },
+   .n_cts_48k =  { .n = 5824,  .cts = 281250, },
+   }, {
+   .tmds_clock_khz = 297000,
+   .n_cts_32k =  { .n = 3072,  .cts = 222750, },
+   .n_cts_44k1 = { .n = 4704,  .cts = 247500, },
+   .n_cts_48k =  { .n = 5120,  .cts = 247500, },
+   }, {
+   .tmds_clock_khz = 593407,
+   .n_cts_32k =  { .n = 5824,  .cts = 843750, },
+   .n_cts_44k1 = { .n = 8918,  .cts = 937500, },
+   

[PATCH 4/4] drm: bridge: dw-hdmi: use new helper to get ACR values

2025-03-09 Thread Dmitry Baryshkov
From: Dmitry Baryshkov 

Use drm_hdmi_acr_get_n_cts() helper instead of calculating N and CTS
values in the DW-HDMI driver.

Signed-off-by: Dmitry Baryshkov 
---
 drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 90 +++
 1 file changed, 8 insertions(+), 82 deletions(-)

diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c 
b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
index 
0890add5f7070f13fefad923526e92f516f06764..b8775e677233ca96c2d4a06fb5697aa3c0bd45c3
 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
@@ -558,68 +558,6 @@ static void hdmi_set_cts_n(struct dw_hdmi *hdmi, unsigned 
int cts,
hdmi_writeb(hdmi, n & 0xff, HDMI_AUD_N1);
 }
 
-static unsigned int hdmi_compute_n(unsigned int freq, unsigned long pixel_clk)
-{
-   unsigned int n = (128 * freq) / 1000;
-   unsigned int mult = 1;
-
-   while (freq > 48000) {
-   mult *= 2;
-   freq /= 2;
-   }
-
-   switch (freq) {
-   case 32000:
-   if (pixel_clk == 25175000)
-   n = 4576;
-   else if (pixel_clk == 27027000)
-   n = 4096;
-   else if (pixel_clk == 74176000 || pixel_clk == 148352000)
-   n = 11648;
-   else if (pixel_clk == 29700)
-   n = 3072;
-   else
-   n = 4096;
-   n *= mult;
-   break;
-
-   case 44100:
-   if (pixel_clk == 25175000)
-   n = 7007;
-   else if (pixel_clk == 74176000)
-   n = 17836;
-   else if (pixel_clk == 148352000)
-   n = 8918;
-   else if (pixel_clk == 29700)
-   n = 4704;
-   else
-   n = 6272;
-   n *= mult;
-   break;
-
-   case 48000:
-   if (pixel_clk == 25175000)
-   n = 6864;
-   else if (pixel_clk == 27027000)
-   n = 6144;
-   else if (pixel_clk == 74176000)
-   n = 11648;
-   else if (pixel_clk == 148352000)
-   n = 5824;
-   else if (pixel_clk == 29700)
-   n = 5120;
-   else
-   n = 6144;
-   n *= mult;
-   break;
-
-   default:
-   break;
-   }
-
-   return n;
-}
-
 /*
  * When transmitting IEC60958 linear PCM audio, these registers allow to
  * configure the channel status information of all the channel status
@@ -646,32 +584,20 @@ static void hdmi_set_clk_regenerator(struct dw_hdmi *hdmi,
unsigned long ftdms = pixel_clk;
unsigned int n, cts;
u8 config3;
-   u64 tmp;
 
-   n = hdmi_compute_n(sample_rate, pixel_clk);
+   drm_hdmi_acr_get_n_cts(ftdms, sample_rate, &n, &cts);
 
config3 = hdmi_readb(hdmi, HDMI_CONFIG3_ID);
 
/* Compute CTS when using internal AHB audio or General Parallel audio*/
-   if ((config3 & HDMI_CONFIG3_AHBAUDDMA) || (config3 & 
HDMI_CONFIG3_GPAUD)) {
-   /*
-* Compute the CTS value from the N value.  Note that CTS and N
-* can be up to 20 bits in total, so we need 64-bit math.  Also
-* note that our TDMS clock is not fully accurate; it is
-* accurate to kHz.  This can introduce an unnecessary remainder
-* in the calculation below, so we don't try to warn about that.
-*/
-   tmp = (u64)ftdms * n;
-   do_div(tmp, 128 * sample_rate);
-   cts = tmp;
-
-   dev_dbg(hdmi->dev, "%s: fs=%uHz ftdms=%lu.%03luMHz N=%d 
cts=%d\n",
-   __func__, sample_rate,
-   ftdms / 100, (ftdms / 1000) % 1000,
-   n, cts);
-   } else {
+   if (!(config3 & HDMI_CONFIG3_AHBAUDDMA) &&
+   !(config3 & HDMI_CONFIG3_GPAUD))
cts = 0;
-   }
+
+   dev_dbg(hdmi->dev, "%s: fs=%uHz ftdms=%lu.%03luMHz N=%d cts=%d\n",
+   __func__, sample_rate,
+   ftdms / 100, (ftdms / 1000) % 1000,
+   n, cts);
 
spin_lock_irq(&hdmi->audio_lock);
hdmi->audio_n = n;

-- 
2.39.5



[PATCH v2] fbdev: fsl-diu-fb: add missing device_remove_file()

2025-03-09 Thread Shixiong Ou
From: Shixiong Ou 

Call device_remove_file() when driver remove.

Signed-off-by: Shixiong Ou 
---
v1->v2:
add has_sysfs_attrs flag.

 drivers/video/fbdev/fsl-diu-fb.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/video/fbdev/fsl-diu-fb.c b/drivers/video/fbdev/fsl-diu-fb.c
index 5ac8201c3533..57f7fe6a4c76 100644
--- a/drivers/video/fbdev/fsl-diu-fb.c
+++ b/drivers/video/fbdev/fsl-diu-fb.c
@@ -384,6 +384,7 @@ struct fsl_diu_data {
__le16 next_cursor[MAX_CURS * MAX_CURS] __aligned(32);
uint8_t edid_data[EDID_LENGTH];
bool has_edid;
+   bool has_dev_attr;
 } __aligned(32);
 
 /* Determine the DMA address of a member of the fsl_diu_data structure */
@@ -1809,6 +1810,7 @@ static int fsl_diu_probe(struct platform_device *pdev)
data->dev_attr.attr.name);
}
 
+   data->has_dev_attr = true;
dev_set_drvdata(&pdev->dev, data);
return 0;
 
@@ -1827,6 +1829,10 @@ static void fsl_diu_remove(struct platform_device *pdev)
int i;
 
data = dev_get_drvdata(&pdev->dev);
+
+   if (data->has_dev_attr)
+   device_remove_file(&pdev->dev, &data->dev_attr);
+
disable_lcdc(&data->fsl_diu_info[0]);
 
free_irq(data->irq, data->diu_reg);
-- 
2.43.0



Re: [PATCH] drm/msm/dpu: reorder pointer operations after sanity checks to avoid NULL deref

2025-03-09 Thread Dmitry Baryshkov
On Sat, Mar 08, 2025 at 02:48:39PM +, Qasim Ijaz wrote:
> _dpu_encoder_trigger_start dereferences "struct dpu_encoder_phys *phys" 
> before the sanity checks which can lead to a NULL pointer dereference if 
> phys is NULL. 
> 
> Fix this by reordering the dereference after the sanity checks.
> 
> Signed-off-by: Qasim Ijaz 
> Fixes: 8144d17a81d9 ("drm/msm/dpu: Skip trigger flush and start for CWB")

Your SoB should be the last tag. Fixes comes before it.

> ---
>  drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c 
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> index 0eed93a4d056..ba8b2a163232 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> @@ -1667,8 +1667,6 @@ static void _dpu_encoder_trigger_flush(struct 
> drm_encoder *drm_enc,
>   */
>  static void _dpu_encoder_trigger_start(struct dpu_encoder_phys *phys)
>  {
> - struct dpu_encoder_virt *dpu_enc = to_dpu_encoder_virt(phys->parent);
> -
>   if (!phys) {
>   DPU_ERROR("invalid argument(s)\n");
>   return;
> @@ -1679,6 +1677,8 @@ static void _dpu_encoder_trigger_start(struct 
> dpu_encoder_phys *phys)
>   return;
>   }
>  
> + struct dpu_encoder_virt *dpu_enc = to_dpu_encoder_virt(phys->parent);
> +

I'm not a fan of having variable defs in the middle of the code. Please
keep the def at the top and assign it here.

>   if (phys->parent->encoder_type == DRM_MODE_ENCODER_VIRTUAL &&
>   dpu_enc->cwb_mask) {
>   DPU_DEBUG("encoder %d CWB enabled, skipping\n", 
> DRMID(phys->parent));
> -- 
> 2.39.5
> 

-- 
With best wishes
Dmitry


[PATCH 0/4] drm/display: hdmi: provide common code to get Audio Clock Recovery params

2025-03-09 Thread Dmitry Baryshkov
HDMI standards define a recommended set of values to be used for Audio
Clock Regeneration. Nevertheless, each HDMI driver dealing with audio
implements its own way to determine those values. Implement a common
helper and use it for MSM HDMI (tested), VC4 and DW-HDMI (compile-tested
only) drivers.

Signed-off-by: Dmitry Baryshkov 
---
Dmitry Baryshkov (4):
  drm/display: hdmi: provide central data authority for ACR params
  drm/msm/hdmi: use new helper for ACR tables
  drm/vc4: use new helper to get ACR values
  drm: bridge: dw-hdmi: use new helper to get ACR values

 drivers/gpu/drm/bridge/synopsys/dw-hdmi.c |  90 ++--
 drivers/gpu/drm/display/drm_hdmi_helper.c | 164 ++
 drivers/gpu/drm/msm/hdmi/hdmi_audio.c | 107 ++-
 drivers/gpu/drm/vc4/vc4_hdmi.c|  10 +-
 drivers/gpu/drm/vc4/vc4_hdmi.h|   7 ++
 include/drm/display/drm_hdmi_helper.h |   6 ++
 6 files changed, 197 insertions(+), 187 deletions(-)
---
base-commit: 0a2f889128969dab41861b6e40111aa03dc57014
change-id: 20250308-drm-hdmi-acr-7ad1f0d012df

Best regards,
-- 
Dmitry Baryshkov 



[PATCH v2] drm/msm/dpu: reorder pointer operations after sanity checks to avoid NULL deref

2025-03-09 Thread Qasim Ijaz
_dpu_encoder_trigger_start dereferences "struct dpu_encoder_phys *phys"
before the sanity checks which can lead to a NULL pointer dereference if
phys is NULL.
 
Fix this by reordering the dereference after the sanity checks.
 
Fixes: 8144d17a81d9 ("drm/msm/dpu: Skip trigger flush and start for CWB")
Signed-off-by: Qasim Ijaz 
---
v2:
- Moved Signed-off tag below Fixes tag
- Moved dpu_enc declaration to the top and initialisation below sanity checks

 drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
index 0eed93a4d056..0bd1f2bfaaff 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
@@ -1667,7 +1667,7 @@ static void _dpu_encoder_trigger_flush(struct drm_encoder 
*drm_enc,
  */
 static void _dpu_encoder_trigger_start(struct dpu_encoder_phys *phys)
 {
-   struct dpu_encoder_virt *dpu_enc = to_dpu_encoder_virt(phys->parent);
+   struct dpu_encoder_virt *dpu_enc;
 
if (!phys) {
DPU_ERROR("invalid argument(s)\n");
@@ -1678,6 +1678,8 @@ static void _dpu_encoder_trigger_start(struct 
dpu_encoder_phys *phys)
DPU_ERROR("invalid pingpong hw\n");
return;
}
+
+   dpu_enc = to_dpu_encoder_virt(phys->parent);
 
if (phys->parent->encoder_type == DRM_MODE_ENCODER_VIRTUAL &&
dpu_enc->cwb_mask) {
-- 
2.39.5



[PATCH v6 2/5] rust: firmware: introduce `firmware::ModInfoBuilder`

2025-03-09 Thread Danilo Krummrich
The `firmware` field of the `module!` only accepts literal strings,
which is due to the fact that it is implemented as a proc macro.

Some drivers require a lot of firmware files (such as nova-core) and
hence benefit from more flexibility composing firmware path strings.

The `firmware::ModInfoBuilder` is a helper component to flexibly compose
firmware path strings for the .modinfo section in const context.

It is meant to be used in combination with `kernel::module_firmware!`.

Co-developed-by: Alice Ryhl 
Signed-off-by: Alice Ryhl 
Signed-off-by: Danilo Krummrich 
---
 rust/kernel/firmware.rs | 127 
 1 file changed, 127 insertions(+)

diff --git a/rust/kernel/firmware.rs b/rust/kernel/firmware.rs
index c5162fdc95ff..6008b62f2de8 100644
--- a/rust/kernel/firmware.rs
+++ b/rust/kernel/firmware.rs
@@ -115,3 +115,130 @@ unsafe impl Send for Firmware {}
 // SAFETY: `Firmware` only holds a pointer to a C `struct firmware`, 
references to which are safe to
 // be used from any thread.
 unsafe impl Sync for Firmware {}
+
+/// Builder for firmware module info.
+///
+/// [`ModInfoBuilder`] is a helper component to flexibly compose firmware 
paths strings for the
+/// .modinfo section in const context.
+///
+/// Therefore the [`ModInfoBuilder`] provides the methods 
[`ModInfoBuilder::new_entry`] and
+/// [`ModInfoBuilder::push`], where the latter is used to push path components 
and the former to
+/// mark the beginning of a new path string.
+///
+/// [`ModInfoBuilder`] is meant to be used in combination with 
`kernel::module_firmware!`.
+///
+/// The const generic `N` as well as the `module_name` parameter of 
[`ModInfoBuilder::new`] is an
+/// internal implementation detail and supplied through the above macro.
+pub struct ModInfoBuilder {
+buf: [u8; N],
+n: usize,
+module_name: &'static CStr,
+}
+
+impl ModInfoBuilder {
+/// Create an empty builder instance.
+pub const fn new(module_name: &'static CStr) -> Self {
+Self {
+buf: [0; N],
+n: 0,
+module_name,
+}
+}
+
+const fn push_internal(mut self, bytes: &[u8]) -> Self {
+let mut j = 0;
+
+if N == 0 {
+self.n += bytes.len();
+return self;
+}
+
+while j < bytes.len() {
+if self.n < N {
+self.buf[self.n] = bytes[j];
+}
+self.n += 1;
+j += 1;
+}
+self
+}
+
+/// Push an additional path component.
+///
+/// Append path components to the [`ModInfoBuilder`] instance. Paths need 
to be separated
+/// with [`ModInfoBuilder::new_entry`].
+///
+/// # Example
+///
+/// ```
+/// use kernel::firmware::ModInfoBuilder;
+///
+/// # const DIR: &str = "vendor/chip/";
+/// # const fn no_run(builder: ModInfoBuilder) {
+/// let builder = builder.new_entry()
+/// .push(DIR)
+/// .push("foo.bin")
+/// .new_entry()
+/// .push(DIR)
+/// .push("bar.bin");
+/// # }
+/// ```
+pub const fn push(self, s: &str) -> Self {
+// Check whether there has been an initial call to `next_entry()`.
+if N != 0 && self.n == 0 {
+crate::build_error!("Must call next_entry() before push().");
+}
+
+self.push_internal(s.as_bytes())
+}
+
+const fn push_module_name(self) -> Self {
+let mut this = self;
+let module_name = this.module_name;
+
+if !this.module_name.is_empty() {
+this = this.push_internal(module_name.as_bytes_with_nul());
+
+if N != 0 {
+// Re-use the space taken by the NULL terminator and swap it 
with the '.' separator.
+this.buf[this.n - 1] = b'.';
+}
+}
+
+this
+}
+
+/// Prepare the [`ModInfoBuilder`] for the next entry.
+///
+/// This method acts as a separator between module firmware path entries.
+///
+/// Must be called before constructing a new entry with subsequent calls to
+/// [`ModInfoBuilder::push`].
+///
+/// See [`ModInfoBuilder::push`] for an example.
+pub const fn new_entry(self) -> Self {
+self.push_internal(b"\0")
+.push_module_name()
+.push_internal(b"firmware=")
+}
+
+/// Build the byte array.
+pub const fn build(self) -> [u8; N] {
+// Add the final NULL terminator.
+let this = self.push_internal(b"\0");
+
+if this.n == N {
+this.buf
+} else {
+crate::build_error!("Length mismatch.");
+}
+}
+}
+
+impl ModInfoBuilder<0> {
+/// Return the length of the byte array to build.
+pub const fn build_length(self) -> usize {
+// Compensate for the NULL terminator added by `build`.
+self.n + 1
+}
+}
-- 
2.48.1



[syzbot] Monthly fbdev report (Mar 2025)

2025-03-09 Thread syzbot
Hello fbdev maintainers/developers,

This is a 31-day syzbot report for the fbdev subsystem.
All related reports/information can be found at:
https://syzkaller.appspot.com/upstream/s/fbdev

During the period, 1 new issues were detected and 0 were fixed.
In total, 7 issues are still open and 25 have already been fixed.

Some of the still happening issues:

Ref Crashes Repro Title
<1> 844 Yes   KASAN: vmalloc-out-of-bounds Write in imageblit (4)
  https://syzkaller.appspot.com/bug?extid=c4b7aa0513823e2ea880
<2> 15  Yes   KASAN: global-out-of-bounds Read in bit_putcs (3)
  https://syzkaller.appspot.com/bug?extid=793cf822d213be1a74f2
<3> 8   NoBUG: unable to handle kernel paging request in 
bitfill_aligned (4)
  https://syzkaller.appspot.com/bug?extid=66bde8e1e4161d4b2cca
<4> 7   Yes   KASAN: slab-out-of-bounds Read in fbcon_prepare_logo
  https://syzkaller.appspot.com/bug?extid=0c815b25cdb3678e7083

---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkal...@googlegroups.com.

To disable reminders for individual bugs, reply with the following command:
#syz set  no-reminders

To change bug's subsystems, reply with:
#syz set  subsystems: new-subsystem

You may send multiple commands in a single email message.


Re: [PATCH 1/1] fbdev: hyperv_fb: Fix hang in kdump kernel when on Hyper-V Gen 2 VMs

2025-03-09 Thread Helge Deller

On 3/9/25 05:10, Michael Kelley wrote:

From: Helge Deller  Sent: Saturday, March 8, 2025 6:59 PM


On 2/19/25 00:01, mhkelle...@gmail.com wrote:

From: Michael Kelley 


[snip]



Reported-by: Thomas Tai 
Fixes: c25a19afb81c ("fbdev/hyperv_fb: Do not clear global screen_info")
Signed-off-by: Michael Kelley 
---
The "Fixes" tag uses commit c25a19afb81c because that's where the problem
was re-exposed, and how far back a stable backport is needed. But I've
taken a completely different, and hopefully better, approach in the
solution that isn't related to the code changes in c25a19afb81c.

   drivers/video/fbdev/hyperv_fb.c | 20 +---
   1 file changed, 13 insertions(+), 7 deletions(-)


applied to fbdev tree.



Thank you!

Related, I noticed the patch "fbdev: hyperv_fb: iounmap() the correct
memory when removing a device" is also in the fbdev for-next branch.
Wei Liu previously applied this patch to the hyperv-fixes tree (see [1])
and it's already in linux-next. Won't having it also in fbdev produce a
merge conflict?
[1] 
https://lore.kernel.org/linux-hyperv/Z6wHDw8BssJyQHiM@liuwe-devbox-debian-v2/


Thanks Michael!
I now dropped that patch from the fbdev tree to avoid collisions.

Btw, I'm fine if we agree that all hyperv-fbdev fixes & patches go through
hyperv or other trees. Just let me know.

Helge


Re: [PATCH v3 00/16] Introduce and use generic parity16/32/64 helper

2025-03-09 Thread Jiri Slaby

On 09. 03. 25, 16:48, Kuan-Wei Chiu wrote:

Would this work for everyone?


+1 for /me.

--
js
suse labs


Re: [PATCH v6 0/5] Initial Nova Core series

2025-03-09 Thread Danilo Krummrich
On Thu, Mar 06, 2025 at 11:23:26PM +0100, Danilo Krummrich wrote:
> This is the initial series for the nova-core stub driver.

Applied to nova-next, thanks!


[PATCH RESEND 0/2] Refactoring the fbcon packed pixel drawing routines

2025-03-09 Thread Zsolt Kajtar
This is the same patch as before just updated to latest fbdev
master and with better description. And hopefully sent intact this
time.

Zsolt Kajtar (2):
  Refactoring the fbcon packed pixel drawing routines
  Adding contact info for packed pixel drawing

 MAINTAINERS |  16 +
 drivers/video/fbdev/core/Kconfig|  10 +-
 drivers/video/fbdev/core/cfbcopyarea.c  | 428 +---
 drivers/video/fbdev/core/cfbfillrect.c  | 362 +
 drivers/video/fbdev/core/cfbimgblt.c| 357 +
 drivers/video/fbdev/core/cfbmem.h   |  43 ++
 drivers/video/fbdev/core/fb_copyarea.h  | 405 +++
 drivers/video/fbdev/core/fb_draw.h  | 274 ++---
 drivers/video/fbdev/core/fb_fillrect.h  | 280 ++
 drivers/video/fbdev/core/fb_imageblit.h | 495 
 drivers/video/fbdev/core/syscopyarea.c  | 369 +-
 drivers/video/fbdev/core/sysfillrect.c  | 324 +---
 drivers/video/fbdev/core/sysimgblt.c| 333 +---
 drivers/video/fbdev/core/sysmem.h   |  39 ++
 14 files changed, 1480 insertions(+), 2255 deletions(-)
 create mode 100644 drivers/video/fbdev/core/cfbmem.h
 create mode 100644 drivers/video/fbdev/core/fb_copyarea.h
 create mode 100644 drivers/video/fbdev/core/fb_fillrect.h
 create mode 100644 drivers/video/fbdev/core/fb_imageblit.h
 create mode 100644 drivers/video/fbdev/core/sysmem.h

-- 
2.30.2



[PATCH RESEND 1/2] Refactoring the fbcon packed pixel drawing routines

2025-03-09 Thread Zsolt Kajtar
The original version duplicated more or less the same algorithms for
both system and i/o memory.

In this version the drawing algorithms (copy/fill/blit) are separate
from the memory access (system and i/o). The two parts are getting
combined in the loadable module sources. This also makes it more robust
against wrong memory access type or alignment mistakes as there's no
direct pointer access or arithmetic in the algorithm sources anymore.

Due to liberal use of inlining the compiled result is a single function
in all 6 cases, without unnecessary function calls. Unlike earlier the
use of macros could be minimized as apparently both gcc and clang is
capable now to do the same with inline functions just as well.

What wasn't quite the same in the two variants is the support for pixel
order reversing. This version is capable to do that for both system and
I/O memory, and not only for the latter. As demand for low bits per
pixel modes isn't high there's a configuration option to enable this
separately for the CFB and SYS modules.

The pixel reversing algorithm is different than earlier and was designed
so that it can take advantage of bit order reversing instructions on
architectures which have them. And even for higher bits per pixel modes
like four bpp.

One of the shortcomings of the earlier version was the incomplete
support for foreign endian framebuffers. Now all three drawing
algorithms produce correct output on both endians with native and
foreign framebuffers. This is one of the important differences even if
otherwise the algorithms don't look too different than before.

All three routines work now with aligned native word accesses. As a
consequence blitting isn't limited to 32 bits on 64 bit architectures as
it was before.

The old routines silently assumed that rows are a multiple of the word
size. Due to how the new routines function this isn't a requirement any
more and access will be done aligned regardless. However if the
framebuffer is configured like that then some of the fast paths won't be
available.

As this code is supposed to be running on all supported architectures it
wasn't optimized for a particular one. That doesn't mean I haven't
looked at the disassembly. That's where I noticed that it isn't a good
idea to use the fallback bitreversing code for example.

The low bits per pixel modes should be faster than before as the new
routines can blit 4 pixels at a time.

On the higher bits per pixel modes I retained the specialized aligned
routines so it should be more or less the same, except on 64 bit
architectures. There the blitting word size is double now which means 32
BPP isn't done a single pixel a time now.

The code was tested on x86, amd64, mips32 and mips64. The latter two in
big endian configuration. Originally thought I can get away with the
first two, but with such bit twisting code byte ordering is tricky and
not really possible to get right without actually verifying it.

While writing such routines isn't rocket science a lot of time was spent
on making sure that pixel ordering, foreign byte order, various bits per
pixels, cpu endianness and word size will give the expected result in
all sorts of combinations without making it overly complicated or full
with special cases.

Signed-off-by: Zsolt Kajtar 
---
 drivers/video/fbdev/core/Kconfig|  10 +-
 drivers/video/fbdev/core/cfbcopyarea.c  | 428 +---
 drivers/video/fbdev/core/cfbfillrect.c  | 362 +
 drivers/video/fbdev/core/cfbimgblt.c| 357 +
 drivers/video/fbdev/core/cfbmem.h   |  43 ++
 drivers/video/fbdev/core/fb_copyarea.h  | 405 +++
 drivers/video/fbdev/core/fb_draw.h  | 274 ++---
 drivers/video/fbdev/core/fb_fillrect.h  | 280 ++
 drivers/video/fbdev/core/fb_imageblit.h | 495 
 drivers/video/fbdev/core/syscopyarea.c  | 369 +-
 drivers/video/fbdev/core/sysfillrect.c  | 324 +---
 drivers/video/fbdev/core/sysimgblt.c| 333 +---
 drivers/video/fbdev/core/sysmem.h   |  39 ++
 13 files changed, 1464 insertions(+), 2255 deletions(-)
 create mode 100644 drivers/video/fbdev/core/cfbmem.h
 create mode 100644 drivers/video/fbdev/core/fb_copyarea.h
 create mode 100644 drivers/video/fbdev/core/fb_fillrect.h
 create mode 100644 drivers/video/fbdev/core/fb_imageblit.h
 create mode 100644 drivers/video/fbdev/core/sysmem.h

diff --git a/drivers/video/fbdev/core/Kconfig b/drivers/video/fbdev/core/Kconfig
index d554d8c54..4abe12db7 100644
--- a/drivers/video/fbdev/core/Kconfig
+++ b/drivers/video/fbdev/core/Kconfig
@@ -69,7 +69,7 @@ config FB_CFB_REV_PIXELS_IN_BYTE
bool
depends on FB_CORE
help
- Allow generic frame-buffer functions to work on displays with 1, 2
+ Allow I/O memory frame-buffer functions to work on displays with 1, 2
  and 4 bits per pixel depths which has opposite order of pixels in
  byte order to

[pull] drm/msm: drm-msm-next-2025-03-09 for v6.15

2025-03-09 Thread Rob Clark
Hi Dave, Simona,

Pull for v6.15, as described below.

The following changes since commit 72d0af4accd965dc32f504440d74d0a4d18bf781:

  drm/msm/dp: Add support for LTTPR handling (2025-02-25 18:34:14 +0200)

are available in the Git repository at:

  https://gitlab.freedesktop.org/drm/msm.git tags/drm-msm-next-2025-03-09

for you to fetch changes up to 83ee6d2ec52f1378f3473ee8657d559bebdbda44:

  dt-bindings: display/msm: dsi-controller-main: Add missing minItems
(2025-03-08 03:06:00 +0200)


Updates for v6.15

GPU:
- Fix obscure GMU suspend failure
- Expose syncobj timeline support
- Extend GPU devcoredump with pagetable info
- a623 support
- Fix a6xx gen1/gen2 indexed-register blocks in gpu snapshot / devcoredump

Display:
- Add cpu-cfg interconnect paths on SM8560 and SM8650
- Introduce KMS OMMU fault handler, causing devcoredump snapshot
- Fixed error pointer dereference in msm_kms_init_aspace()

DPU:
- Fix mode_changing handling
- Add writeback support on SM6150 (QCS615)
- Fix DSC programming in 1:1:1 topology
- Reworked hardware resource allocation, moving it to the CRTC code
- Enabled support for Concurrent WriteBack (CWB) on SM8650
- Enabled CDM blocks on all relevant platforms
- Reworked debugfs interface for BW/clocks debugging
- Clear perf params before calculating bw
- Support YUV formats on writeback
- Fixed double inclusion
- Fixed writeback in YUV formats when using cloned output, Dropped
  wb2_formats_rgb
- Corrected dpu_crtc_check_mode_changed and struct dpu_encoder_virt
  kerneldocs
- Fixed uninitialized variable in dpu_crtc_kickoff_clone_mode()

DSI:
- DSC-related fixes
- Rework clock programming

DSI PHY:
- Fix 7nm (and lower) PHY programming
- Add proper DT schema definitions for DSI PHY clocks

HDMI:
- Rework the driver, enabling the use of the HDMI Connector framework

Bindings:
- Added eDP PHY on SA8775P

Misc:
- mailmap/MAINTAINERS: update Dmitry's email addr


Abhinav Kumar (5):
  drm/msm: register a fault handler for display mmu faults
  drm/msm/iommu: rename msm_fault_handler to msm_gpu_fault_handler
  drm/msm/iommu: introduce msm_iommu_disp_new() for msm_kms
  drm/msm: switch msm_kms to use msm_iommu_disp_new()
  drm/msm/dpu: rate limit snapshot capture for mmu faults

Akhil P Oommen (1):
  drm/msm/a6xx: Fix stale rpmh votes from GPU

Dan Carpenter (3):
  drm/msm/gem: Fix error code msm_parse_deps()
  drm/msm/dpu: fix error pointer dereference in msm_kms_init_aspace()
  drm/msm/dpu: Fix uninitialized variable in dpu_crtc_kickoff_clone_mode()

Dmitry Baryshkov (32):
  drm/msm/dpu: don't use active in atomic_check()
  drm/msm/dpu: move needs_cdm setting to dpu_encoder_get_topology()
  drm/msm/dpu: simplify dpu_encoder_get_topology() interface
  drm/msm/dpu: don't set crtc_state->mode_changed from atomic_check()
  drm/msm/dpu: fill CRTC resources in dpu_crtc.c
  drm/msm/dpu: move resource allocation to CRTC
  drm/msm/dpu: switch RM to use crtc_id rather than enc_id for allocation
  drm/msm/hdmi: switch to atomic bridge callbacks
  drm/msm/hdmi: program HDMI timings during atomic_pre_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
  drm/msm/hdmi: use DRM HDMI Audio framework
  drm/msm/dpu: rename CDM block definition
  drm/msm/dpu: enable CDM_0 for DPUs 5.x+
  drm/msm/dpu: enable CDM_0 for DPUs 1.x - 4.x
  drm/msm/dpu: enable CDM_0 for SC8280XP platform
  drm/msm/dpu: enable CDM_0 for X Elite platform
  drm/msm/dpu: extract bandwidth aggregation function
  drm/msm/dpu: remove duplicate code calculating sum of bandwidths
  drm/msm/dpu: change ib values to u32
  drm/msm/dpu: make fix_core_ab_vote consistent with fix_core_ib_vote
  drm/msm/dpu: also use KBps for bw_ctl output
  drm/msm/dpu: rename average bandwidth-related debugfs files
  drm/msm/dpu: drop core_clk_rate overrides from _dpu_core_perf_calc_crtc
  drm/msm/dpu: handle perf mode in _dpu_core_perf_crtc_update_bus()
  MAINTAINERS: use kernel.org alias
  mailmap: remap all addresses to kernel.org alias
  drm/msm/dpu: correct dpu_crtc_check_mode_changed docs
  drm/msm/dpu: correct struct dpu_encoder_virt docs
  drm/msm/dpu: drop wb2_formats_rgb

Eugene Lepshy (1):
  drm/msm/dsi: Allow values of 10 and 12 for bits per component

Fange Zhang (1):
  drm/msm/dpu: Add writeback support for SM6150

Haoxiang Li (1):
  drm/msm/dsi: Add check for devm_kstrdup()

Jessica Zhang (14):
  drm/msm/dpu: Add CWB to msm_display_topology
  drm/msm/dpu: Require modeset if clone mode status changes
  drm/msm/dpu: Fail atomic_check if multiple outp

Re: [PATCH v3 00/16] Introduce and use generic parity16/32/64 helper

2025-03-09 Thread Kuan-Wei Chiu
On Fri, Mar 07, 2025 at 12:07:02PM -0800, H. Peter Anvin wrote:
> On March 7, 2025 11:53:10 AM PST, David Laight  
> wrote:
> >On Fri, 07 Mar 2025 11:30:35 -0800
> >"H. Peter Anvin"  wrote:
> >
> >> On March 7, 2025 10:49:56 AM PST, Andrew Cooper 
> >>  wrote:
> >> >> (int)true most definitely is guaranteed to be 1.  
> >> >
> >> >That's not technically correct any more.
> >> >
> >> >GCC has introduced hardened bools that intentionally have bit patterns
> >> >other than 0 and 1.
> >> >
> >> >https://gcc.gnu.org/gcc-14/changes.html
> >> >
> >> >~Andrew  
> >> 
> >> Bit patterns in memory maybe (not that I can see the Linux kernel using 
> >> them) but
> >> for compiler-generated conversations that's still a given, or the manager 
> >> isn't C
> >> or anything even remotely like it.
> >> 
> >
> >The whole idea of 'bool' is pretty much broken by design.
> >The underlying problem is that values other than 'true' and 'false' can
> >always get into 'bool' variables.
> >
> >Once that has happened it is all fubar.
> >
> >Trying to sanitise a value with (say):
> >int f(bool v)
> >{
> > return (int)v & 1;
> >}
> >just doesn't work (see https://www.godbolt.org/z/MEndP3q9j)
> >
> >I really don't see how using (say) 0xaa and 0x55 helps.
> >What happens if the value is wrong? a trap or exception?, good luck 
> >recovering
> >from that.
> >
> > David
> 
> Did you just discover GIGO?

Thanks for all the suggestions.

I don't have a strong opinion on the naming or return type. I'm still a
bit confused about whether I can assume that casting bool to int always
results in 0 or 1.

If that's the case, since most people prefer bool over int as the
return type and some are against introducing u1, my current plan is to
use the following in the next version:

bool parity_odd(u64 val);

This keeps the bool return type, renames the function for better
clarity, and avoids extra maintenance burden by having just one
function.

If I can't assume that casting bool to int always results in 0 or 1,
would it be acceptable to keep the return type as int?

Would this work for everyone?

Regards,
Kuan-Wei


Re: [PATCH v3 00/16] Introduce and use generic parity16/32/64 helper

2025-03-09 Thread H. Peter Anvin
On March 9, 2025 8:48:26 AM PDT, Kuan-Wei Chiu  wrote:
>On Fri, Mar 07, 2025 at 12:07:02PM -0800, H. Peter Anvin wrote:
>> On March 7, 2025 11:53:10 AM PST, David Laight 
>>  wrote:
>> >On Fri, 07 Mar 2025 11:30:35 -0800
>> >"H. Peter Anvin"  wrote:
>> >
>> >> On March 7, 2025 10:49:56 AM PST, Andrew Cooper 
>> >>  wrote:
>> >> >> (int)true most definitely is guaranteed to be 1.  
>> >> >
>> >> >That's not technically correct any more.
>> >> >
>> >> >GCC has introduced hardened bools that intentionally have bit patterns
>> >> >other than 0 and 1.
>> >> >
>> >> >https://gcc.gnu.org/gcc-14/changes.html
>> >> >
>> >> >~Andrew  
>> >> 
>> >> Bit patterns in memory maybe (not that I can see the Linux kernel using 
>> >> them) but
>> >> for compiler-generated conversations that's still a given, or the manager 
>> >> isn't C
>> >> or anything even remotely like it.
>> >> 
>> >
>> >The whole idea of 'bool' is pretty much broken by design.
>> >The underlying problem is that values other than 'true' and 'false' can
>> >always get into 'bool' variables.
>> >
>> >Once that has happened it is all fubar.
>> >
>> >Trying to sanitise a value with (say):
>> >int f(bool v)
>> >{
>> >return (int)v & 1;
>> >}
>> >just doesn't work (see https://www.godbolt.org/z/MEndP3q9j)
>> >
>> >I really don't see how using (say) 0xaa and 0x55 helps.
>> >What happens if the value is wrong? a trap or exception?, good luck 
>> >recovering
>> >from that.
>> >
>> >David
>> 
>> Did you just discover GIGO?
>
>Thanks for all the suggestions.
>
>I don't have a strong opinion on the naming or return type. I'm still a
>bit confused about whether I can assume that casting bool to int always
>results in 0 or 1.
>
>If that's the case, since most people prefer bool over int as the
>return type and some are against introducing u1, my current plan is to
>use the following in the next version:
>
>bool parity_odd(u64 val);
>
>This keeps the bool return type, renames the function for better
>clarity, and avoids extra maintenance burden by having just one
>function.
>
>If I can't assume that casting bool to int always results in 0 or 1,
>would it be acceptable to keep the return type as int?
>
>Would this work for everyone?
>
>Regards,
>Kuan-Wei

You *CAN* safely assume that bool is an integer type which always has the value 
0 or 1.


Re: [PATCH v2] drm/msm/dpu: reorder pointer operations after sanity checks to avoid NULL deref

2025-03-09 Thread Dmitry Baryshkov
On Sun, Mar 09, 2025 at 09:55:25AM +, Qasim Ijaz wrote:
> _dpu_encoder_trigger_start dereferences "struct dpu_encoder_phys *phys"
> before the sanity checks which can lead to a NULL pointer dereference if
> phys is NULL.
>  
> Fix this by reordering the dereference after the sanity checks.
>  
> Fixes: 8144d17a81d9 ("drm/msm/dpu: Skip trigger flush and start for CWB")
> Signed-off-by: Qasim Ijaz 
> ---
> v2:
> - Moved Signed-off tag below Fixes tag
> - Moved dpu_enc declaration to the top and initialisation below sanity checks
> 

Reviewed-by: Dmitry Baryshkov 
-- 
With best wishes
Dmitry


Re: [PATCH v5 1/7] bits: split the definition of the asm and non-asm GENMASK()

2025-03-09 Thread David Laight
On Sun, 9 Mar 2025 01:58:53 +
David Laight  wrote:

> On Fri, 7 Mar 2025 18:58:08 +0900
> Vincent Mailhol  wrote:
> 
> > On 07/03/2025 at 04:23, David Laight wrote:  
> > > On Thu, 06 Mar 2025 20:29:52 +0900
> > > Vincent Mailhol via B4 Relay 
> > >  wrote:
> > > 
> > >> From: Vincent Mailhol 
> > >>
> > >> In an upcoming change, GENMASK() and its friends will indirectly
> > >> depend on sizeof() which is not available in asm.
> > >>
> > >> Instead of adding further complexity to __GENMASK() to make it work
> > >> for both asm and non asm, just split the definition of the two
> > >> variants.
> > > ...
> > >> +#else /* defined(__ASSEMBLY__) */
> > >> +
> > >> +#define GENMASK(h, l)   __GENMASK(h, l)
> > >> +#define GENMASK_ULL(h, l)   __GENMASK_ULL(h, l)
> > > 
> > > What do those actually expand to now?
> > > As I've said a few times both UL(0) and ULL(0) are just (0) for 
> > > __ASSEMBLY__
> > > so the expansions of __GENMASK() and __GENMASK_ULL() contained the
> > > same numeric constants.
> > 
> > Indeed, in asm, the UL(0) and ULL(0) expands to the same thing: 0.
> > 
> > But the two macros still expand to something different on 32 bits
> > architectures:
> > 
> >   * __GENMASK:
> > 
> >   (((~(0)) << (l)) & (~(0) >> (32 - 1 - (h
> > 
> >   * __GENMASK_ULL:
> > 
> >   (((~(0)) << (l)) & (~(0) >> (64 - 1 - (h
> > 
> > On 64 bits architecture these are the same.  
> 
> I've just fed those into godbolt (https://www.godbolt.org/z/Ter6WE9qE) as:
> int fi(void)
> {
> int v;
> asm("mov $(((~(0)) << (8)) & (~(0) >> (32 - 1 - (15,%0": "=r" (v));
> return v -(((~(0u)) << (8)) & (~(0u) >> (32 - 1 - (15;
> }
> 
> gas warns:
> :4: Warning: 0xff00 shortened to 0xff00
> 
> unsigned long long fll(void)
> {
> unsigned long long v;
> asm("mov $(((~(0)) << (8)) & (~(0) >> (64 - 1 - (15,%0": "=r" (v));
> return v -(((~(0ull)) << (8)) & (~(0ull) >> (64 - 1 - (15;
> }
> 
> (for other architectures you'll need to change the opcode)
> 
> For x86 and x86-32 the assembler seems to be doing 64bit maths with unsigned
> right shifts - so the second function (with the 64 in it) generates 0xff00.
> I doubt a 32bit only assembler does 64bit maths, but the '>> 48' above
> might get masked to a '>> 16' by the cpu and generate the correct result.
> 
> So __GENMASK() is likely to be broken for any assembler that supports 64bits
> when generating 32bit code.
> __GENMASK_ULL() works (assuming all have unsigned >>) on 64bit assemblers
> (even when generating 32bit code). It may work on some 32bit assemblers.

I've remembered my 'pi' has a 32bit userspace (on a 64bit kernel).
I quick test of "mov %0,#(...)" and bits 11..8 gives the correct output
for size '32' but the error message:
/tmp/ccPB7bWh.s:26: Warning: shift count out of range (56 is not between 0 and 
31)
with size '64'.

Assuming that part of the gnu assembler is consistent across architectures
you can't use either GENMASK in asm for 32bit architectures.

Any change (probably including removing the asm support for the uapi) isn't
going to make things worse!

David

> 
> Since most uses in the header files will be GENMASK() I doubt (hope) no
> asm code actually uses the values!
> The headers assemble - but that is about all that can be said.
> 
> Bags of worms :-)
> 
>   David
> 



[PATCH 3/4] drm/vc4: use new helper to get ACR values

2025-03-09 Thread Dmitry Baryshkov
From: Dmitry Baryshkov 

Use drm_hdmi_acr_get_n_cts() helper instead of calculating N and CTS
values in the VC4 driver.

Signed-off-by: Dmitry Baryshkov 
---
 drivers/gpu/drm/vc4/vc4_hdmi.c | 10 +++---
 drivers/gpu/drm/vc4/vc4_hdmi.h |  7 +++
 2 files changed, 10 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
index 
37238a12baa58a06a5d6f40d1ab64abc7fac60d7..f24bcc2f3a2ac39aaea061b809940978341472f4
 100644
--- a/drivers/gpu/drm/vc4/vc4_hdmi.c
+++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
@@ -1637,6 +1637,7 @@ static void vc4_hdmi_encoder_atomic_mode_set(struct 
drm_encoder *encoder,
  &crtc_state->adjusted_mode);
vc4_hdmi->output_bpc = conn_state->hdmi.output_bpc;
vc4_hdmi->output_format = conn_state->hdmi.output_format;
+   vc4_hdmi->tmds_char_rate = conn_state->hdmi.tmds_char_rate;
mutex_unlock(&vc4_hdmi->mutex);
 }
 
@@ -1829,17 +1830,12 @@ static void vc4_hdmi_audio_set_mai_clock(struct 
vc4_hdmi *vc4_hdmi,
 
 static void vc4_hdmi_set_n_cts(struct vc4_hdmi *vc4_hdmi, unsigned int 
samplerate)
 {
-   const struct drm_display_mode *mode = &vc4_hdmi->saved_adjusted_mode;
-   u32 n, cts;
-   u64 tmp;
+   unsigned int n, cts;
 
lockdep_assert_held(&vc4_hdmi->mutex);
lockdep_assert_held(&vc4_hdmi->hw_lock);
 
-   n = 128 * samplerate / 1000;
-   tmp = (u64)(mode->clock * 1000) * n;
-   do_div(tmp, 128 * samplerate);
-   cts = tmp;
+   drm_hdmi_acr_get_n_cts(vc4_hdmi->tmds_char_rate, samplerate, &n, &cts);
 
HDMI_WRITE(HDMI_CRP_CFG,
   VC4_HDMI_CRP_CFG_EXTERNAL_CTS_EN |
diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.h b/drivers/gpu/drm/vc4/vc4_hdmi.h
index 
e3d989ca302b72533c374dfa3fd0d5bd7fe64a82..0a775dbfe99d45521f3d0a2016555aefa81d7934
 100644
--- a/drivers/gpu/drm/vc4/vc4_hdmi.h
+++ b/drivers/gpu/drm/vc4/vc4_hdmi.h
@@ -211,6 +211,13 @@ struct vc4_hdmi {
 * KMS hooks. Protected by @mutex.
 */
enum hdmi_colorspace output_format;
+
+   /**
+* @tmds_char_rate: Copy of
+* @drm_connector_state.hdmi.tmds_char_rate for use outside of
+* KMS hooks. Protected by @mutex.
+*/
+   unsigned long long tmds_char_rate;
 };
 
 #define connector_to_vc4_hdmi(_connector)  \

-- 
2.39.5



[PATCH 2/4] drm/msm/hdmi: use new helper for ACR tables

2025-03-09 Thread Dmitry Baryshkov
From: Dmitry Baryshkov 

Use new drm_hdmi_acr_get_n_cts() helper instead of hand-coding the
tables. Instead of storing the rate 'index', store the audio sample rate
in hdmi->audio.rate, removing the need for even more defines.

Signed-off-by: Dmitry Baryshkov 
---
 drivers/gpu/drm/msm/hdmi/hdmi_audio.c | 107 +++---
 1 file changed, 9 insertions(+), 98 deletions(-)

diff --git a/drivers/gpu/drm/msm/hdmi/hdmi_audio.c 
b/drivers/gpu/drm/msm/hdmi/hdmi_audio.c
index 
8bb975e82c17c1d77217128e9ddbd6a0575bb33d..b9ec14ef2c20ebfa03c30994eb2395f21b9502bb
 100644
--- a/drivers/gpu/drm/msm/hdmi/hdmi_audio.c
+++ b/drivers/gpu/drm/msm/hdmi/hdmi_audio.c
@@ -4,6 +4,7 @@
  * Author: Rob Clark 
  */
 
+#include 
 #include 
 
 #include 
@@ -12,71 +13,9 @@
 
 #include "hdmi.h"
 
-/* Supported HDMI Audio sample rates */
-#define MSM_HDMI_SAMPLE_RATE_32KHZ 0
-#define MSM_HDMI_SAMPLE_RATE_44_1KHZ   1
-#define MSM_HDMI_SAMPLE_RATE_48KHZ 2
-#define MSM_HDMI_SAMPLE_RATE_88_2KHZ   3
-#define MSM_HDMI_SAMPLE_RATE_96KHZ 4
-#define MSM_HDMI_SAMPLE_RATE_176_4KHZ  5
-#define MSM_HDMI_SAMPLE_RATE_192KHZ6
-#define MSM_HDMI_SAMPLE_RATE_MAX   7
-
-
-struct hdmi_msm_audio_acr {
-   uint32_t n; /* N parameter for clock regeneration */
-   uint32_t cts;   /* CTS parameter for clock regeneration */
-};
-
-struct hdmi_msm_audio_arcs {
-   unsigned long int pixclock;
-   struct hdmi_msm_audio_acr lut[MSM_HDMI_SAMPLE_RATE_MAX];
-};
-
-#define HDMI_MSM_AUDIO_ARCS(pclk, ...) { (1000 * (pclk)), __VA_ARGS__ }
-
-/* Audio constants lookup table for hdmi_msm_audio_acr_setup */
-/* Valid Pixel-Clock rates: 25.2MHz, 27MHz, 27.03MHz, 74.25MHz, 148.5MHz */
-static const struct hdmi_msm_audio_arcs acr_lut[] = {
-   /*  25.200MHz  */
-   HDMI_MSM_AUDIO_ARCS(25200, {
-   {4096, 25200}, {6272, 28000}, {6144, 25200}, {12544, 28000},
-   {12288, 25200}, {25088, 28000}, {24576, 25200} }),
-   /*  27.000MHz  */
-   HDMI_MSM_AUDIO_ARCS(27000, {
-   {4096, 27000}, {6272, 3}, {6144, 27000}, {12544, 3},
-   {12288, 27000}, {25088, 3}, {24576, 27000} }),
-   /*  27.027MHz */
-   HDMI_MSM_AUDIO_ARCS(27030, {
-   {4096, 27027}, {6272, 30030}, {6144, 27027}, {12544, 30030},
-   {12288, 27027}, {25088, 30030}, {24576, 27027} }),
-   /*  74.250MHz */
-   HDMI_MSM_AUDIO_ARCS(74250, {
-   {4096, 74250}, {6272, 82500}, {6144, 74250}, {12544, 82500},
-   {12288, 74250}, {25088, 82500}, {24576, 74250} }),
-   /* 148.500MHz */
-   HDMI_MSM_AUDIO_ARCS(148500, {
-   {4096, 148500}, {6272, 165000}, {6144, 148500}, {12544, 165000},
-   {12288, 148500}, {25088, 165000}, {24576, 148500} }),
-};
-
-static const struct hdmi_msm_audio_arcs *get_arcs(unsigned long int pixclock)
-{
-   int i;
-
-   for (i = 0; i < ARRAY_SIZE(acr_lut); i++) {
-   const struct hdmi_msm_audio_arcs *arcs = &acr_lut[i];
-   if (arcs->pixclock == pixclock)
-   return arcs;
-   }
-
-   return NULL;
-}
-
 int msm_hdmi_audio_update(struct hdmi *hdmi)
 {
struct hdmi_audio *audio = &hdmi->audio;
-   const struct hdmi_msm_audio_arcs *arcs = NULL;
bool enabled = audio->enabled;
uint32_t acr_pkt_ctrl, vbi_pkt_ctrl, aud_pkt_ctrl;
uint32_t audio_config;
@@ -94,15 +33,6 @@ int msm_hdmi_audio_update(struct hdmi *hdmi)
enabled = false;
}
 
-   if (enabled) {
-   arcs = get_arcs(hdmi->pixclock);
-   if (!arcs) {
-   DBG("disabling audio: unsupported pixclock: %lu",
-   hdmi->pixclock);
-   enabled = false;
-   }
-   }
-
/* Read first before writing */
acr_pkt_ctrl = hdmi_read(hdmi, REG_HDMI_ACR_PKT_CTRL);
vbi_pkt_ctrl = hdmi_read(hdmi, REG_HDMI_VBI_PKT_CTRL);
@@ -116,15 +46,12 @@ int msm_hdmi_audio_update(struct hdmi *hdmi)
uint32_t n, cts, multiplier;
enum hdmi_acr_cts select;
 
-   n   = arcs->lut[audio->rate].n;
-   cts = arcs->lut[audio->rate].cts;
+   drm_hdmi_acr_get_n_cts(hdmi->pixclock, audio->rate, &n, &cts);
 
-   if ((MSM_HDMI_SAMPLE_RATE_192KHZ == audio->rate) ||
-   (MSM_HDMI_SAMPLE_RATE_176_4KHZ == audio->rate)) 
{
+   if (audio->rate == 192000 || audio->rate == 176400) {
multiplier = 4;
n >>= 2; /* divide N by 4 and use multiplier */
-   } else if ((MSM_HDMI_SAMPLE_RATE_96KHZ == audio->rate) ||
-   (MSM_HDMI_SAMPLE_RATE_88_2KHZ == audio->rate)) {
+   } else if (audio->rate == 96000 || audio->rate == 88200) {
multiplier

Re: [PATCH] drm/msm/dpu: reorder pointer operations after sanity checks to avoid NULL deref

2025-03-09 Thread Markus Elfring
…
> Fix this by reordering the dereference after the sanity checks.

Another wording suggestion:
Thus move the assignment of the variable “dpu_enc” behind a null pointer check.


Would an other summary phrase be nicer?

Regards,
Markus


Re: [PATCH] drm/panel/synaptics-r63353: Use _multi variants

2025-03-09 Thread Tejas Vipin



On 3/6/25 9:03 PM, Anusha Srivatsa wrote:
> On Thu, Mar 6, 2025 at 11:29 AM Dmitry Baryshkov <
> dmitry.barysh...@linaro.org> wrote:
> 
>> On Thu, 6 Mar 2025 at 17:10, Anusha Srivatsa  wrote:
>>>
>>>
>>>
>>> On Thu, Mar 6, 2025 at 4:31 AM Maxime Ripard  wrote:

 Hi Anusha,

 On Wed, Mar 05, 2025 at 07:01:41PM -0500, Anusha Srivatsa wrote:
> Move away from using deprecated API and use _multi
> variants if available. Use mipi_dsi_msleep()
> and mipi_dsi_usleep_range() instead of msleep()
> and usleep_range() respectively.
>
> Used Coccinelle to find the multiple occurences.
> SmPl patch:
> @rule@
> identifier dsi_var;
> identifier r;
> identifier func;
> type t;
> position p;
> expression dsi_device;
> expression list es;
> @@
> t func(...) {
> ...
> struct mipi_dsi_device *dsi_var = dsi_device;
> +struct mipi_dsi_multi_context dsi_ctx = { .dsi = dsi_var };
> <+...
> (
> -mipi_dsi_dcs_write_seq(dsi_var,es)@p;
> +mipi_dsi_dcs_write_seq_multi(&dsi_ctx,es);
> |
> -mipi_dsi_generic_write_seq(dsi_var,es)@p;
> +mipi_dsi_generic_write_seq_multi(&dsi_ctx,es);
> |
> -mipi_dsi_generic_write(dsi_var,es)@p;
> +mipi_dsi_generic_write_multi(&dsi_ctx,es);
> |
> -r = mipi_dsi_dcs_nop(dsi_var)@p;
> +mipi_dsi_dcs_nop_multi(&dsi_ctx);
> |
> rest of API
> ..
> )
> -if(r < 0) {
> -...
> -}
> ...+>

 The point of sending a single patch was to review the coccinelle script,
 so you must put the entire script you used here.

>>>
>>> I was actually thinking of sending patches per driver this time around
>> since Tejas also seems to be looking into similar partsThoughts?
>>
>> Have you discussed it with Tejas? What is his next target?
>>
>> I was hoping he will have some feedback on this patch and we could take it
> from there.
> It *should* be okay for me to send all changes in a single series...
> 
> Anusha
>

There's 5 more panels that use dcs/generic write_seq(). Maybe I could
work on those (himax-hx8394, samsung-sofef00, samsung-s6d7aa0,
boe-bf060y8m-aj0, jdi-lpm102a188a) while you work on transitioning the
rest of the panels (excluding these) that use other functions in the 
old API? When either of us finishes before the other we could have 
another discussion about splitting work if necessary. I'm open to other
suggestions too.

> Cc: Maxime Ripard 

 That hasn't been my email address for 6 years :)

>>> My bad. Will change this.
>>
>>
>>
>> --
>> With best wishes
>> Dmitry
>>
>>
> 

-- 
Tejas Vipin


[PATCH 3/9] rtc: pcf50633: Remove

2025-03-09 Thread linux
From: "Dr. David Alan Gilbert" 

The pcf50633 was used as part of the OpenMoko devices but
the support for its main chip was recently removed in:
commit 61b7f8920b17 ("ARM: s3c: remove all s3c24xx support")

See https://lore.kernel.org/all/Z8z236h4B5A6Ki3D@gallifrey/

Remove it.

Signed-off-by: Dr. David Alan Gilbert 
---
 drivers/mfd/pcf50633-core.c   |   2 -
 drivers/rtc/Kconfig   |   7 -
 drivers/rtc/Makefile  |   1 -
 drivers/rtc/rtc-pcf50633.c| 284 --
 include/linux/mfd/pcf50633/core.h |   1 -
 5 files changed, 295 deletions(-)
 delete mode 100644 drivers/rtc/rtc-pcf50633.c

diff --git a/drivers/mfd/pcf50633-core.c b/drivers/mfd/pcf50633-core.c
index 08aa68ef2fbc..d991a77f6dd2 100644
--- a/drivers/mfd/pcf50633-core.c
+++ b/drivers/mfd/pcf50633-core.c
@@ -208,7 +208,6 @@ static int pcf50633_probe(struct i2c_client *client)
 
/* Create sub devices */
pcf50633_client_dev_register(pcf, "pcf50633-input", &pcf->input_pdev);
-   pcf50633_client_dev_register(pcf, "pcf50633-rtc", &pcf->rtc_pdev);
pcf50633_client_dev_register(pcf, "pcf50633-mbc", &pcf->mbc_pdev);
 
 
@@ -259,7 +258,6 @@ static void pcf50633_remove(struct i2c_client *client)
pcf50633_irq_free(pcf);
 
platform_device_unregister(pcf->input_pdev);
-   platform_device_unregister(pcf->rtc_pdev);
platform_device_unregister(pcf->mbc_pdev);
 
for (i = 0; i < PCF50633_NUM_REGULATORS; i++)
diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig
index 0bbbf778ecfa..838bdc138ffe 100644
--- a/drivers/rtc/Kconfig
+++ b/drivers/rtc/Kconfig
@@ -1321,13 +1321,6 @@ config RTC_DRV_SPEAR
 If you say Y here you will get support for the RTC found on
 spear
 
-config RTC_DRV_PCF50633
-   depends on MFD_PCF50633
-   tristate "NXP PCF50633 RTC"
-   help
- If you say yes here you get support for the RTC subsystem of the
- NXP PCF50633 used in embedded systems.
-
 config RTC_DRV_AB8500
tristate "ST-Ericsson AB8500 RTC"
depends on AB8500_CORE
diff --git a/drivers/rtc/Makefile b/drivers/rtc/Makefile
index 489b4ab07068..31473b3276d9 100644
--- a/drivers/rtc/Makefile
+++ b/drivers/rtc/Makefile
@@ -126,7 +126,6 @@ obj-$(CONFIG_RTC_DRV_PALMAS)+= rtc-palmas.o
 obj-$(CONFIG_RTC_DRV_PCAP) += rtc-pcap.o
 obj-$(CONFIG_RTC_DRV_PCF2123)  += rtc-pcf2123.o
 obj-$(CONFIG_RTC_DRV_PCF2127)  += rtc-pcf2127.o
-obj-$(CONFIG_RTC_DRV_PCF50633) += rtc-pcf50633.o
 obj-$(CONFIG_RTC_DRV_PCF85063) += rtc-pcf85063.o
 obj-$(CONFIG_RTC_DRV_PCF8523)  += rtc-pcf8523.o
 obj-$(CONFIG_RTC_DRV_PCF85363) += rtc-pcf85363.o
diff --git a/drivers/rtc/rtc-pcf50633.c b/drivers/rtc/rtc-pcf50633.c
deleted file mode 100644
index c019c4d91c7d..
--- a/drivers/rtc/rtc-pcf50633.c
+++ /dev/null
@@ -1,284 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0-or-later
-/* NXP PCF50633 RTC Driver
- *
- * (C) 2006-2008 by Openmoko, Inc.
- * Author: Balaji Rao 
- * All rights reserved.
- *
- * Broken down from monstrous PCF50633 driver mainly by
- * Harald Welte, Andy Green and Werner Almesberger
- */
-
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-
-#include 
-
-#define PCF50633_REG_RTCSC 0x59 /* Second */
-#define PCF50633_REG_RTCMN 0x5a /* Minute */
-#define PCF50633_REG_RTCHR 0x5b /* Hour */
-#define PCF50633_REG_RTCWD 0x5c /* Weekday */
-#define PCF50633_REG_RTCDT 0x5d /* Day */
-#define PCF50633_REG_RTCMT 0x5e /* Month */
-#define PCF50633_REG_RTCYR 0x5f /* Year */
-#define PCF50633_REG_RTCSCA0x60 /* Alarm Second */
-#define PCF50633_REG_RTCMNA0x61 /* Alarm Minute */
-#define PCF50633_REG_RTCHRA0x62 /* Alarm Hour */
-#define PCF50633_REG_RTCWDA0x63 /* Alarm Weekday */
-#define PCF50633_REG_RTCDTA0x64 /* Alarm Day */
-#define PCF50633_REG_RTCMTA0x65 /* Alarm Month */
-#define PCF50633_REG_RTCYRA0x66 /* Alarm Year */
-
-enum pcf50633_time_indexes {
-   PCF50633_TI_SEC,
-   PCF50633_TI_MIN,
-   PCF50633_TI_HOUR,
-   PCF50633_TI_WKDAY,
-   PCF50633_TI_DAY,
-   PCF50633_TI_MONTH,
-   PCF50633_TI_YEAR,
-   PCF50633_TI_EXTENT /* always last */
-};
-
-struct pcf50633_time {
-   u_int8_t time[PCF50633_TI_EXTENT];
-};
-
-struct pcf50633_rtc {
-   int alarm_enabled;
-   int alarm_pending;
-
-   struct pcf50633 *pcf;
-   struct rtc_device *rtc_dev;
-};
-
-static void pcf2rtc_time(struct rtc_time *rtc, struct pcf50633_time *pcf)
-{
-   rtc->tm_sec = bcd2bin(pcf->time[PCF50633_TI_SEC]);
-   rtc->tm_min = bcd2bin(pcf->time[PCF50633_TI_MIN]);
-   rtc->tm_hour = bcd2bin(pcf->time[PCF50633_TI_HOUR]);
-   rtc->tm_wday = bcd2bin(pcf->time[PCF50633_TI_WKDAY]);
-   rtc->tm_mday = bcd2bin(pcf->time[PCF50633_TI_DAY]);
-   rtc->tm_mon = bcd2bin(pcf->time[PCF50633_TI_MONTH]) - 1;
-   rtc->tm_year = bcd2bin(pcf->time[PCF50633_TI_YEAR]) + 100;
-}
-
-static void rtc

[PATCH 6/9] regulator: pcf50633-regulator: Remove

2025-03-09 Thread linux
From: "Dr. David Alan Gilbert" 

The pcf50633 was used as part of the OpenMoko devices but
the support for its main chip was recently removed in:
commit 61b7f8920b17 ("ARM: s3c: remove all s3c24xx support")

See https://lore.kernel.org/all/Z8z236h4B5A6Ki3D@gallifrey/

Remove it.

Signed-off-by: Dr. David Alan Gilbert 
---
 drivers/mfd/pcf50633-core.c|  35 +--
 drivers/regulator/Kconfig  |   7 --
 drivers/regulator/Makefile |   1 -
 drivers/regulator/pcf50633-regulator.c | 124 -
 include/linux/mfd/pcf50633/core.h  |   1 -
 5 files changed, 1 insertion(+), 167 deletions(-)
 delete mode 100644 drivers/regulator/pcf50633-regulator.c

diff --git a/drivers/mfd/pcf50633-core.c b/drivers/mfd/pcf50633-core.c
index f12359f42140..be90ca30b75b 100644
--- a/drivers/mfd/pcf50633-core.c
+++ b/drivers/mfd/pcf50633-core.c
@@ -166,9 +166,8 @@ static const struct regmap_config pcf50633_regmap_config = {
 static int pcf50633_probe(struct i2c_client *client)
 {
struct pcf50633 *pcf;
-   struct platform_device *pdev;
struct pcf50633_platform_data *pdata = dev_get_platdata(&client->dev);
-   int i, j, ret;
+   int ret;
int version, variant;
 
if (!client->irq) {
@@ -210,26 +209,6 @@ static int pcf50633_probe(struct i2c_client *client)
pcf50633_client_dev_register(pcf, "pcf50633-mbc", &pcf->mbc_pdev);
 
 
-   for (i = 0; i < PCF50633_NUM_REGULATORS; i++) {
-   pdev = platform_device_alloc("pcf50633-regulator", i);
-   if (!pdev) {
-   ret = -ENOMEM;
-   goto err2;
-   }
-
-   pdev->dev.parent = pcf->dev;
-   ret = platform_device_add_data(pdev, &pdata->reg_init_data[i],
-  sizeof(pdata->reg_init_data[i]));
-   if (ret)
-   goto err;
-
-   ret = platform_device_add(pdev);
-   if (ret)
-   goto err;
-
-   pcf->regulator_pdev[i] = pdev;
-   }
-
ret = sysfs_create_group(&client->dev.kobj, &pcf_attr_group);
if (ret)
dev_warn(pcf->dev, "error creating sysfs entries\n");
@@ -238,28 +217,16 @@ static int pcf50633_probe(struct i2c_client *client)
pdata->probe_done(pcf);
 
return 0;
-
-err:
-   platform_device_put(pdev);
-err2:
-   for (j = 0; j < i; j++)
-   platform_device_put(pcf->regulator_pdev[j]);
-
-   return ret;
 }
 
 static void pcf50633_remove(struct i2c_client *client)
 {
struct pcf50633 *pcf = i2c_get_clientdata(client);
-   int i;
 
sysfs_remove_group(&client->dev.kobj, &pcf_attr_group);
pcf50633_irq_free(pcf);
 
platform_device_unregister(pcf->mbc_pdev);
-
-   for (i = 0; i < PCF50633_NUM_REGULATORS; i++)
-   platform_device_unregister(pcf->regulator_pdev[i]);
 }
 
 static const struct i2c_device_id pcf50633_id_table[] = {
diff --git a/drivers/regulator/Kconfig b/drivers/regulator/Kconfig
index 39297f7d8177..1236b3a1f93f 100644
--- a/drivers/regulator/Kconfig
+++ b/drivers/regulator/Kconfig
@@ -988,13 +988,6 @@ config REGULATOR_PCAP
 This driver provides support for the voltage regulators of the
 PCAP2 PMIC.
 
-config REGULATOR_PCF50633
-   tristate "NXP PCF50633 regulator driver"
-   depends on MFD_PCF50633
-   help
-Say Y here to support the voltage regulators and converters
-on PCF50633
-
 config REGULATOR_PF8X00
tristate "NXP PF8100/PF8121A/PF8200 regulator driver"
depends on I2C && OF
diff --git a/drivers/regulator/Makefile b/drivers/regulator/Makefile
index 3d5a803dce8a..8dca3567437f 100644
--- a/drivers/regulator/Makefile
+++ b/drivers/regulator/Makefile
@@ -132,7 +132,6 @@ obj-$(CONFIG_REGULATOR_PWM) += pwm-regulator.o
 obj-$(CONFIG_REGULATOR_TPS51632) += tps51632-regulator.o
 obj-$(CONFIG_REGULATOR_PBIAS) += pbias-regulator.o
 obj-$(CONFIG_REGULATOR_PCAP) += pcap-regulator.o
-obj-$(CONFIG_REGULATOR_PCF50633) += pcf50633-regulator.o
 obj-$(CONFIG_REGULATOR_RAA215300) += raa215300.o
 obj-$(CONFIG_REGULATOR_RASPBERRYPI_TOUCHSCREEN_ATTINY)  += 
rpi-panel-attiny-regulator.o
 obj-$(CONFIG_REGULATOR_RC5T583)  += rc5t583-regulator.o
diff --git a/drivers/regulator/pcf50633-regulator.c 
b/drivers/regulator/pcf50633-regulator.c
deleted file mode 100644
index 9f08a62c800e..
--- a/drivers/regulator/pcf50633-regulator.c
+++ /dev/null
@@ -1,124 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0-or-later
-/* NXP PCF50633 PMIC Driver
- *
- * (C) 2006-2008 by Openmoko, Inc.
- * Author: Balaji Rao 
- * All rights reserved.
- *
- * Broken down from monstrous PCF50633 driver mainly by
- * Harald Welte and Andy Green and Werner Almesberger
- */
-
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-
-#include 
-#include 
-
-#define PCF50633_REGULATOR(_name, _id, _min_uV, _uV_s

[PATCH 9/9] mfd: pcf50633: Remove remains

2025-03-09 Thread linux
From: "Dr. David Alan Gilbert" 

Remove the remaining parts of the 50633, the core, headers and glue.

The pcf50633 was used as part of the OpenMoko devices but
the support for its main chip was recently removed in:
commit 61b7f8920b17 ("ARM: s3c: remove all s3c24xx support")

See https://lore.kernel.org/all/Z8z236h4B5A6Ki3D@gallifrey/

Remove it.

Signed-off-by: Dr. David Alan Gilbert 
---
 arch/mips/configs/ip27_defconfig  |   1 -
 drivers/mfd/Kconfig   |  10 --
 drivers/mfd/Makefile  |   2 -
 drivers/mfd/pcf50633-core.c   | 260 --
 include/linux/mfd/pcf50633/core.h | 224 -
 include/linux/mfd/pcf50633/mbc.h  | 130 ---
 include/linux/mfd/pcf50633/pmic.h |  68 
 7 files changed, 695 deletions(-)
 delete mode 100644 drivers/mfd/pcf50633-core.c
 delete mode 100644 include/linux/mfd/pcf50633/core.h
 delete mode 100644 include/linux/mfd/pcf50633/mbc.h
 delete mode 100644 include/linux/mfd/pcf50633/pmic.h

diff --git a/arch/mips/configs/ip27_defconfig b/arch/mips/configs/ip27_defconfig
index 0a9ec09aff65..c13c2f3cff9a 100644
--- a/arch/mips/configs/ip27_defconfig
+++ b/arch/mips/configs/ip27_defconfig
@@ -255,7 +255,6 @@ CONFIG_I2C_TAOS_EVM=m
 CONFIG_I2C_STUB=m
 # CONFIG_HWMON is not set
 CONFIG_THERMAL=y
-CONFIG_MFD_PCF50633=m
 # CONFIG_VGA_ARB is not set
 CONFIG_LEDS_LP3944=m
 CONFIG_LEDS_PCA955X=m
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index 766453ef6c2d..1eeb62dac8d3 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -1119,16 +1119,6 @@ config MFD_RETU
  Retu and Tahvo are a multi-function devices found on Nokia
  Internet Tablets (770, N800 and N810).
 
-config MFD_PCF50633
-   tristate "NXP PCF50633"
-   depends on I2C
-   select REGMAP_I2C
-   help
- Say yes here if you have NXP PCF50633 chip on your board.
- This core driver provides register access and IRQ handling
- facilities, and registers devices for the various functions
- so that function-specific drivers can bind to them.
-
 config MFD_PM8XXX
tristate "Qualcomm PM8xxx PMIC chips driver"
depends on ARM || HEXAGON || COMPILE_TEST
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index f1c7a15c8f7b..941e4ba58b24 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -183,8 +183,6 @@ obj-$(CONFIG_MFD_MT6370)+= mt6370.o
 mt6397-objs:= mt6397-core.o mt6397-irq.o mt6358-irq.o
 obj-$(CONFIG_MFD_MT6397)   += mt6397.o
 
-pcf50633-objs  := pcf50633-core.o
-obj-$(CONFIG_MFD_PCF50633) += pcf50633.o
 obj-$(CONFIG_RZ_MTU3)  += rz-mtu3.o
 obj-$(CONFIG_ABX500_CORE)  += abx500-core.o
 obj-$(CONFIG_MFD_DB8500_PRCMU) += db8500-prcmu.o
diff --git a/drivers/mfd/pcf50633-core.c b/drivers/mfd/pcf50633-core.c
deleted file mode 100644
index 1637816a23d1..
--- a/drivers/mfd/pcf50633-core.c
+++ /dev/null
@@ -1,260 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0-or-later
-/* NXP PCF50633 Power Management Unit (PMU) driver
- *
- * (C) 2006-2008 by Openmoko, Inc.
- * Author: Harald Welte 
- *Balaji Rao 
- * All rights reserved.
- */
-
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-
-#include 
-
-/* Read a block of up to 32 regs  */
-int pcf50633_read_block(struct pcf50633 *pcf, u8 reg,
-   int nr_regs, u8 *data)
-{
-   int ret;
-
-   ret = regmap_raw_read(pcf->regmap, reg, data, nr_regs);
-   if (ret != 0)
-   return ret;
-
-   return nr_regs;
-}
-EXPORT_SYMBOL_GPL(pcf50633_read_block);
-
-/* Write a block of up to 32 regs  */
-int pcf50633_write_block(struct pcf50633 *pcf , u8 reg,
-   int nr_regs, u8 *data)
-{
-   return regmap_raw_write(pcf->regmap, reg, data, nr_regs);
-}
-EXPORT_SYMBOL_GPL(pcf50633_write_block);
-
-u8 pcf50633_reg_read(struct pcf50633 *pcf, u8 reg)
-{
-   unsigned int val;
-   int ret;
-
-   ret = regmap_read(pcf->regmap, reg, &val);
-   if (ret < 0)
-   return -1;
-
-   return val;
-}
-EXPORT_SYMBOL_GPL(pcf50633_reg_read);
-
-int pcf50633_reg_write(struct pcf50633 *pcf, u8 reg, u8 val)
-{
-   return regmap_write(pcf->regmap, reg, val);
-}
-EXPORT_SYMBOL_GPL(pcf50633_reg_write);
-
-int pcf50633_reg_set_bit_mask(struct pcf50633 *pcf, u8 reg, u8 mask, u8 val)
-{
-   return regmap_update_bits(pcf->regmap, reg, mask, val);
-}
-EXPORT_SYMBOL_GPL(pcf50633_reg_set_bit_mask);
-
-int pcf50633_reg_clear_bits(struct pcf50633 *pcf, u8 reg, u8 val)
-{
-   return regmap_update_bits(pcf->regmap, reg, val, 0);
-}
-EXPORT_SYMBOL_GPL(pcf50633_reg_clear_bits);
-
-/* sysfs attributes */
-static ssize_t dump_regs_show(struct device *dev,
- struct device_attribute *attr, char *buf)
-{
-   struct pcf50633 *pcf 

[PATCH 8/9] mfd: pcf50633: Remove irq code

2025-03-09 Thread linux
From: "Dr. David Alan Gilbert" 

As part of the pcf50633 removal, take out it's irq code
(which includes one bit still called from the core, but it'll
go soon).

Signed-off-by: Dr. David Alan Gilbert 
---
 drivers/mfd/Makefile|   2 +-
 drivers/mfd/pcf50633-core.c |   5 +-
 drivers/mfd/pcf50633-irq.c  | 312 
 3 files changed, 2 insertions(+), 317 deletions(-)
 delete mode 100644 drivers/mfd/pcf50633-irq.c

diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index d769e40251c8..f1c7a15c8f7b 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -183,7 +183,7 @@ obj-$(CONFIG_MFD_MT6370)+= mt6370.o
 mt6397-objs:= mt6397-core.o mt6397-irq.o mt6358-irq.o
 obj-$(CONFIG_MFD_MT6397)   += mt6397.o
 
-pcf50633-objs  := pcf50633-core.o pcf50633-irq.o
+pcf50633-objs  := pcf50633-core.o
 obj-$(CONFIG_MFD_PCF50633) += pcf50633.o
 obj-$(CONFIG_RZ_MTU3)  += rz-mtu3.o
 obj-$(CONFIG_ABX500_CORE)  += abx500-core.o
diff --git a/drivers/mfd/pcf50633-core.c b/drivers/mfd/pcf50633-core.c
index be90ca30b75b..1637816a23d1 100644
--- a/drivers/mfd/pcf50633-core.c
+++ b/drivers/mfd/pcf50633-core.c
@@ -203,8 +203,6 @@ static int pcf50633_probe(struct i2c_client *client)
dev_info(pcf->dev, "Probed device version %d variant %d\n",
version, variant);
 
-   pcf50633_irq_init(pcf, client->irq);
-
/* Create sub devices */
pcf50633_client_dev_register(pcf, "pcf50633-mbc", &pcf->mbc_pdev);
 
@@ -224,7 +222,6 @@ static void pcf50633_remove(struct i2c_client *client)
struct pcf50633 *pcf = i2c_get_clientdata(client);
 
sysfs_remove_group(&client->dev.kobj, &pcf_attr_group);
-   pcf50633_irq_free(pcf);
 
platform_device_unregister(pcf->mbc_pdev);
 }
@@ -238,7 +235,7 @@ MODULE_DEVICE_TABLE(i2c, pcf50633_id_table);
 static struct i2c_driver pcf50633_driver = {
.driver = {
.name   = "pcf50633",
-   .pm = pm_sleep_ptr(&pcf50633_pm),
+   /* going .pm= pm_sleep_ptr(&pcf50633_pm), */
},
.id_table = pcf50633_id_table,
.probe = pcf50633_probe,
diff --git a/drivers/mfd/pcf50633-irq.c b/drivers/mfd/pcf50633-irq.c
deleted file mode 100644
index e85af7f1cb0b..
--- a/drivers/mfd/pcf50633-irq.c
+++ /dev/null
@@ -1,312 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0-or-later
-/* NXP PCF50633 Power Management Unit (PMU) driver
- *
- * (C) 2006-2008 by Openmoko, Inc.
- * Author: Harald Welte 
- *Balaji Rao 
- * All rights reserved.
- */
-
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-
-#include 
-#include 
-
-int pcf50633_register_irq(struct pcf50633 *pcf, int irq,
-   void (*handler) (int, void *), void *data)
-{
-   if (irq < 0 || irq >= PCF50633_NUM_IRQ || !handler)
-   return -EINVAL;
-
-   if (WARN_ON(pcf->irq_handler[irq].handler))
-   return -EBUSY;
-
-   mutex_lock(&pcf->lock);
-   pcf->irq_handler[irq].handler = handler;
-   pcf->irq_handler[irq].data = data;
-   mutex_unlock(&pcf->lock);
-
-   return 0;
-}
-EXPORT_SYMBOL_GPL(pcf50633_register_irq);
-
-int pcf50633_free_irq(struct pcf50633 *pcf, int irq)
-{
-   if (irq < 0 || irq >= PCF50633_NUM_IRQ)
-   return -EINVAL;
-
-   mutex_lock(&pcf->lock);
-   pcf->irq_handler[irq].handler = NULL;
-   mutex_unlock(&pcf->lock);
-
-   return 0;
-}
-EXPORT_SYMBOL_GPL(pcf50633_free_irq);
-
-static int __pcf50633_irq_mask_set(struct pcf50633 *pcf, int irq, u8 mask)
-{
-   u8 reg, bit;
-   int idx;
-
-   idx = irq >> 3;
-   reg = PCF50633_REG_INT1M + idx;
-   bit = 1 << (irq & 0x07);
-
-   pcf50633_reg_set_bit_mask(pcf, reg, bit, mask ? bit : 0);
-
-   mutex_lock(&pcf->lock);
-
-   if (mask)
-   pcf->mask_regs[idx] |= bit;
-   else
-   pcf->mask_regs[idx] &= ~bit;
-
-   mutex_unlock(&pcf->lock);
-
-   return 0;
-}
-
-int pcf50633_irq_mask(struct pcf50633 *pcf, int irq)
-{
-   dev_dbg(pcf->dev, "Masking IRQ %d\n", irq);
-
-   return __pcf50633_irq_mask_set(pcf, irq, 1);
-}
-EXPORT_SYMBOL_GPL(pcf50633_irq_mask);
-
-int pcf50633_irq_unmask(struct pcf50633 *pcf, int irq)
-{
-   dev_dbg(pcf->dev, "Unmasking IRQ %d\n", irq);
-
-   return __pcf50633_irq_mask_set(pcf, irq, 0);
-}
-EXPORT_SYMBOL_GPL(pcf50633_irq_unmask);
-
-int pcf50633_irq_mask_get(struct pcf50633 *pcf, int irq)
-{
-   u8 reg, bits;
-
-   reg =  irq >> 3;
-   bits = 1 << (irq & 0x07);
-
-   return pcf->mask_regs[reg] & bits;
-}
-EXPORT_SYMBOL_GPL(pcf50633_irq_mask_get);
-
-static void pcf50633_irq_call_handler(struct pcf50633 *pcf, int irq)
-{
-   if (pcf->irq_handler[irq].handler)
-   pcf->irq_handler[irq].handler(irq, pcf->irq_handler[irq].data);
-}
-
-/* Maximum amount of ti

[PATCH 0/9] Remove pcf50633

2025-03-09 Thread linux
From: "Dr. David Alan Gilbert" 

The pcf50633 was used as part of the OpenMoko devices but
the support for its main chip was recently removed in:
commit 61b7f8920b17 ("ARM: s3c: remove all s3c24xx support")

See https://lore.kernel.org/all/Z8z236h4B5A6Ki3D@gallifrey/

Remove it.

I've split this up based on the subcomponents to make the size
of each patch sensible.

Dave

Signed-off-by: Dr. David Alan Gilbert 


Dr. David Alan Gilbert (9):
  mfd: pcf50633-adc:  Remove
  backlight: pcf50633-backlight: Remove
  rtc: pcf50633: Remove
  mfd: pcF50633-gpio: Remove
  Input: pcf50633-input - Remove
  regulator: pcf50633-regulator: Remove
  power: supply: pcf50633: Remove charger
  mfd: pcf50633: Remove irq code
  mfd: pcf50633: Remove remains

 arch/mips/configs/ip27_defconfig |   3 -
 drivers/input/misc/Kconfig   |   7 -
 drivers/input/misc/Makefile  |   1 -
 drivers/input/misc/pcf50633-input.c  | 113 -
 drivers/mfd/Kconfig  |  24 -
 drivers/mfd/Makefile |   4 -
 drivers/mfd/pcf50633-adc.c   | 255 --
 drivers/mfd/pcf50633-core.c  | 304 
 drivers/mfd/pcf50633-gpio.c  |  92 
 drivers/mfd/pcf50633-irq.c   | 312 -
 drivers/power/supply/Kconfig |   6 -
 drivers/power/supply/Makefile|   1 -
 drivers/power/supply/pcf50633-charger.c  | 466 ---
 drivers/regulator/Kconfig|   7 -
 drivers/regulator/Makefile   |   1 -
 drivers/regulator/pcf50633-regulator.c   | 124 -
 drivers/rtc/Kconfig  |   7 -
 drivers/rtc/Makefile |   1 -
 drivers/rtc/rtc-pcf50633.c   | 284 ---
 drivers/video/backlight/Kconfig  |   7 -
 drivers/video/backlight/Makefile |   1 -
 drivers/video/backlight/pcf50633-backlight.c | 154 --
 include/linux/mfd/pcf50633/adc.h |  69 ---
 include/linux/mfd/pcf50633/backlight.h   |  42 --
 include/linux/mfd/pcf50633/core.h| 232 -
 include/linux/mfd/pcf50633/gpio.h|  48 --
 include/linux/mfd/pcf50633/mbc.h | 130 --
 include/linux/mfd/pcf50633/pmic.h|  68 ---
 28 files changed, 2763 deletions(-)
 delete mode 100644 drivers/input/misc/pcf50633-input.c
 delete mode 100644 drivers/mfd/pcf50633-adc.c
 delete mode 100644 drivers/mfd/pcf50633-core.c
 delete mode 100644 drivers/mfd/pcf50633-gpio.c
 delete mode 100644 drivers/mfd/pcf50633-irq.c
 delete mode 100644 drivers/power/supply/pcf50633-charger.c
 delete mode 100644 drivers/regulator/pcf50633-regulator.c
 delete mode 100644 drivers/rtc/rtc-pcf50633.c
 delete mode 100644 drivers/video/backlight/pcf50633-backlight.c
 delete mode 100644 include/linux/mfd/pcf50633/adc.h
 delete mode 100644 include/linux/mfd/pcf50633/backlight.h
 delete mode 100644 include/linux/mfd/pcf50633/core.h
 delete mode 100644 include/linux/mfd/pcf50633/gpio.h
 delete mode 100644 include/linux/mfd/pcf50633/mbc.h
 delete mode 100644 include/linux/mfd/pcf50633/pmic.h

-- 
2.48.1



[PATCH 4/9] mfd: pcF50633-gpio: Remove

2025-03-09 Thread linux
From: "Dr. David Alan Gilbert" 

The pcf50633 was used as part of the OpenMoko devices but
the support for its main chip was recently removed in:
commit 61b7f8920b17 ("ARM: s3c: remove all s3c24xx support")

See https://lore.kernel.org/all/Z8z236h4B5A6Ki3D@gallifrey/

Remove it.

Signed-off-by: Dr. David Alan Gilbert 
---
 arch/mips/configs/ip27_defconfig  |  1 -
 drivers/mfd/Kconfig   |  7 ---
 drivers/mfd/Makefile  |  1 -
 drivers/mfd/pcf50633-gpio.c   | 92 ---
 include/linux/mfd/pcf50633/gpio.h | 48 
 5 files changed, 149 deletions(-)
 delete mode 100644 drivers/mfd/pcf50633-gpio.c
 delete mode 100644 include/linux/mfd/pcf50633/gpio.h

diff --git a/arch/mips/configs/ip27_defconfig b/arch/mips/configs/ip27_defconfig
index 66085bb71bc4..0a9ec09aff65 100644
--- a/arch/mips/configs/ip27_defconfig
+++ b/arch/mips/configs/ip27_defconfig
@@ -256,7 +256,6 @@ CONFIG_I2C_STUB=m
 # CONFIG_HWMON is not set
 CONFIG_THERMAL=y
 CONFIG_MFD_PCF50633=m
-CONFIG_PCF50633_GPIO=m
 # CONFIG_VGA_ARB is not set
 CONFIG_LEDS_LP3944=m
 CONFIG_LEDS_PCA955X=m
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index 051272126fe1..766453ef6c2d 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -1129,13 +1129,6 @@ config MFD_PCF50633
  facilities, and registers devices for the various functions
  so that function-specific drivers can bind to them.
 
-config PCF50633_GPIO
-   tristate "NXP PCF50633 GPIO"
-   depends on MFD_PCF50633
-   help
- Say yes here if you want to include support GPIO for pins on
- the PCF50633 chip.
-
 config MFD_PM8XXX
tristate "Qualcomm PM8xxx PMIC chips driver"
depends on ARM || HEXAGON || COMPILE_TEST
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index e085da3f13c3..d769e40251c8 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -185,7 +185,6 @@ obj-$(CONFIG_MFD_MT6397)+= mt6397.o
 
 pcf50633-objs  := pcf50633-core.o pcf50633-irq.o
 obj-$(CONFIG_MFD_PCF50633) += pcf50633.o
-obj-$(CONFIG_PCF50633_GPIO)+= pcf50633-gpio.o
 obj-$(CONFIG_RZ_MTU3)  += rz-mtu3.o
 obj-$(CONFIG_ABX500_CORE)  += abx500-core.o
 obj-$(CONFIG_MFD_DB8500_PRCMU) += db8500-prcmu.o
diff --git a/drivers/mfd/pcf50633-gpio.c b/drivers/mfd/pcf50633-gpio.c
deleted file mode 100644
index 3e368219479a..
--- a/drivers/mfd/pcf50633-gpio.c
+++ /dev/null
@@ -1,92 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0-or-later
-/* NXP PCF50633 GPIO Driver
- *
- * (C) 2006-2008 by Openmoko, Inc.
- * Author: Balaji Rao 
- * All rights reserved.
- *
- * Broken down from monstrous PCF50633 driver mainly by
- * Harald Welte, Andy Green and Werner Almesberger
- */
-
-#include 
-#include 
-
-#include 
-#include 
-#include 
-
-static const u8 pcf50633_regulator_registers[PCF50633_NUM_REGULATORS] = {
-   [PCF50633_REGULATOR_AUTO]   = PCF50633_REG_AUTOOUT,
-   [PCF50633_REGULATOR_DOWN1]  = PCF50633_REG_DOWN1OUT,
-   [PCF50633_REGULATOR_DOWN2]  = PCF50633_REG_DOWN2OUT,
-   [PCF50633_REGULATOR_MEMLDO] = PCF50633_REG_MEMLDOOUT,
-   [PCF50633_REGULATOR_LDO1]   = PCF50633_REG_LDO1OUT,
-   [PCF50633_REGULATOR_LDO2]   = PCF50633_REG_LDO2OUT,
-   [PCF50633_REGULATOR_LDO3]   = PCF50633_REG_LDO3OUT,
-   [PCF50633_REGULATOR_LDO4]   = PCF50633_REG_LDO4OUT,
-   [PCF50633_REGULATOR_LDO5]   = PCF50633_REG_LDO5OUT,
-   [PCF50633_REGULATOR_LDO6]   = PCF50633_REG_LDO6OUT,
-   [PCF50633_REGULATOR_HCLDO]  = PCF50633_REG_HCLDOOUT,
-};
-
-int pcf50633_gpio_set(struct pcf50633 *pcf, int gpio, u8 val)
-{
-   u8 reg;
-
-   reg = gpio - PCF50633_GPIO1 + PCF50633_REG_GPIO1CFG;
-
-   return pcf50633_reg_set_bit_mask(pcf, reg, 0x07, val);
-}
-EXPORT_SYMBOL_GPL(pcf50633_gpio_set);
-
-u8 pcf50633_gpio_get(struct pcf50633 *pcf, int gpio)
-{
-   u8 reg, val;
-
-   reg = gpio - PCF50633_GPIO1 + PCF50633_REG_GPIO1CFG;
-   val = pcf50633_reg_read(pcf, reg) & 0x07;
-
-   return val;
-}
-EXPORT_SYMBOL_GPL(pcf50633_gpio_get);
-
-int pcf50633_gpio_invert_set(struct pcf50633 *pcf, int gpio, int invert)
-{
-   u8 val, reg;
-
-   reg = gpio - PCF50633_GPIO1 + PCF50633_REG_GPIO1CFG;
-   val = !!invert << 3;
-
-   return pcf50633_reg_set_bit_mask(pcf, reg, 1 << 3, val);
-}
-EXPORT_SYMBOL_GPL(pcf50633_gpio_invert_set);
-
-int pcf50633_gpio_invert_get(struct pcf50633 *pcf, int gpio)
-{
-   u8 reg, val;
-
-   reg = gpio - PCF50633_GPIO1 + PCF50633_REG_GPIO1CFG;
-   val = pcf50633_reg_read(pcf, reg);
-
-   return val & (1 << 3);
-}
-EXPORT_SYMBOL_GPL(pcf50633_gpio_invert_get);
-
-int pcf50633_gpio_power_supply_set(struct pcf50633 *pcf,
-   int gpio, int regulator, int on)
-{
-   u8 reg, val, mask;
-
-   /* the *ENA register is always one after the *OUT register */
-   reg = pcf50633_regulator_registers[regulat

[PATCH 5/9] Input: pcf50633-input - Remove

2025-03-09 Thread linux
From: "Dr. David Alan Gilbert" 

The pcf50633 was used as part of the OpenMoko devices but
the support for its main chip was recently removed in:
commit 61b7f8920b17 ("ARM: s3c: remove all s3c24xx support")

See https://lore.kernel.org/all/Z8z236h4B5A6Ki3D@gallifrey/

Remove it.

Signed-off-by: Dr. David Alan Gilbert 
---
 drivers/input/misc/Kconfig  |   7 --
 drivers/input/misc/Makefile |   1 -
 drivers/input/misc/pcf50633-input.c | 113 
 drivers/mfd/pcf50633-core.c |   2 -
 include/linux/mfd/pcf50633/core.h   |   1 -
 5 files changed, 124 deletions(-)
 delete mode 100644 drivers/input/misc/pcf50633-input.c

diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig
index 13d135257e06..62819144bd8c 100644
--- a/drivers/input/misc/Kconfig
+++ b/drivers/input/misc/Kconfig
@@ -584,13 +584,6 @@ config INPUT_PALMAS_PWRBUTTON
  To compile this driver as a module, choose M here. The module will
  be called palmas_pwrbutton.
 
-config INPUT_PCF50633_PMU
-   tristate "PCF50633 PMU events"
-   depends on MFD_PCF50633
-   help
-Say Y to include support for delivering  PMU events via  input
-layer on NXP PCF50633.
-
 config INPUT_PCF8574
tristate "PCF8574 Keypad input device"
depends on I2C
diff --git a/drivers/input/misc/Makefile b/drivers/input/misc/Makefile
index 6d91804d0a6f..d468c8140b93 100644
--- a/drivers/input/misc/Makefile
+++ b/drivers/input/misc/Makefile
@@ -59,7 +59,6 @@ obj-$(CONFIG_INPUT_MC13783_PWRBUTTON) += mc13783-pwrbutton.o
 obj-$(CONFIG_INPUT_MMA8450)+= mma8450.o
 obj-$(CONFIG_INPUT_PALMAS_PWRBUTTON)   += palmas-pwrbutton.o
 obj-$(CONFIG_INPUT_PCAP)   += pcap_keys.o
-obj-$(CONFIG_INPUT_PCF50633_PMU)   += pcf50633-input.o
 obj-$(CONFIG_INPUT_PCF8574)+= pcf8574_keypad.o
 obj-$(CONFIG_INPUT_PCSPKR) += pcspkr.o
 obj-$(CONFIG_INPUT_PM8941_PWRKEY)  += pm8941-pwrkey.o
diff --git a/drivers/input/misc/pcf50633-input.c 
b/drivers/input/misc/pcf50633-input.c
deleted file mode 100644
index 6d046e236ba6..
--- a/drivers/input/misc/pcf50633-input.c
+++ /dev/null
@@ -1,113 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0-or-later
-/* NXP PCF50633 Input Driver
- *
- * (C) 2006-2008 by Openmoko, Inc.
- * Author: Balaji Rao 
- * All rights reserved.
- *
- * Broken down from monstrous PCF50633 driver mainly by
- * Harald Welte, Andy Green and Werner Almesberger
- */
-
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-
-#include 
-
-#define PCF50633_OOCSTAT_ONKEY 0x01
-#define PCF50633_REG_OOCSTAT   0x12
-#define PCF50633_REG_OOCMODE   0x10
-
-struct pcf50633_input {
-   struct pcf50633 *pcf;
-   struct input_dev *input_dev;
-};
-
-static void
-pcf50633_input_irq(int irq, void *data)
-{
-   struct pcf50633_input *input;
-   int onkey_released;
-
-   input = data;
-
-   /* We report only one event depending on the key press status */
-   onkey_released = pcf50633_reg_read(input->pcf, PCF50633_REG_OOCSTAT)
-   & PCF50633_OOCSTAT_ONKEY;
-
-   if (irq == PCF50633_IRQ_ONKEYF && !onkey_released)
-   input_report_key(input->input_dev, KEY_POWER, 1);
-   else if (irq == PCF50633_IRQ_ONKEYR && onkey_released)
-   input_report_key(input->input_dev, KEY_POWER, 0);
-
-   input_sync(input->input_dev);
-}
-
-static int pcf50633_input_probe(struct platform_device *pdev)
-{
-   struct pcf50633_input *input;
-   struct input_dev *input_dev;
-   int ret;
-
-
-   input = kzalloc(sizeof(*input), GFP_KERNEL);
-   if (!input)
-   return -ENOMEM;
-
-   input_dev = input_allocate_device();
-   if (!input_dev) {
-   kfree(input);
-   return -ENOMEM;
-   }
-
-   platform_set_drvdata(pdev, input);
-   input->pcf = dev_to_pcf50633(pdev->dev.parent);
-   input->input_dev = input_dev;
-
-   input_dev->name = "PCF50633 PMU events";
-   input_dev->id.bustype = BUS_I2C;
-   input_dev->evbit[0] = BIT(EV_KEY) | BIT(EV_PWR);
-   set_bit(KEY_POWER, input_dev->keybit);
-
-   ret = input_register_device(input_dev);
-   if (ret) {
-   input_free_device(input_dev);
-   kfree(input);
-   return ret;
-   }
-   pcf50633_register_irq(input->pcf, PCF50633_IRQ_ONKEYR,
-   pcf50633_input_irq, input);
-   pcf50633_register_irq(input->pcf, PCF50633_IRQ_ONKEYF,
-   pcf50633_input_irq, input);
-
-   return 0;
-}
-
-static void pcf50633_input_remove(struct platform_device *pdev)
-{
-   struct pcf50633_input *input  = platform_get_drvdata(pdev);
-
-   pcf50633_free_irq(input->pcf, PCF50633_IRQ_ONKEYR);
-   pcf50633_free_irq(input->pcf, PCF50633_IRQ_ONKEYF);
-
-   input_unregister_device(input->input_dev);
-   kfree(input);
-}
-
-static s

Re: [PATCH v2] fbdev: fsl-diu-fb: add missing device_remove_file()

2025-03-09 Thread Helge Deller

On 3/9/25 09:16, Shixiong Ou wrote:

From: Shixiong Ou 

Call device_remove_file() when driver remove.

Signed-off-by: Shixiong Ou 
---
v1->v2:
add has_sysfs_attrs flag.

  drivers/video/fbdev/fsl-diu-fb.c | 6 ++
  1 file changed, 6 insertions(+)

diff --git a/drivers/video/fbdev/fsl-diu-fb.c b/drivers/video/fbdev/fsl-diu-fb.c
index 5ac8201c3533..57f7fe6a4c76 100644
--- a/drivers/video/fbdev/fsl-diu-fb.c
+++ b/drivers/video/fbdev/fsl-diu-fb.c
@@ -384,6 +384,7 @@ struct fsl_diu_data {
__le16 next_cursor[MAX_CURS * MAX_CURS] __aligned(32);
uint8_t edid_data[EDID_LENGTH];
bool has_edid;
+   bool has_dev_attr;
  } __aligned(32);

  /* Determine the DMA address of a member of the fsl_diu_data structure */
@@ -1809,6 +1810,7 @@ static int fsl_diu_probe(struct platform_device *pdev)
data->dev_attr.attr.name);
}

+   data->has_dev_attr = true;
dev_set_drvdata(&pdev->dev, data);
return 0;

@@ -1827,6 +1829,10 @@ static void fsl_diu_remove(struct platform_device *pdev)
int i;

data = dev_get_drvdata(&pdev->dev);
+
+   if (data->has_dev_attr)


Looking at other drivers (e.g. drivers/net/can/usb/esd_usb.c) it seems
that device_remove_file() is ok even if it's not fully initialized...

I think you can drop those extra checks.

Helge



+   device_remove_file(&pdev->dev, &data->dev_attr);
+
disable_lcdc(&data->fsl_diu_info[0]);

free_irq(data->irq, data->diu_reg);




Re: [PATCH] drm/vc4: plane: fix inconsistent indenting warning

2025-03-09 Thread Maíra Canal

Hi Charles,

On 05/03/25 07:21, Charles Han wrote:

Fix below inconsistent indenting smatch warning.
smatch warnings:
drivers/gpu/drm/vc4/vc4_plane.c:2083 vc6_plane_mode_set() warn: inconsistent 
indenting

Signed-off-by: Charles Han 


Applied to misc/kernel.git (drm-misc-next).

Best Regards,
- Maíra


---
  drivers/gpu/drm/vc4/vc4_plane.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/vc4/vc4_plane.c b/drivers/gpu/drm/vc4/vc4_plane.c
index c5e84d3494d2..056d344c5411 100644
--- a/drivers/gpu/drm/vc4/vc4_plane.c
+++ b/drivers/gpu/drm/vc4/vc4_plane.c
@@ -2080,7 +2080,7 @@ static int vc6_plane_mode_set(struct drm_plane *plane,
/* HPPF plane 1 */
vc4_dlist_write(vc4_state, kernel);
/* VPPF plane 1 */
-   vc4_dlist_write(vc4_state, kernel);
+   vc4_dlist_write(vc4_state, kernel);
}
}
  




Re: [PATCH v3 0/5] Check Rust signatures at compile time

2025-03-09 Thread Miguel Ojeda
On Mon, Mar 3, 2025 at 9:45 AM Alice Ryhl  wrote:
>
> Rust has two different tools for generating function declarations to
> call across the FFI boundary:
>
> * bindgen. Generates Rust declarations from a C header.
> * cbindgen. Generates C headers from Rust declarations.
>
> However, we only use bindgen in the kernel. This means that when C code
> calls a Rust function by name, its signature must be duplicated in both
> Rust code and a C header, and the signature needs to be kept in sync
> manually.
>
> Introducing cbindgen as a mandatory dependency to build the kernel would
> be a rather complex and large change, so we do not consider that at this
> time. Instead, to eliminate this manual checking, introduce a new macro
> that verifies at compile time that the two function declarations use the
> same signature. The idea is to run the C declaration through bindgen,
> and then have rustc verify that the function pointers have the same
> type.
>
> The signature must still be written twice, but at least you can no
> longer get it wrong. If the signatures don't match, you will get errors
> that look like this:
>
> error[E0308]: `if` and `else` have incompatible types
>   --> /rust/kernel/print.rs:22:22
>|
> 21 | #[export]
>| - expected because of this
> 22 | unsafe extern "C" fn rust_fmt_argument(
>|  ^ expected `u8`, found `i8`
>|
>= note: expected fn item `unsafe extern "C" fn(*mut u8, *mut u8, *mut 
> c_void) -> *mut u8 {bindings::rust_fmt_argument}`
>   found fn item `unsafe extern "C" fn(*mut i8, *mut i8, *const 
> c_void) -> *mut i8 {print::rust_fmt_argument}`
>
> It is unfortunate that the error message starts out by saying "`if` and
> `else` have incompatible types", but I believe the rest of the error
> message is reasonably clear and not too confusing.
>
> The main commit of this series is "rust: add #[export] macro".
>
> Signed-off-by: Alice Ryhl 

Applied to `rust-next` -- thanks everyone!

[ Removed period as requested by Andy. - Miguel ]

[ Fixed `rustfmt`. Moved on top the unsafe requirement comment to follow
  the usual style, and slightly reworded it for clarity. Formatted
  bindings helper comment. - Miguel ]

Cheers,
Miguel


[PATCH 7/9] power: supply: pcf50633: Remove charger

2025-03-09 Thread linux
From: "Dr. David Alan Gilbert" 

The pcf50633 was used as part of the OpenMoko devices but
the support for its main chip was recently removed in:
commit 61b7f8920b17 ("ARM: s3c: remove all s3c24xx support")

See https://lore.kernel.org/all/Z8z236h4B5A6Ki3D@gallifrey/

Remove it.

Signed-off-by: Dr. David Alan Gilbert 
---
 drivers/power/supply/Kconfig|   6 -
 drivers/power/supply/Makefile   |   1 -
 drivers/power/supply/pcf50633-charger.c | 466 
 3 files changed, 473 deletions(-)
 delete mode 100644 drivers/power/supply/pcf50633-charger.c

diff --git a/drivers/power/supply/Kconfig b/drivers/power/supply/Kconfig
index 7b18358f194a..aa569badaf73 100644
--- a/drivers/power/supply/Kconfig
+++ b/drivers/power/supply/Kconfig
@@ -449,12 +449,6 @@ config CHARGER_88PM860X
help
  Say Y here to enable charger for Marvell 88PM860x chip.
 
-config CHARGER_PCF50633
-   tristate "NXP PCF50633 MBC"
-   depends on MFD_PCF50633
-   help
- Say Y to include support for NXP PCF50633 Main Battery Charger.
-
 config BATTERY_RX51
tristate "Nokia RX-51 (N900) battery driver"
depends on TWL4030_MADC
diff --git a/drivers/power/supply/Makefile b/drivers/power/supply/Makefile
index b55cc48a4c86..eedb00e377cb 100644
--- a/drivers/power/supply/Makefile
+++ b/drivers/power/supply/Makefile
@@ -62,7 +62,6 @@ obj-$(CONFIG_CHARGER_RT9467)  += rt9467-charger.o
 obj-$(CONFIG_CHARGER_RT9471)   += rt9471.o
 obj-$(CONFIG_BATTERY_TWL4030_MADC) += twl4030_madc_battery.o
 obj-$(CONFIG_CHARGER_88PM860X) += 88pm860x_charger.o
-obj-$(CONFIG_CHARGER_PCF50633) += pcf50633-charger.o
 obj-$(CONFIG_BATTERY_RX51) += rx51_battery.o
 obj-$(CONFIG_AB8500_BM)+= ab8500_bmdata.o ab8500_charger.o 
ab8500_fg.o ab8500_btemp.o ab8500_chargalg.o
 obj-$(CONFIG_CHARGER_CPCAP)+= cpcap-charger.o
diff --git a/drivers/power/supply/pcf50633-charger.c 
b/drivers/power/supply/pcf50633-charger.c
deleted file mode 100644
index 0136bc87b105..
--- a/drivers/power/supply/pcf50633-charger.c
+++ /dev/null
@@ -1,466 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0-or-later
-/* NXP PCF50633 Main Battery Charger Driver
- *
- * (C) 2006-2008 by Openmoko, Inc.
- * Author: Balaji Rao 
- * All rights reserved.
- *
- * Broken down from monstrous PCF50633 driver mainly by
- * Harald Welte, Andy Green and Werner Almesberger
- */
-
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-
-#include 
-#include 
-
-struct pcf50633_mbc {
-   struct pcf50633 *pcf;
-
-   int adapter_online;
-   int usb_online;
-
-   struct power_supply *usb;
-   struct power_supply *adapter;
-   struct power_supply *ac;
-};
-
-int pcf50633_mbc_usb_curlim_set(struct pcf50633 *pcf, int ma)
-{
-   struct pcf50633_mbc *mbc = platform_get_drvdata(pcf->mbc_pdev);
-   int ret = 0;
-   u8 bits;
-   u8 mbcs2, chgmod;
-   unsigned int mbcc5;
-
-   if (ma >= 1000) {
-   bits = PCF50633_MBCC7_USB_1000mA;
-   ma = 1000;
-   } else if (ma >= 500) {
-   bits = PCF50633_MBCC7_USB_500mA;
-   ma = 500;
-   } else if (ma >= 100) {
-   bits = PCF50633_MBCC7_USB_100mA;
-   ma = 100;
-   } else {
-   bits = PCF50633_MBCC7_USB_SUSPEND;
-   ma = 0;
-   }
-
-   ret = pcf50633_reg_set_bit_mask(pcf, PCF50633_REG_MBCC7,
-   PCF50633_MBCC7_USB_MASK, bits);
-   if (ret)
-   dev_err(pcf->dev, "error setting usb curlim to %d mA\n", ma);
-   else
-   dev_info(pcf->dev, "usb curlim to %d mA\n", ma);
-
-   /*
-* We limit the charging current to be the USB current limit.
-* The reason is that on pcf50633, when it enters PMU Standby mode,
-* which it does when the device goes "off", the USB current limit
-* reverts to the variant default.  In at least one common case, that
-* default is 500mA.  By setting the charging current to be the same
-* as the USB limit we set here before PMU standby, we enforce it only
-* using the correct amount of current even when the USB current limit
-* gets reset to the wrong thing
-*/
-
-   if (mbc->pcf->pdata->charger_reference_current_ma) {
-   mbcc5 = (ma << 8) / 
mbc->pcf->pdata->charger_reference_current_ma;
-   if (mbcc5 > 255)
-   mbcc5 = 255;
-   pcf50633_reg_write(mbc->pcf, PCF50633_REG_MBCC5, mbcc5);
-   }
-
-   mbcs2 = pcf50633_reg_read(mbc->pcf, PCF50633_REG_MBCS2);
-   chgmod = (mbcs2 & PCF50633_MBCS2_MBC_MASK);
-
-   /* If chgmod == BATFULL, setting chgena has no effect.
-* Datasheet says we need to set resume instead but when autoresume is
-* used resume doesn't work. Clear and set chgena instead.
-*/
-   if (chgmod != PCF50633_MBC

Re: [PATCH 0/6] Add support for RK3588 DisplayPort Controller

2025-03-09 Thread Piotr Oniszczuk



> Wiadomość napisana przez Andy Yan  w dniu 7 mar 2025, o 
> godz. 01:48:
> 
> 
> Hi Piotr,
> 在 2025-03-06 22:28:08,"Piotr Oniszczuk"  写道:
>> 
>> 
> 
> All dump information currently appears to be correct, so I'm temporarily 
> unsure why
> there is no display on the monitor.
> Maybe try some plug and unplug for the DP cable, or try another cable or 
> monitor?
> 
> It seems that this board uses a DP to HDMI converter? Does this transmitter 
> need a driver?
> 
> I won't be at my computer over the next two or three days, so any further 
> replies to your email
> might have to wait until next week.
> 
> 

Andy,
FYI:

I done test on mine rock5a with applied Naoki dp0 enablement in dts (and only 
in dts).
No any changes in dw dp driver (so i’m on vanilla  
https://patchwork.kernel.org/project/linux-rockchip/cover/20250223113036.74252-1-andys...@163.com/
   )

on mine rock5a ra620 hdmi port works ok.
(I contacted also Radxa about ra620 and they confirmed: ra620 is just DP->HDMI 
converter. No any driver nor special programming/enablement is needed)

This tells me that dp0 (rock5a) works ok while dp1 (rock5itx) not.
i suspect issue is probably in 
https://patchwork.kernel.org/project/linux-rockchip/cover/20250223113036.74252-1-andys...@163.com/
 and is related to dp1 handling?

BTW: there seems to be issue with video modes handling on dp0 port: 
-playing video 1920@1080@50 - ok
-playing then video1920@1080@59,64 hangs board….

hdmi0 works ok. video modes issue is only on dp0





[PATCH v6 drm-dp 8/9] drm/hisilicon/hibmc: Add MSI irq getting and requesting for HPD

2025-03-09 Thread Yongbang Shi
From: Baihan Li 

To realize HPD feature, request irq for HPD , add its handler function.
We use pci_alloc_irq_vectors() to get our msi irq, because we have two
interrupts now.

Signed-off-by: Baihan Li 
Signed-off-by: Yongbang Shi 
Reviewed-by: Dmitry Baryshkov 
---
ChangeLog:
v4 -> v5:
  - remove pci_disable_msi() in hibmc_unload()
---
 drivers/gpu/drm/hisilicon/hibmc/dp/dp_reg.h   |  3 +
 .../gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c   | 74 +++
 .../gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h   |  3 +
 3 files changed, 66 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/hisilicon/hibmc/dp/dp_reg.h 
b/drivers/gpu/drm/hisilicon/hibmc/dp/dp_reg.h
index 5614b727a710..394b1e933c3a 100644
--- a/drivers/gpu/drm/hisilicon/hibmc/dp/dp_reg.h
+++ b/drivers/gpu/drm/hisilicon/hibmc/dp/dp_reg.h
@@ -99,6 +99,9 @@
 
 #define HIBMC_DP_TIMING_SYNC_CTRL  0xFF0
 
+#define HIBMC_DP_INTSTAT   0x1e0724
+#define HIBMC_DP_INTCLR0x1e0728
+
 /* dp serdes reg */
 #define HIBMC_DP_HOST_OFFSET   0x1
 #define HIBMC_DP_LANE0_RATE_OFFSET 0x4
diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c 
b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
index 98b01c8aee8e..768b97f9e74a 100644
--- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
+++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
@@ -32,6 +32,8 @@
 
 DEFINE_DRM_GEM_FOPS(hibmc_fops);
 
+static const char *g_irqs_names_map[HIBMC_MAX_VECTORS] = { "vblank", "hpd" };
+
 static irqreturn_t hibmc_interrupt(int irq, void *arg)
 {
struct drm_device *dev = (struct drm_device *)arg;
@@ -49,6 +51,22 @@ static irqreturn_t hibmc_interrupt(int irq, void *arg)
return IRQ_HANDLED;
 }
 
+static irqreturn_t hibmc_dp_interrupt(int irq, void *arg)
+{
+   struct drm_device *dev = (struct drm_device *)arg;
+   struct hibmc_drm_private *priv = to_hibmc_drm_private(dev);
+   u32 status;
+
+   status = readl(priv->mmio + HIBMC_DP_INTSTAT);
+   if (status) {
+   priv->dp.irq_status = status;
+   writel(status, priv->mmio + HIBMC_DP_INTCLR);
+   return IRQ_WAKE_THREAD;
+   }
+
+   return IRQ_HANDLED;
+}
+
 static int hibmc_dumb_create(struct drm_file *file, struct drm_device *dev,
 struct drm_mode_create_dumb *args)
 {
@@ -251,15 +269,48 @@ static int hibmc_hw_init(struct hibmc_drm_private *priv)
return 0;
 }
 
-static int hibmc_unload(struct drm_device *dev)
+static void hibmc_unload(struct drm_device *dev)
 {
-   struct pci_dev *pdev = to_pci_dev(dev->dev);
-
drm_atomic_helper_shutdown(dev);
+}
 
-   free_irq(pdev->irq, dev);
+static int hibmc_msi_init(struct drm_device *dev)
+{
+   struct pci_dev *pdev = to_pci_dev(dev->dev);
+   char name[32] = {0};
+   int valid_irq_num;
+   int irq;
+   int ret;
 
-   pci_disable_msi(to_pci_dev(dev->dev));
+   ret = pci_alloc_irq_vectors(pdev, HIBMC_MIN_VECTORS,
+   HIBMC_MAX_VECTORS, PCI_IRQ_MSI);
+   if (ret < 0) {
+   drm_err(dev, "enabling MSI failed: %d\n", ret);
+   return ret;
+   }
+
+   valid_irq_num = ret;
+
+   for (int i = 0; i < valid_irq_num; i++) {
+   snprintf(name, ARRAY_SIZE(name) - 1, "%s-%s-%s",
+dev->driver->name, pci_name(pdev), 
g_irqs_names_map[i]);
+
+   irq = pci_irq_vector(pdev, i);
+
+   if (i)
+   /* PCI devices require shared interrupts. */
+   ret = devm_request_threaded_irq(&pdev->dev, irq,
+   hibmc_dp_interrupt,
+   hibmc_dp_hpd_isr,
+   IRQF_SHARED, name, dev);
+   else
+   ret = devm_request_irq(&pdev->dev, irq, hibmc_interrupt,
+  IRQF_SHARED, name, dev);
+   if (ret) {
+   drm_err(dev, "install irq failed: %d\n", ret);
+   return ret;
+   }
+   }
 
return 0;
 }
@@ -291,15 +342,10 @@ static int hibmc_load(struct drm_device *dev)
goto err;
}
 
-   ret = pci_enable_msi(pdev);
+   ret = hibmc_msi_init(dev);
if (ret) {
-   drm_warn(dev, "enabling MSI failed: %d\n", ret);
-   } else {
-   /* PCI devices require shared interrupts. */
-   ret = request_irq(pdev->irq, hibmc_interrupt, IRQF_SHARED,
- dev->driver->name, dev);
-   if (ret)
-   drm_warn(dev, "install irq failed: %d\n", ret);
+   drm_err(dev, "hibmc msi init failed, ret:%d\n", ret);
+   goto err;
}
 
/* reset all the states of crtc/plane/encoder/connector */

[PATCH v6 drm-dp 5/9] drm/hisilicon/hibmc: Getting connector info and EDID by using AUX channel

2025-03-09 Thread Yongbang Shi
From: Baihan Li 

Add registering drm_aux and use it to get connector edid with drm
functions. Add ddc channel in connector initialization to put drm_aux
in drm_connector.

Signed-off-by: Baihan Li 
Signed-off-by: Yongbang Shi 
Reviewed-by: Dmitry Baryshkov 
---
ChangeLog:
v5 -> v6:
  - move the detect_ctx() to the patch 7/9.
v2 -> v3:
  - Capitalized EDID and AUX, suggested by Dmitry Baryshkov.
v1 -> v2:
  - deleting type conversion, suggested by Dmitry Baryshkov.
  - deleting hibmc_dp_connector_get_modes() and using 
drm_connector_helper_get_modes(), suggested by Dmitry Baryshkov.
---
 drivers/gpu/drm/hisilicon/hibmc/dp/dp_aux.c   |  3 +-
 .../gpu/drm/hisilicon/hibmc/hibmc_drm_dp.c| 32 ---
 .../gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h   |  5 +++
 3 files changed, 34 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/hisilicon/hibmc/dp/dp_aux.c 
b/drivers/gpu/drm/hisilicon/hibmc/dp/dp_aux.c
index ded9e7ce887a..e0bb9b14d9d8 100644
--- a/drivers/gpu/drm/hisilicon/hibmc/dp/dp_aux.c
+++ b/drivers/gpu/drm/hisilicon/hibmc/dp/dp_aux.c
@@ -161,7 +161,8 @@ void hibmc_dp_aux_init(struct hibmc_dp *dp)
 HIBMC_DP_MIN_PULSE_NUM);
 
dp->aux.transfer = hibmc_dp_aux_xfer;
-   dp->aux.is_remote = 0;
+   dp->aux.name = kasprintf(GFP_KERNEL, "HIBMC DRM dp aux");
+   dp->aux.drm_dev = dp->drm_dev;
drm_dp_aux_init(&dp->aux);
dp->dp_dev->aux = &dp->aux;
 }
diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_dp.c 
b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_dp.c
index 603d6b198a54..891fde237c16 100644
--- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_dp.c
+++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_dp.c
@@ -15,11 +15,17 @@
 
 static int hibmc_dp_connector_get_modes(struct drm_connector *connector)
 {
+   struct hibmc_dp *dp = to_hibmc_dp(connector);
+   const struct drm_edid *drm_edid;
int count;
 
-   count = drm_add_modes_noedid(connector, 
connector->dev->mode_config.max_width,
-connector->dev->mode_config.max_height);
-   drm_set_preferred_mode(connector, 1024, 768); // temporary 
implementation
+   drm_edid = drm_edid_read_ddc(connector, &dp->aux.ddc);
+
+   drm_edid_connector_update(connector, drm_edid);
+
+   count = drm_edid_connector_add_modes(connector);
+
+   drm_edid_free(drm_edid);
 
return count;
 }
@@ -28,12 +34,28 @@ static const struct drm_connector_helper_funcs 
hibmc_dp_conn_helper_funcs = {
.get_modes = hibmc_dp_connector_get_modes,
 };
 
+static int hibmc_dp_late_register(struct drm_connector *connector)
+{
+   struct hibmc_dp *dp = to_hibmc_dp(connector);
+
+   return drm_dp_aux_register(&dp->aux);
+}
+
+static void hibmc_dp_early_unregister(struct drm_connector *connector)
+{
+   struct hibmc_dp *dp = to_hibmc_dp(connector);
+
+   drm_dp_aux_unregister(&dp->aux);
+}
+
 static const struct drm_connector_funcs hibmc_dp_conn_funcs = {
.reset = drm_atomic_helper_connector_reset,
.fill_modes = drm_helper_probe_single_connector_modes,
.destroy = drm_connector_cleanup,
.atomic_duplicate_state = drm_atomic_helper_connector_duplicate_state,
.atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
+   .late_register = hibmc_dp_late_register,
+   .early_unregister = hibmc_dp_early_unregister,
 };
 
 static inline int hibmc_dp_prepare(struct hibmc_dp *dp, struct 
drm_display_mode *mode)
@@ -103,8 +125,8 @@ int hibmc_dp_init(struct hibmc_drm_private *priv)
 
drm_encoder_helper_add(encoder, &hibmc_dp_encoder_helper_funcs);
 
-   ret = drm_connector_init(dev, connector, &hibmc_dp_conn_funcs,
-DRM_MODE_CONNECTOR_DisplayPort);
+   ret = drm_connector_init_with_ddc(dev, connector, &hibmc_dp_conn_funcs,
+ DRM_MODE_CONNECTOR_DisplayPort, 
&dp->aux.ddc);
if (ret) {
drm_err(dev, "init dp connector failed: %d\n", ret);
return ret;
diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h 
b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h
index d982f1e4b958..3ddd71aada66 100644
--- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h
+++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h
@@ -47,6 +47,11 @@ static inline struct hibmc_vdac *to_hibmc_vdac(struct 
drm_connector *connector)
return container_of(connector, struct hibmc_vdac, connector);
 }
 
+static inline struct hibmc_dp *to_hibmc_dp(struct drm_connector *connector)
+{
+   return container_of(connector, struct hibmc_dp, connector);
+}
+
 static inline struct hibmc_drm_private *to_hibmc_drm_private(struct drm_device 
*dev)
 {
return container_of(dev, struct hibmc_drm_private, dev);
-- 
2.33.0



[PATCH v6 drm-dp 7/9] drm/hisilicon/hibmc: Enable this hot plug detect of irq feature

2025-03-09 Thread Yongbang Shi
From: Baihan Li 

Add HPD interrupt enable functions in drm framework, and also add
detect_ctx functions. Because of the debouncing when HPD pulled out,
add 200 ms delay in detect_ctx(). Add link reset process to reset link
status when a new connector pulgged in.

Signed-off-by: Baihan Li 
Signed-off-by: Yongbang Shi 
---
ChangeLog:
v5 -> v6:
  - add detect_ctx with 200ms delay, suggested by Dmitry Baryshkov.
v4 -> v5:
  - separate the vga part commit, suggested by Dmitry Baryshkov.
v3 -> v4:
  - add link reset of rates and lanes in pre link training process, suggested 
by Dmitry Baryshkov.
  - add vdac detect and connected/disconnected status to enable HPD process, 
suggested by Dmitry Baryshkov.
  - remove a drm_client, suggested by Dmitry Baryshkov.
  - fix build errors reported by kernel test robot 
Closes: 
https://lore.kernel.org/oe-kbuild-all/202502231304.bczv4y8d-...@intel.com/
v2 -> v3:
  - remove mdelay(100) hpd function in ISR, suggested by Dmitry Baryshkov.
  - remove enble_display in ISR, suggested by Dmitry Baryshkov.
  - change drm_kms_helper_connector_hotplug_event() to
drm_connector_helper_hpd_irq_event(), suggested by Dmitry Baryshkov.
  - move macros to dp_reg.h, suggested by Dmitry Baryshkov.
  - remove struct irqs, suggested by Dmitry Baryshkov.
  - split this patch into two parts, suggested by Dmitry Baryshkov.
  - add a drm client dev to handle HPD event.
v1 -> v2:
  - optimizing the description in commit message, suggested by Dmitry Baryshkov.
  - add mdelay(100) comments, suggested by Dmitry Baryshkov.
  - deleting display enable in hpd event, suggested by Dmitry Baryshkov.
---
 .../gpu/drm/hisilicon/hibmc/dp/dp_config.h|  1 +
 drivers/gpu/drm/hisilicon/hibmc/dp/dp_hw.c| 36 
 drivers/gpu/drm/hisilicon/hibmc/dp/dp_hw.h|  5 +++
 .../gpu/drm/hisilicon/hibmc/hibmc_drm_dp.c| 42 +++
 .../gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h   |  2 +
 5 files changed, 86 insertions(+)

diff --git a/drivers/gpu/drm/hisilicon/hibmc/dp/dp_config.h 
b/drivers/gpu/drm/hisilicon/hibmc/dp/dp_config.h
index c5feef8dc27d..08f9e1caf7fc 100644
--- a/drivers/gpu/drm/hisilicon/hibmc/dp/dp_config.h
+++ b/drivers/gpu/drm/hisilicon/hibmc/dp/dp_config.h
@@ -16,5 +16,6 @@
 #define HIBMC_DP_SYNC_EN_MASK  0x3
 #define HIBMC_DP_LINK_RATE_CAL 27
 #define HIBMC_DP_SYNC_DELAY(lanes) ((lanes) == 0x2 ? 86 : 46)
+#define HIBMC_DP_INT_ENABLE0xc
 
 #endif
diff --git a/drivers/gpu/drm/hisilicon/hibmc/dp/dp_hw.c 
b/drivers/gpu/drm/hisilicon/hibmc/dp/dp_hw.c
index ce7cb07815b2..8f0daec7d174 100644
--- a/drivers/gpu/drm/hisilicon/hibmc/dp/dp_hw.c
+++ b/drivers/gpu/drm/hisilicon/hibmc/dp/dp_hw.c
@@ -189,6 +189,36 @@ int hibmc_dp_hw_init(struct hibmc_dp *dp)
return 0;
 }
 
+void hibmc_dp_enable_int(struct hibmc_dp *dp)
+{
+   struct hibmc_dp_dev *dp_dev = dp->dp_dev;
+
+   writel(HIBMC_DP_INT_ENABLE, dp_dev->base + HIBMC_DP_INTR_ENABLE);
+}
+
+void hibmc_dp_disable_int(struct hibmc_dp *dp)
+{
+   struct hibmc_dp_dev *dp_dev = dp->dp_dev;
+
+   writel(0, dp_dev->base + HIBMC_DP_INTR_ENABLE);
+   writel(HIBMC_DP_INT_RST, dp_dev->base + HIBMC_DP_INTR_ORIGINAL_STATUS);
+}
+
+void hibmc_dp_hpd_cfg(struct hibmc_dp *dp)
+{
+   struct hibmc_dp_dev *dp_dev = dp->dp_dev;
+
+   hibmc_dp_reg_write_field(dp_dev, HIBMC_DP_AUX_REQ, 
HIBMC_DP_CFG_AUX_SYNC_LEN_SEL, 0x0);
+   hibmc_dp_reg_write_field(dp_dev, HIBMC_DP_AUX_REQ, 
HIBMC_DP_CFG_AUX_TIMER_TIMEOUT, 0x1);
+   hibmc_dp_reg_write_field(dp->dp_dev, HIBMC_DP_AUX_REQ, 
HIBMC_DP_CFG_AUX_MIN_PULSE_NUM, 0x9);
+   writel(HIBMC_DP_HDCP, dp_dev->base + HIBMC_DP_HDCP_CFG);
+   writel(0, dp_dev->base + HIBMC_DP_INTR_ENABLE);
+   writel(HIBMC_DP_INT_RST, dp_dev->base + HIBMC_DP_INTR_ORIGINAL_STATUS);
+   writel(HIBMC_DP_INT_ENABLE, dp_dev->base + HIBMC_DP_INTR_ENABLE);
+   writel(HIBMC_DP_DPTX_RST, dp_dev->base + HIBMC_DP_DPTX_RST_CTRL);
+   writel(HIBMC_DP_CLK_EN, dp_dev->base + HIBMC_DP_DPTX_CLK_CTRL);
+}
+
 void hibmc_dp_display_en(struct hibmc_dp *dp, bool enable)
 {
struct hibmc_dp_dev *dp_dev = dp->dp_dev;
@@ -227,6 +257,12 @@ int hibmc_dp_mode_set(struct hibmc_dp *dp, struct 
drm_display_mode *mode)
return 0;
 }
 
+void hibmc_dp_reset_link(struct hibmc_dp *dp)
+{
+   dp->dp_dev->link.status.clock_recovered = false;
+   dp->dp_dev->link.status.channel_equalized = false;
+}
+
 static const struct hibmc_dp_color_raw g_rgb_raw[] = {
{CBAR_COLOR_BAR, 0x000, 0x000, 0x000},
{CBAR_WHITE, 0xfff, 0xfff, 0xfff},
diff --git a/drivers/gpu/drm/hisilicon/hibmc/dp/dp_hw.h 
b/drivers/gpu/drm/hisilicon/hibmc/dp/dp_hw.h
index 83a53dae8012..665f5b166dfb 100644
--- a/drivers/gpu/drm/hisilicon/hibmc/dp/dp_hw.h
+++ b/drivers/gpu/drm/hisilicon/hibmc/dp/dp_hw.h
@@ -49,11 +49,16 @@ struct hibmc_dp {
void __iomem *mmio;
struct drm_dp_aux aux;
struct hibmc_dp_cbar_cfg cfg;
+   u32 irq_status;
 };
 
 int hi

[PATCH v6 drm-dp 4/9] drm/hisilicon/hibmc: Refactor the member of drm_aux in struct hibmc_dp

2025-03-09 Thread Yongbang Shi
From: Baihan Li 

Because the drm_aux of struct hibmc_dp_dev's member is not easy to get in
hibmc_drm_dp.c, move the drm_aux to struct hibmc_dp. Then there are some
adaptations and modifications to make this patch compile.

Signed-off-by: Baihan Li 
Signed-off-by: Yongbang Shi 
Reviewed-by: Dmitry Baryshkov 
---
ChangeLog:
v3 -> v4:
  - fix the comment log to imperative sentence, suggested by Dmitry Baryshkov.
v2 -> v3:
  - split the patch into two parts, suggested by Dmitry Baryshkov.
---
 drivers/gpu/drm/hisilicon/hibmc/dp/dp_aux.c  | 13 +++-
 drivers/gpu/drm/hisilicon/hibmc/dp/dp_comm.h |  6 --
 drivers/gpu/drm/hisilicon/hibmc/dp/dp_hw.c   |  2 +-
 drivers/gpu/drm/hisilicon/hibmc/dp/dp_hw.h   |  2 ++
 drivers/gpu/drm/hisilicon/hibmc/dp/dp_link.c | 22 ++--
 5 files changed, 26 insertions(+), 19 deletions(-)

diff --git a/drivers/gpu/drm/hisilicon/hibmc/dp/dp_aux.c 
b/drivers/gpu/drm/hisilicon/hibmc/dp/dp_aux.c
index 0a903cce1fa9..ded9e7ce887a 100644
--- a/drivers/gpu/drm/hisilicon/hibmc/dp/dp_aux.c
+++ b/drivers/gpu/drm/hisilicon/hibmc/dp/dp_aux.c
@@ -8,6 +8,7 @@
 #include 
 #include "dp_comm.h"
 #include "dp_reg.h"
+#include "dp_hw.h"
 
 #define HIBMC_AUX_CMD_REQ_LEN  GENMASK(7, 4)
 #define HIBMC_AUX_CMD_ADDR GENMASK(27, 8)
@@ -124,7 +125,8 @@ static int hibmc_dp_aux_parse_xfer(struct hibmc_dp_dev *dp, 
struct drm_dp_aux_ms
 /* ret >= 0 ,ret is size; ret < 0, ret is err code */
 static ssize_t hibmc_dp_aux_xfer(struct drm_dp_aux *aux, struct drm_dp_aux_msg 
*msg)
 {
-   struct hibmc_dp_dev *dp = container_of(aux, struct hibmc_dp_dev, aux);
+   struct hibmc_dp *dp_priv = container_of(aux, struct hibmc_dp, aux);
+   struct hibmc_dp_dev *dp = dp_priv->dp_dev;
u32 aux_cmd;
int ret;
u32 val; /* val will be assigned at the beginning of readl_poll_timeout 
function */
@@ -151,14 +153,15 @@ static ssize_t hibmc_dp_aux_xfer(struct drm_dp_aux *aux, 
struct drm_dp_aux_msg *
return hibmc_dp_aux_parse_xfer(dp, msg);
 }
 
-void hibmc_dp_aux_init(struct hibmc_dp_dev *dp)
+void hibmc_dp_aux_init(struct hibmc_dp *dp)
 {
-   hibmc_dp_reg_write_field(dp, HIBMC_DP_AUX_REQ, 
HIBMC_DP_CFG_AUX_SYNC_LEN_SEL, 0x0);
-   hibmc_dp_reg_write_field(dp, HIBMC_DP_AUX_REQ, 
HIBMC_DP_CFG_AUX_TIMER_TIMEOUT, 0x1);
-   hibmc_dp_reg_write_field(dp, HIBMC_DP_AUX_REQ, 
HIBMC_DP_CFG_AUX_MIN_PULSE_NUM,
+   hibmc_dp_reg_write_field(dp->dp_dev, HIBMC_DP_AUX_REQ, 
HIBMC_DP_CFG_AUX_SYNC_LEN_SEL, 0x0);
+   hibmc_dp_reg_write_field(dp->dp_dev, HIBMC_DP_AUX_REQ, 
HIBMC_DP_CFG_AUX_TIMER_TIMEOUT, 0x1);
+   hibmc_dp_reg_write_field(dp->dp_dev, HIBMC_DP_AUX_REQ, 
HIBMC_DP_CFG_AUX_MIN_PULSE_NUM,
 HIBMC_DP_MIN_PULSE_NUM);
 
dp->aux.transfer = hibmc_dp_aux_xfer;
dp->aux.is_remote = 0;
drm_dp_aux_init(&dp->aux);
+   dp->dp_dev->aux = &dp->aux;
 }
diff --git a/drivers/gpu/drm/hisilicon/hibmc/dp/dp_comm.h 
b/drivers/gpu/drm/hisilicon/hibmc/dp/dp_comm.h
index e0c6a3b7463b..4add05c7f161 100644
--- a/drivers/gpu/drm/hisilicon/hibmc/dp/dp_comm.h
+++ b/drivers/gpu/drm/hisilicon/hibmc/dp/dp_comm.h
@@ -13,6 +13,8 @@
 #include 
 #include 
 
+#include "dp_hw.h"
+
 #define HIBMC_DP_LANE_NUM_MAX 2
 
 struct hibmc_link_status {
@@ -32,7 +34,7 @@ struct hibmc_dp_link {
 };
 
 struct hibmc_dp_dev {
-   struct drm_dp_aux aux;
+   struct drm_dp_aux *aux;
struct drm_device *dev;
void __iomem *base;
struct mutex lock; /* protects concurrent RW in 
hibmc_dp_reg_write_field() */
@@ -58,7 +60,7 @@ struct hibmc_dp_dev {
mutex_unlock(&_dp->lock);   \
} while (0)
 
-void hibmc_dp_aux_init(struct hibmc_dp_dev *dp);
+void hibmc_dp_aux_init(struct hibmc_dp *dp);
 int hibmc_dp_link_training(struct hibmc_dp_dev *dp);
 int hibmc_dp_serdes_init(struct hibmc_dp_dev *dp);
 int hibmc_dp_serdes_rate_switch(u8 rate, struct hibmc_dp_dev *dp);
diff --git a/drivers/gpu/drm/hisilicon/hibmc/dp/dp_hw.c 
b/drivers/gpu/drm/hisilicon/hibmc/dp/dp_hw.c
index dcb2ab5ea6bb..aa9354a996c9 100644
--- a/drivers/gpu/drm/hisilicon/hibmc/dp/dp_hw.c
+++ b/drivers/gpu/drm/hisilicon/hibmc/dp/dp_hw.c
@@ -167,7 +167,7 @@ int hibmc_dp_hw_init(struct hibmc_dp *dp)
dp_dev->dev = drm_dev;
dp_dev->base = dp->mmio + HIBMC_DP_OFFSET;
 
-   hibmc_dp_aux_init(dp_dev);
+   hibmc_dp_aux_init(dp);
 
ret = hibmc_dp_serdes_init(dp_dev);
if (ret)
diff --git a/drivers/gpu/drm/hisilicon/hibmc/dp/dp_hw.h 
b/drivers/gpu/drm/hisilicon/hibmc/dp/dp_hw.h
index 4dc13b3d9875..53b6d0beecea 100644
--- a/drivers/gpu/drm/hisilicon/hibmc/dp/dp_hw.h
+++ b/drivers/gpu/drm/hisilicon/hibmc/dp/dp_hw.h
@@ -10,6 +10,7 @@
 #include 
 #include 
 #include 
+#include 
 
 struct hibmc_dp_dev;
 
@@ -19,6 +20,7 @@ struct hibmc_dp {
struct drm_encoder encoder;
struct drm_connector connector;
void __iomem *mmio;
+   struct drm_dp_aux aux;
 };
 

[PATCH v6 drm-dp 9/9] drm/hisilicon/hibmc: Add vga connector detect functions

2025-03-09 Thread Yongbang Shi
From: Baihan Li 

Because the connected VGA connector would make driver can't get the
userspace call, adding detect_ctx in vga connector to make HPD active
userspace.

Signed-off-by: Baihan Li 
Signed-off-by: Yongbang Shi 
Reviewed-by: Dmitry Baryshkov 
---
 drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_vdac.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_vdac.c 
b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_vdac.c
index 05e19ea4c9f9..e8a527ede854 100644
--- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_vdac.c
+++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_vdac.c
@@ -60,6 +60,7 @@ static void hibmc_connector_destroy(struct drm_connector 
*connector)
 static const struct drm_connector_helper_funcs
hibmc_connector_helper_funcs = {
.get_modes = hibmc_connector_get_modes,
+   .detect_ctx = drm_connector_helper_detect_from_ddc,
 };
 
 static const struct drm_connector_funcs hibmc_connector_funcs = {
@@ -127,5 +128,7 @@ int hibmc_vdac_init(struct hibmc_drm_private *priv)
 
drm_connector_attach_encoder(connector, encoder);
 
+   connector->polled = DRM_CONNECTOR_POLL_CONNECT | 
DRM_CONNECTOR_POLL_DISCONNECT;
+
return 0;
 }
-- 
2.33.0



[PATCH v6 drm-dp 0/9] Add HPD, getting EDID, colorbar features in DP function

2025-03-09 Thread Yongbang Shi
From: Baihan Li 

To support DP HPD, edid printing, and colorbar display features based on
the Hisislcon DP devices.
---
ChangeLog:
v5 -> v6:
  - fix the DP_SERDES_VOL2_PRE0 value after electrical test.
  - move the detect_ctx() to the patch 7/9.
  - add detect_ctx with 200ms delay, suggested by Dmitry Baryshkov.
v4 -> v5:
  - add commit log about hibmc_kms_init(), suggested by Dmitry Baryshkov.
  - fix the format of block comments, suggested by Dmitry Baryshkov.
  - add hibmc_dp_get_serdes_rate_cfg() to correct transferring serdes cfg.
  - separate the vga part commit, suggested by Dmitry Baryshkov.
  - remove pci_disable_msi() in hibmc_unload()
v3 -> v4:
  - fix the serdes cfg in hibmc_dp_serdes_set_tx_cfg(), suggested by Dmitry 
Baryshkov.
  - move the dp serdes registers to dp_reg.h, suggested by Dmitry Baryshkov.
  - add comments for if-statement of dp_init(), suggested by Dmitry Baryshkov.
  - fix the comment log to imperative sentence, suggested by Dmitry Baryshkov.
  - add comments in hibmc_control_write(), suggested by Dmitry Baryshkov.
  - add link reset of rates and lanes in pre link training process, suggested 
by Dmitry Baryshkov.
  - add vdac detect and connected/disconnected status to enable HPD process, 
suggested by Dmitry Baryshkov.
  - remove a drm_client, suggested by Dmitry Baryshkov.
  - fix build errors reported by kernel test robot 
Closes: 
https://lore.kernel.org/oe-kbuild-all/202502231304.bczv4y8d-...@intel.com/
v2 -> v3:
  - restructuring the header p_reg.h, suggested by Dmitry Baryshkov.
  - add commit log about dp serdes, suggested by Dmitry Baryshkov.
  - return value in hibmc_dp_serdes_init(), suggested by Dmitry Baryshkov.
  - add static const in the array of serdes_tx_cfg[], suggested by Dmitry 
Baryshkov.
  - change drm_warn to drm_dbg_dp, suggested by Dmitry Baryshkov.
  - add explanations about dp serdes macros, suggested by Dmitry Baryshkov.
  - change commit to an imperative sentence, suggested by Dmitry Baryshkov.
  - put HIBMC_DP_HOST_SERDES_CTRL in dp_serdes.h, suggested by Dmitry Baryshkov.
  - split the patch into two parts, suggested by Dmitry Baryshkov.
  - Capitalized EDID and AUX, suggested by Dmitry Baryshkov.
  - rewrite the commit log, suggested by Dmitry Baryshkov.
  - move colorbar debugfs entry to this patch, suggested by Dmitry Baryshkov.
  - change binary format to integer format, suggested by Dmitry Baryshkov.
  - remove mdelay(100) hpd function in ISR, suggested by Dmitry Baryshkov.
  - remove enble_display in ISR, suggested by Dmitry Baryshkov.
  - change drm_kms_helper_connector_hotplug_event() to
drm_connector_helper_hpd_irq_event(), suggested by Dmitry Baryshkov.
  - move macros to dp_reg.h, suggested by Dmitry Baryshkov.
  - remove struct irqs, suggested by Dmitry Baryshkov.
  - split this patch into two parts, suggested by Dmitry Baryshkov.
v1 -> v2:
  - splittting the patch and add more detailed the changes in the commit 
message, suggested by Dmitry Baryshkov.
  - changing all names of dp phy to dp serdes.
  - deleting type conversion, suggested by Dmitry Baryshkov.
  - deleting hibmc_dp_connector_get_modes() and using 
drm_connector_helper_get_modes(), suggested by Dmitry Baryshkov.
  - add colorbar introduction in commit, suggested by Dmitry Baryshkov.
  - deleting edid decoder and its debugfs, suggested by Dmitry Baryshkov.
  - using debugfs_init() callback, suggested by Dmitry Baryshkov.
  - splittting colorbar and debugfs in different patches, suggested by Dmitry 
Baryshkov.
  - optimizing the description in commit message, suggested by Dmitry Baryshkov.
  - add mdelay(100) comments, suggested by Dmitry Baryshkov.
  - deleting display enable in hpd event, suggested by Dmitry Baryshkov.
---

Baihan Li (9):
  drm/hisilicon/hibmc: Restructuring the header dp_reg.h
  drm/hisilicon/hibmc: Add dp serdes cfg to adjust serdes rate, voltage
and pre-emphasis
  drm/hisilicon/hibmc: Add dp serdes cfg in dp process
  drm/hisilicon/hibmc: Refactor the member of drm_aux in struct hibmc_dp
  drm/hisilicon/hibmc: Getting connector info and EDID by using AUX
channel
  drm/hisilicon/hibmc: Add colorbar-cfg feature and its debugfs file
  drm/hisilicon/hibmc: Enable this hot plug detect of irq feature
  drm/hisilicon/hibmc: Add MSI irq getting and requesting for HPD
  drm/hisilicon/hibmc: Add vga connector detect functions

 drivers/gpu/drm/hisilicon/hibmc/Makefile  |   3 +-
 drivers/gpu/drm/hisilicon/hibmc/dp/dp_aux.c   |  16 ++-
 drivers/gpu/drm/hisilicon/hibmc/dp/dp_comm.h  |  10 +-
 .../gpu/drm/hisilicon/hibmc/dp/dp_config.h|   2 +
 drivers/gpu/drm/hisilicon/hibmc/dp/dp_hw.c|  91 +++-
 drivers/gpu/drm/hisilicon/hibmc/dp/dp_hw.h|  36 +
 drivers/gpu/drm/hisilicon/hibmc/dp/dp_link.c  |  97 +
 drivers/gpu/drm/hisilicon/hibmc/dp/dp_reg.h   | 130 +-
 .../gpu/drm/hisilicon/hibmc/dp/dp_serdes.c|  71 ++
 .../drm/hisilicon/hibmc/hibmc_drm_debugfs.c   | 104 ++
 .../gpu/

[PATCH v6 drm-dp 1/9] drm/hisilicon/hibmc: Restructuring the header dp_reg.h

2025-03-09 Thread Yongbang Shi
From: Baihan Li 

Move the macros below their corresponding registers to make
them more obvious.

Signed-off-by: Baihan Li 
Signed-off-by: Yongbang Shi 
Reviewed-by: Dmitry Baryshkov 
---
ChangeLog:
v2 -> v3:
  - restructuring the header dp_reg.h, suggested by Dmitry Baryshkov.
---
 drivers/gpu/drm/hisilicon/hibmc/dp/dp_reg.h | 98 +
 1 file changed, 60 insertions(+), 38 deletions(-)

diff --git a/drivers/gpu/drm/hisilicon/hibmc/dp/dp_reg.h 
b/drivers/gpu/drm/hisilicon/hibmc/dp/dp_reg.h
index 4a515c726d52..dc2bd3f80b70 100644
--- a/drivers/gpu/drm/hisilicon/hibmc/dp/dp_reg.h
+++ b/drivers/gpu/drm/hisilicon/hibmc/dp/dp_reg.h
@@ -5,72 +5,94 @@
 #define DP_REG_H
 
 #define HIBMC_DP_AUX_CMD_ADDR  0x50
+
 #define HIBMC_DP_AUX_WR_DATA0  0x54
 #define HIBMC_DP_AUX_WR_DATA1  0x58
 #define HIBMC_DP_AUX_WR_DATA2  0x5c
 #define HIBMC_DP_AUX_WR_DATA3  0x60
 #define HIBMC_DP_AUX_RD_DATA0  0x64
+
 #define HIBMC_DP_AUX_REQ   0x74
+#define HIBMC_DP_CFG_AUX_REQ   BIT(0)
+#define HIBMC_DP_CFG_AUX_SYNC_LEN_SEL  BIT(1)
+#define HIBMC_DP_CFG_AUX_TIMER_TIMEOUT BIT(2)
+#define HIBMC_DP_CFG_AUX_MIN_PULSE_NUM GENMASK(13, 9)
+
 #define HIBMC_DP_AUX_STATUS0x78
+#define HIBMC_DP_CFG_AUX_TIMEOUT   BIT(0)
+#define HIBMC_DP_CFG_AUX_STATUSGENMASK(11, 4)
+#define HIBMC_DP_CFG_AUX_READY_DATA_BYTE   GENMASK(16, 12)
+#define HIBMC_DP_CFG_AUX   GENMASK(24, 17)
+
 #define HIBMC_DP_PHYIF_CTRL0   0xa0
+#define HIBMC_DP_CFG_SCRAMBLE_EN   BIT(0)
+#define HIBMC_DP_CFG_PAT_SEL   GENMASK(7, 4)
+#define HIBMC_DP_CFG_LANE_DATA_EN  GENMASK(11, 8)
+
 #define HIBMC_DP_VIDEO_CTRL0x100
+#define HIBMC_DP_CFG_STREAM_RGB_ENABLE BIT(1)
+#define HIBMC_DP_CFG_STREAM_VIDEO_MAPPING  GENMASK(5, 2)
+#define HIBMC_DP_CFG_STREAM_FRAME_MODE BIT(6)
+#define HIBMC_DP_CFG_STREAM_HSYNC_POLARITY BIT(7)
+#define HIBMC_DP_CFG_STREAM_VSYNC_POLARITY BIT(8)
+
 #define HIBMC_DP_VIDEO_CONFIG0 0x104
+#define HIBMC_DP_CFG_STREAM_HACTIVEGENMASK(31, 16)
+#define HIBMC_DP_CFG_STREAM_HBLANK GENMASK(15, 0)
+
 #define HIBMC_DP_VIDEO_CONFIG1 0x108
+#define HIBMC_DP_CFG_STREAM_VACTIVEGENMASK(31, 16)
+#define HIBMC_DP_CFG_STREAM_VBLANK GENMASK(15, 0)
+
 #define HIBMC_DP_VIDEO_CONFIG2 0x10c
+#define HIBMC_DP_CFG_STREAM_HSYNC_WIDTHGENMASK(15, 0)
+
 #define HIBMC_DP_VIDEO_CONFIG3 0x110
+#define HIBMC_DP_CFG_STREAM_VSYNC_WIDTHGENMASK(15, 0)
+#define HIBMC_DP_CFG_STREAM_VFRONT_PORCH   GENMASK(31, 16)
+
 #define HIBMC_DP_VIDEO_PACKET  0x114
+#define HIBMC_DP_CFG_STREAM_TU_SYMBOL_SIZE GENMASK(5, 0)
+#define HIBMC_DP_CFG_STREAM_TU_SYMBOL_FRAC_SIZEGENMASK(9, 6)
+
 #define HIBMC_DP_VIDEO_MSA00x118
+#define HIBMC_DP_CFG_STREAM_VSTART GENMASK(31, 16)
+#define HIBMC_DP_CFG_STREAM_HSTART GENMASK(15, 0)
+
 #define HIBMC_DP_VIDEO_MSA10x11c
 #define HIBMC_DP_VIDEO_MSA20x120
+
 #define HIBMC_DP_VIDEO_HORIZONTAL_SIZE 0X124
+#define HIBMC_DP_CFG_STREAM_HTOTAL_SIZEGENMASK(31, 16)
+#define HIBMC_DP_CFG_STREAM_HBLANK_SIZEGENMASK(15, 0)
+
 #define HIBMC_DP_TIMING_GEN_CONFIG00x26c
+#define HIBMC_DP_CFG_TIMING_GEN0_HACTIVE   GENMASK(31, 16)
+#define HIBMC_DP_CFG_TIMING_GEN0_HBLANKGENMASK(15, 0)
+
 #define HIBMC_DP_TIMING_GEN_CONFIG20x274
+#define HIBMC_DP_CFG_TIMING_GEN0_VACTIVE   GENMASK(31, 16)
+#define HIBMC_DP_CFG_TIMING_GEN0_VBLANKGENMASK(15, 0)
+
 #define HIBMC_DP_TIMING_GEN_CONFIG30x278
+#define HIBMC_DP_CFG_TIMING_GEN0_VFRONT_PORCH  GENMASK(31, 16)
+
 #define HIBMC_DP_HDCP_CFG  0x600
+
 #define HIBMC_DP_DPTX_RST_CTRL 0x700
+#define HIBMC_DP_CFG_AUX_RST_N BIT(4)
+
 #define HIBMC_DP_DPTX_CLK_CTRL 0x704
+
 #define HIBMC_DP_DPTX_GCTL00x708
+#define HIBMC_DP_CFG_PHY_LANE_NUM  GENMASK(2, 1)
+
 #define HIBMC_DP_INTR_ENABLE   0x720
 #define HIBMC_DP_INTR_ORIGINAL_STATUS  0x728
-#define HIBMC_DP_TIMING_MODEL_CTRL 0x884
-#define HIBMC_DP_TIMING_SYNC_CTRL  0xFF0
 
-#define HIBMC_DP_CFG_AUX_SYNC_LEN_SEL  BIT(1)
-#define HIBMC_DP_CFG_AUX_TIMER_TIMEOUT BIT(2)
-#define HIBMC_DP_CFG_STREAM_FRAME_MODE BIT(6)
-#define HIBMC_DP_CFG_AUX_MIN_PULSE_NUM GENMASK(13, 9)
-#define HIBMC_DP_CFG_LANE_DATA_EN  GENMASK(11, 8)
-#define HIBMC_DP_CFG_PHY_LANE_NUM  GENMASK(2, 1)
-#define HIBMC_DP_CFG_AUX_REQ

[PATCH 1/9] mfd: pcf50633-adc: Remove

2025-03-09 Thread linux
From: "Dr. David Alan Gilbert" 

The pcf50633 was used as part of the OpenMoko devices but
the support for its main chip was recently removed in:
commit 61b7f8920b17 ("ARM: s3c: remove all s3c24xx support")

See https://lore.kernel.org/all/Z8z236h4B5A6Ki3D@gallifrey/

Remove it.

Signed-off-by: Dr. David Alan Gilbert 
---
 arch/mips/configs/ip27_defconfig  |   1 -
 drivers/mfd/Kconfig   |   7 -
 drivers/mfd/Makefile  |   1 -
 drivers/mfd/pcf50633-adc.c| 255 --
 drivers/mfd/pcf50633-core.c   |   2 -
 include/linux/mfd/pcf50633/adc.h  |  69 
 include/linux/mfd/pcf50633/core.h |   1 -
 7 files changed, 336 deletions(-)
 delete mode 100644 drivers/mfd/pcf50633-adc.c
 delete mode 100644 include/linux/mfd/pcf50633/adc.h

diff --git a/arch/mips/configs/ip27_defconfig b/arch/mips/configs/ip27_defconfig
index b08a199767d1..66085bb71bc4 100644
--- a/arch/mips/configs/ip27_defconfig
+++ b/arch/mips/configs/ip27_defconfig
@@ -256,7 +256,6 @@ CONFIG_I2C_STUB=m
 # CONFIG_HWMON is not set
 CONFIG_THERMAL=y
 CONFIG_MFD_PCF50633=m
-CONFIG_PCF50633_ADC=m
 CONFIG_PCF50633_GPIO=m
 # CONFIG_VGA_ARB is not set
 CONFIG_LEDS_LP3944=m
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index 6b0682af6e32..051272126fe1 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -1129,13 +1129,6 @@ config MFD_PCF50633
  facilities, and registers devices for the various functions
  so that function-specific drivers can bind to them.
 
-config PCF50633_ADC
-   tristate "NXP PCF50633 ADC"
-   depends on MFD_PCF50633
-   help
- Say yes here if you want to include support for ADC in the
- NXP PCF50633 chip.
-
 config PCF50633_GPIO
tristate "NXP PCF50633 GPIO"
depends on MFD_PCF50633
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index 9220eaf7cf12..e085da3f13c3 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -185,7 +185,6 @@ obj-$(CONFIG_MFD_MT6397)+= mt6397.o
 
 pcf50633-objs  := pcf50633-core.o pcf50633-irq.o
 obj-$(CONFIG_MFD_PCF50633) += pcf50633.o
-obj-$(CONFIG_PCF50633_ADC) += pcf50633-adc.o
 obj-$(CONFIG_PCF50633_GPIO)+= pcf50633-gpio.o
 obj-$(CONFIG_RZ_MTU3)  += rz-mtu3.o
 obj-$(CONFIG_ABX500_CORE)  += abx500-core.o
diff --git a/drivers/mfd/pcf50633-adc.c b/drivers/mfd/pcf50633-adc.c
deleted file mode 100644
index 1fbba0e666d5..
--- a/drivers/mfd/pcf50633-adc.c
+++ /dev/null
@@ -1,255 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0-or-later
-/* NXP PCF50633 ADC Driver
- *
- * (C) 2006-2008 by Openmoko, Inc.
- * Author: Balaji Rao 
- * All rights reserved.
- *
- * Broken down from monstrous PCF50633 driver mainly by
- * Harald Welte, Andy Green and Werner Almesberger
- *
- *  NOTE: This driver does not yet support subtractive ADC mode, which means
- *  you can do only one measurement per read request.
- */
-
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-
-#include 
-#include 
-
-struct pcf50633_adc_request {
-   int mux;
-   int avg;
-   void (*callback)(struct pcf50633 *, void *, int);
-   void *callback_param;
-};
-
-struct pcf50633_adc_sync_request {
-   int result;
-   struct completion completion;
-};
-
-#define PCF50633_MAX_ADC_FIFO_DEPTH 8
-
-struct pcf50633_adc {
-   struct pcf50633 *pcf;
-
-   /* Private stuff */
-   struct pcf50633_adc_request *queue[PCF50633_MAX_ADC_FIFO_DEPTH];
-   int queue_head;
-   int queue_tail;
-   struct mutex queue_mutex;
-};
-
-static inline struct pcf50633_adc *__to_adc(struct pcf50633 *pcf)
-{
-   return platform_get_drvdata(pcf->adc_pdev);
-}
-
-static void adc_setup(struct pcf50633 *pcf, int channel, int avg)
-{
-   channel &= PCF50633_ADCC1_ADCMUX_MASK;
-
-   /* kill ratiometric, but enable ACCSW biasing */
-   pcf50633_reg_write(pcf, PCF50633_REG_ADCC2, 0x00);
-   pcf50633_reg_write(pcf, PCF50633_REG_ADCC3, 0x01);
-
-   /* start ADC conversion on selected channel */
-   pcf50633_reg_write(pcf, PCF50633_REG_ADCC1, channel | avg |
-   PCF50633_ADCC1_ADCSTART | PCF50633_ADCC1_RES_10BIT);
-}
-
-static void trigger_next_adc_job_if_any(struct pcf50633 *pcf)
-{
-   struct pcf50633_adc *adc = __to_adc(pcf);
-   int head;
-
-   head = adc->queue_head;
-
-   if (!adc->queue[head])
-   return;
-
-   adc_setup(pcf, adc->queue[head]->mux, adc->queue[head]->avg);
-}
-
-static int
-adc_enqueue_request(struct pcf50633 *pcf, struct pcf50633_adc_request *req)
-{
-   struct pcf50633_adc *adc = __to_adc(pcf);
-   int head, tail;
-
-   mutex_lock(&adc->queue_mutex);
-
-   head = adc->queue_head;
-   tail = adc->queue_tail;
-
-   if (adc->queue[tail]) {
-   mutex_unlock(&adc->queue_mutex);
-   dev_err(pcf->dev, "ADC queue is full, dropping request\n");
-   return -EBUSY;
-   }
-
-   adc->

Re: [PATCH 4/4] drm: bridge: dw-hdmi: use new helper to get ACR values

2025-03-09 Thread kernel test robot
Hi Dmitry,

kernel test robot noticed the following build errors:

[auto build test ERROR on 0a2f889128969dab41861b6e40111aa03dc57014]

url:
https://github.com/intel-lab-lkp/linux/commits/Dmitry-Baryshkov/drm-display-hdmi-provide-central-data-authority-for-ACR-params/20250309-161610
base:   0a2f889128969dab41861b6e40111aa03dc57014
patch link:
https://lore.kernel.org/r/20250309-drm-hdmi-acr-v1-4-bb9c242f4d4b%40linaro.org
patch subject: [PATCH 4/4] drm: bridge: dw-hdmi: use new helper to get ACR 
values
config: arm64-randconfig-002-20250310 
(https://download.01.org/0day-ci/archive/20250310/202503100501.slwyob9u-...@intel.com/config)
compiler: clang version 17.0.6 (https://github.com/llvm/llvm-project 
6009708b4367171ccdbf4b5905cb6a803753fe18)
reproduce (this is a W=1 build): 
(https://download.01.org/0day-ci/archive/20250310/202503100501.slwyob9u-...@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/202503100501.slwyob9u-...@intel.com/

All errors (new ones prefixed by >>, old ones prefixed by <<):

>> ERROR: modpost: "drm_hdmi_acr_get_n_cts" 
>> [drivers/gpu/drm/bridge/synopsys/dw-hdmi.ko] undefined!

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki


[PATCH v3 5/8] drm/msm/dpu: don't select single flush for active CTL blocks

2025-03-09 Thread Dmitry Baryshkov
From: Dmitry Baryshkov 

In case of ACTIVE CTLs, a single CTL is being used for flushing all INTF
blocks. Don't skip programming the CTL on those targets.

Tested-by: Neil Armstrong  # on SM8550-QRD
Signed-off-by: Dmitry Baryshkov 
---
 drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

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 
232055473ba55998b79dd2e8c752c129bbffbff4..8a618841e3ea89acfe4a42d48319a6c54a1b3495
 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
@@ -374,7 +374,8 @@ static void dpu_encoder_phys_vid_underrun_irq(void *arg)
 static bool dpu_encoder_phys_vid_needs_single_flush(
struct dpu_encoder_phys *phys_enc)
 {
-   return phys_enc->split_role != ENC_ROLE_SOLO;
+   return !(phys_enc->hw_ctl->caps->features & BIT(DPU_CTL_ACTIVE_CFG)) &&
+   phys_enc->split_role != ENC_ROLE_SOLO;
 }
 
 static void dpu_encoder_phys_vid_atomic_mode_set(

-- 
2.39.5



Re: [RFC 07/11] mm/memremap: Add folio_split support

2025-03-09 Thread Mika Penttilä
Hi,

On 3/6/25 06:42, Balbir Singh wrote:
> When a zone device page is split (via huge pmd folio split). The
> driver callback for folio_split is invoked to let the device driver
> know that the folio size has been split into a smaller order.
>
> The HMM test driver has been updated to handle the split, since the
> test driver uses backing pages, it requires a mechanism of reorganizing
> the backing pages (backing pages are used to create a mirror device)
> again into the right sized order pages. This is supported by exporting
> prep_compound_page().
>
> Signed-off-by: Balbir Singh 
> ---
>  include/linux/memremap.h |  7 +++
>  include/linux/mm.h   |  1 +
>  lib/test_hmm.c   | 35 +++
>  mm/huge_memory.c |  5 +
>  mm/page_alloc.c  |  1 +
>  5 files changed, 49 insertions(+)
>
> diff --git a/include/linux/memremap.h b/include/linux/memremap.h
> index 11d586dd8ef1..2091b754f1da 100644
> --- a/include/linux/memremap.h
> +++ b/include/linux/memremap.h
> @@ -100,6 +100,13 @@ struct dev_pagemap_ops {
>*/
>   int (*memory_failure)(struct dev_pagemap *pgmap, unsigned long pfn,
> unsigned long nr_pages, int mf_flags);
> +
> + /*
> +  * Used for private (un-addressable) device memory only.
> +  * This callback is used when a folio is split into
> +  * a smaller folio
> +  */
> + void (*folio_split)(struct folio *head, struct folio *tail);
>  };
>  
>  #define PGMAP_ALTMAP_VALID   (1 << 0)
> diff --git a/include/linux/mm.h b/include/linux/mm.h
> index 98a67488b5fe..3d0e91e0a923 100644
> --- a/include/linux/mm.h
> +++ b/include/linux/mm.h
> @@ -1415,6 +1415,7 @@ static inline struct folio *virt_to_folio(const void *x)
>  void __folio_put(struct folio *folio);
>  
>  void split_page(struct page *page, unsigned int order);
> +void prep_compound_page(struct page *page, unsigned int order);
>  void folio_copy(struct folio *dst, struct folio *src);
>  int folio_mc_copy(struct folio *dst, struct folio *src);
>  
> diff --git a/lib/test_hmm.c b/lib/test_hmm.c
> index a81d2f8a0426..18b6a7b061d7 100644
> --- a/lib/test_hmm.c
> +++ b/lib/test_hmm.c
> @@ -1640,10 +1640,45 @@ static vm_fault_t dmirror_devmem_fault(struct 
> vm_fault *vmf)
>   return ret;
>  }
>  
> +
> +static void dmirror_devmem_folio_split(struct folio *head, struct folio 
> *tail)
> +{
> + struct page *rpage = BACKING_PAGE(folio_page(head, 0));
> + struct folio *new_rfolio;
> + struct folio *rfolio;
> + unsigned long offset = 0;
> +
> + if (!rpage) {
> + folio_page(tail, 0)->zone_device_data = NULL;
> + return;
> + }
> +
> + offset = folio_pfn(tail) - folio_pfn(head);
> + rfolio = page_folio(rpage);
> + new_rfolio = page_folio(folio_page(rfolio, offset));
> +
> + folio_page(tail, 0)->zone_device_data = folio_page(new_rfolio, 0);
> +

> + if (folio_pfn(tail) - folio_pfn(head) == 1) {
> + if (folio_order(head))
> + prep_compound_page(folio_page(rfolio, 0),
> + folio_order(head));
> + folio_set_count(rfolio, 1);
> + }

I think this might need at least a comment. Also, isn't the
folio_order(head) always 0, tail and head are splitted folios and if pfn
difference == 1?
If the intention is to adjust the backing folio's head page to the new
order, shouldn't there be clear_compound_head() also for backing head
page if split to zero order?


> + clear_compound_head(folio_page(new_rfolio, 0));
> + if (folio_order(tail))
> + prep_compound_page(folio_page(new_rfolio, 0),
> + folio_order(tail));
> + folio_set_count(new_rfolio, 1);
> + folio_page(new_rfolio, 0)->mapping = folio_page(rfolio, 0)->mapping;
> + tail->pgmap = head->pgmap;
> +}
> +
>  static const struct dev_pagemap_ops dmirror_devmem_ops = {
>   .page_free  = dmirror_devmem_free,
>   .migrate_to_ram = dmirror_devmem_fault,
>   .page_free  = dmirror_devmem_free,
> + .folio_split= dmirror_devmem_folio_split,
>  };
>  
>  static int dmirror_device_init(struct dmirror_device *mdevice, int id)
> diff --git a/mm/huge_memory.c b/mm/huge_memory.c
> index 995ac8be5709..518a70d1b58a 100644
> --- a/mm/huge_memory.c
> +++ b/mm/huge_memory.c
> @@ -3655,6 +3655,11 @@ static int __split_unmapped_folio(struct folio *folio, 
> int new_order,
>   MTHP_STAT_NR_ANON, 1);
>   }
>  
> + if (folio_is_device_private(origin_folio) &&
> + origin_folio->pgmap->ops->folio_split)
> + origin_folio->pgmap->ops->folio_split(
> + origin_folio, release);
> +
>   /*
>* Unfreeze refcount first. Additional reference from
>

Re: [PATCH 2/4] drm/msm/hdmi: use new helper for ACR tables

2025-03-09 Thread kernel test robot
Hi Dmitry,

kernel test robot noticed the following build errors:

[auto build test ERROR on 0a2f889128969dab41861b6e40111aa03dc57014]

url:
https://github.com/intel-lab-lkp/linux/commits/Dmitry-Baryshkov/drm-display-hdmi-provide-central-data-authority-for-ACR-params/20250309-161610
base:   0a2f889128969dab41861b6e40111aa03dc57014
patch link:
https://lore.kernel.org/r/20250309-drm-hdmi-acr-v1-2-bb9c242f4d4b%40linaro.org
patch subject: [PATCH 2/4] drm/msm/hdmi: use new helper for ACR tables
config: arm-randconfig-004-20250310 
(https://download.01.org/0day-ci/archive/20250310/202503100745.kweawjfd-...@intel.com/config)
compiler: clang version 21.0.0git (https://github.com/llvm/llvm-project 
e15545cad8297ec7555f26e5ae74a9f0511203e7)
reproduce (this is a W=1 build): 
(https://download.01.org/0day-ci/archive/20250310/202503100745.kweawjfd-...@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/202503100745.kweawjfd-...@intel.com/

All errors (new ones prefixed by >>, old ones prefixed by <<):

>> ERROR: modpost: "drm_hdmi_acr_get_n_cts" [drivers/gpu/drm/msm/msm.ko] 
>> undefined!

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki


[PATCH v3] fbdev: fsl-diu-fb: add missing device_remove_file()

2025-03-09 Thread oushixiong1025
From: Shixiong Ou 

Call device_remove_file() when driver remove.

Signed-off-by: Shixiong Ou 
---
v1->v2:
add has_dev_attrs flag.
v2->v3:
drop those extra checks.

 drivers/video/fbdev/fsl-diu-fb.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/video/fbdev/fsl-diu-fb.c b/drivers/video/fbdev/fsl-diu-fb.c
index 5ac8201c3533..b71d15794ce8 100644
--- a/drivers/video/fbdev/fsl-diu-fb.c
+++ b/drivers/video/fbdev/fsl-diu-fb.c
@@ -1827,6 +1827,7 @@ static void fsl_diu_remove(struct platform_device *pdev)
int i;
 
data = dev_get_drvdata(&pdev->dev);
+   device_remove_file(&pdev->dev, &data->dev_attr);
disable_lcdc(&data->fsl_diu_info[0]);
 
free_irq(data->irq, data->diu_reg);
-- 
2.25.1



[PATCH] backlight: tdo24m: Eliminate redundant whitespace

2025-03-09 Thread WangYuli
The description for CONFIG_LCD_TDO24M has redundant whitespace.
Trim it to keep the code tidy.

Signed-off-by: WangYuli 
---
 drivers/video/backlight/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/video/backlight/Kconfig b/drivers/video/backlight/Kconfig
index 3614a5d29c71..f2d7c4fe3ba5 100644
--- a/drivers/video/backlight/Kconfig
+++ b/drivers/video/backlight/Kconfig
@@ -70,7 +70,7 @@ config LCD_ILI9320
  then say y to include a power driver for it.
 
 config LCD_TDO24M
-   tristate "Toppoly TDO24M  and TDO35S LCD Panels support"
+   tristate "Toppoly TDO24M and TDO35S LCD Panels support"
depends on SPI_MASTER
help
  If you have a Toppoly TDO24M/TDO35S series LCD panel, say y here to
-- 
2.47.2



Re: [PATCH 1/1] drm/hyperv: Fix address space leak when Hyper-V DRM device is removed

2025-03-09 Thread Wei Liu
On Mon, Feb 10, 2025 at 11:34:41AM -0800, mhkelle...@gmail.com wrote:
> From: Michael Kelley 
> 
> When a Hyper-V DRM device is probed, the driver allocates MMIO space for
> the vram, and maps it cacheable. If the device removed, or in the error
> path for device probing, the MMIO space is released but no unmap is done.
> Consequently the kernel address space for the mapping is leaked.
> 
> Fix this by adding iounmap() calls in the device removal path, and in the
> error path during device probing.
> 
> Fixes: f1f63cbb705d ("drm/hyperv: Fix an error handling path in 
> hyperv_vmbus_probe()")
> Fixes: a0ab5abced55 ("drm/hyperv : Removing the restruction of VRAM 
> allocation with PCI bar size")
> Signed-off-by: Michael Kelley 

Applied to hyperv-fixes. Thanks.


Re: [PATCH 1/1] fbdev: hyperv_fb: Fix hang in kdump kernel when on Hyper-V Gen 2 VMs

2025-03-09 Thread Wei Liu
On Tue, Feb 18, 2025 at 03:01:30PM -0800, mhkelle...@gmail.com wrote:
> From: Michael Kelley 
> 
> Gen 2 Hyper-V VMs boot via EFI and have a standard EFI framebuffer
> device. When the kdump kernel runs in such a VM, loading the efifb
> driver may hang because of accessing the framebuffer at the wrong
> memory address.
> 
> The scenario occurs when the hyperv_fb driver in the original kernel
> moves the framebuffer to a different MMIO address because of conflicts
> with an already-running efifb or simplefb driver. The hyperv_fb driver
> then informs Hyper-V of the change, which is allowed by the Hyper-V FB
> VMBus device protocol. However, when the kexec command loads the kdump
> kernel into crash memory via the kexec_file_load() system call, the
> system call doesn't know the framebuffer has moved, and it sets up the
> kdump screen_info using the original framebuffer address. The transition
> to the kdump kernel does not go through the Hyper-V host, so Hyper-V
> does not reset the framebuffer address like it would do on a reboot.
> When efifb tries to run, it accesses a non-existent framebuffer
> address, which traps to the Hyper-V host. After many such accesses,
> the Hyper-V host thinks the guest is being malicious, and throttles
> the guest to the point that it runs very slowly or appears to have hung.
> 
> When the kdump kernel is loaded into crash memory via the kexec_load()
> system call, the problem does not occur. In this case, the kexec command
> builds the screen_info table itself in user space from data returned
> by the FBIOGET_FSCREENINFO ioctl against /dev/fb0, which gives it the
> new framebuffer location.
> 
> This problem was originally reported in 2020 [1], resulting in commit
> 3cb73bc3fa2a ("hyperv_fb: Update screen_info after removing old
> framebuffer"). This commit solved the problem by setting orig_video_isVGA
> to 0, so the kdump kernel was unaware of the EFI framebuffer. The efifb
> driver did not try to load, and no hang occurred. But in 2024, commit
> c25a19afb81c ("fbdev/hyperv_fb: Do not clear global screen_info")
> effectively reverted 3cb73bc3fa2a. Commit c25a19afb81c has no reference
> to 3cb73bc3fa2a, so perhaps it was done without knowing the implications
> that were reported with 3cb73bc3fa2a. In any case, as of commit
> c25a19afb81c, the original problem came back again.
> 
> Interestingly, the hyperv_drm driver does not have this problem because
> it never moves the framebuffer. The difference is that the hyperv_drm
> driver removes any conflicting framebuffers *before* allocating an MMIO
> address, while the hyperv_fb drivers removes conflicting framebuffers
> *after* allocating an MMIO address. With the "after" ordering, hyperv_fb
> may encounter a conflict and move the framebuffer to a different MMIO
> address. But the conflict is essentially bogus because it is removed
> a few lines of code later.
> 
> Rather than fix the problem with the approach from 2020 in commit
> 3cb73bc3fa2a, instead slightly reorder the steps in hyperv_fb so
> conflicting framebuffers are removed before allocating an MMIO address.
> Then the default framebuffer MMIO address should always be available, and
> there's never any confusion about which framebuffer address the kdump
> kernel should use -- it's always the original address provided by
> the Hyper-V host. This approach is already used by the hyperv_drm
> driver, and is consistent with the usage guidelines at the head of
> the module with the function aperture_remove_conflicting_devices().
> 
> This approach also solves a related minor problem when kexec_load()
> is used to load the kdump kernel. With current code, unbinding and
> rebinding the hyperv_fb driver could result in the framebuffer moving
> back to the default framebuffer address, because on the rebind there
> are no conflicts. If such a move is done after the kdump kernel is
> loaded with the new framebuffer address, at kdump time it could again
> have the wrong address.
> 
> This problem and fix are described in terms of the kdump kernel, but
> it can also occur with any kernel started via kexec.
> 
> See extensive discussion of the problem and solution at [2].
> 
> [1] 
> https://lore.kernel.org/linux-hyperv/20201014092429.1415040-1-kas...@redhat.com/
> [2] 
> https://lore.kernel.org/linux-hyperv/blapr10mb521793485093fdb448f7b2e5fd...@blapr10mb5217.namprd10.prod.outlook.com/
> 
> Reported-by: Thomas Tai 
> Fixes: c25a19afb81c ("fbdev/hyperv_fb: Do not clear global screen_info")
> Signed-off-by: Michael Kelley 

Applied to hyperv-fixes, thanks!



Re: [PATCH 1/1] fbdev: hyperv_fb: Fix hang in kdump kernel when on Hyper-V Gen 2 VMs

2025-03-09 Thread Wei Liu
On Sun, Mar 09, 2025 at 03:20:04PM +0100, Helge Deller wrote:
> On 3/9/25 05:10, Michael Kelley wrote:
> > From: Helge Deller  Sent: Saturday, March 8, 2025 6:59 PM
> > > 
> > > On 2/19/25 00:01, mhkelle...@gmail.com wrote:
> > > > From: Michael Kelley 
> > > > 
> > [snip]
> > 
> > > > 
> > > > Reported-by: Thomas Tai 
> > > > Fixes: c25a19afb81c ("fbdev/hyperv_fb: Do not clear global screen_info")
> > > > Signed-off-by: Michael Kelley 
> > > > ---
> > > > The "Fixes" tag uses commit c25a19afb81c because that's where the 
> > > > problem
> > > > was re-exposed, and how far back a stable backport is needed. But I've
> > > > taken a completely different, and hopefully better, approach in the
> > > > solution that isn't related to the code changes in c25a19afb81c.
> > > > 
> > > >drivers/video/fbdev/hyperv_fb.c | 20 +---
> > > >1 file changed, 13 insertions(+), 7 deletions(-)
> > > 
> > > applied to fbdev tree.
> > > 
> > 
> > Thank you!
> > 
> > Related, I noticed the patch "fbdev: hyperv_fb: iounmap() the correct
> > memory when removing a device" is also in the fbdev for-next branch.
> > Wei Liu previously applied this patch to the hyperv-fixes tree (see [1])
> > and it's already in linux-next. Won't having it also in fbdev produce a
> > merge conflict?
> > [1] 
> > https://lore.kernel.org/linux-hyperv/Z6wHDw8BssJyQHiM@liuwe-devbox-debian-v2/
> 
> Thanks Michael!
> I now dropped that patch from the fbdev tree to avoid collisions.
> 
> Btw, I'm fine if we agree that all hyperv-fbdev fixes & patches go through
> hyperv or other trees. Just let me know.

I can pick up all hyperv-fbdev patches in the future. Thanks Helge.

Wei.

> 
> Helge


Re: [PATCH v3 0/2] fbdev: hyperv_fb: framebuffer release cleanup

2025-03-09 Thread Wei Liu
On Sat, Mar 01, 2025 at 08:16:29AM -0800, Saurabh Sengar wrote:
> This patch series addresses an issue in the unbind path of the hyperv_fb
> driver, which is resolved in the second patch of this series.
> 
> While working on this fix, it was observed that hvfb_putmem() and its
> child functions could be cleaned up first to simplify the movement of
> hvfb_putmem(). This cleanup is done in the first patch.
> 
> Although hvfb_getmem() could also be cleaned up, it depends on
> vmbus_allocate_mmio(), which is used by multiple other drivers. Since
> addressing hvfb_getmem() is independent of this fix, it will be handled
> in a separate patch series.
> 
> [V3]
>  - Add a patch 1 for cleanup of hvfb_putmem()
>  - Use the simplified hvfb_putmem()
> 
> Saurabh Sengar (2):
>   fbdev: hyperv_fb: Simplify hvfb_putmem
>   fbdev: hyperv_fb: Allow graceful removal of framebuffer

Applied to hyperv-fixes, thanks!



Re: [PATCH RESEND 1/2] Refactoring the fbcon packed pixel drawing routines

2025-03-09 Thread kernel test robot
Hi Zsolt,

kernel test robot noticed the following build errors:

[auto build test ERROR on linus/master]
[also build test ERROR on v6.14-rc5 next-20250307]
[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/Zsolt-Kajtar/Refactoring-the-fbcon-packed-pixel-drawing-routines/20250310-025619
base:   linus/master
patch link:
https://lore.kernel.org/r/20250309184716.13732-2-soci%40c64.rulez.org
patch subject: [PATCH RESEND 1/2] Refactoring the fbcon packed pixel drawing 
routines
config: i386-buildonly-randconfig-002-20250310 
(https://download.01.org/0day-ci/archive/20250310/202503100810.9iid3430-...@intel.com/config)
compiler: clang version 19.1.7 (https://github.com/llvm/llvm-project 
cd708029e0b2869e80abe31ddb175f7c35361f90)
reproduce (this is a W=1 build): 
(https://download.01.org/0day-ci/archive/20250310/202503100810.9iid3430-...@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/202503100810.9iid3430-...@intel.com/

All error/warnings (new ones prefixed by >>):

   In file included from drivers/video/fbdev/aty/mach64_cursor.c:9:
>> drivers/video/fbdev/aty/../core/fb_draw.h:16:48: warning: declaration of 
>> 'struct fb_address' will not be visible outside of this function 
>> [-Wvisibility]
  16 | static inline void fb_address_move_long(struct fb_address *adr, int 
offset)
 |^
>> drivers/video/fbdev/aty/../core/fb_draw.h:18:5: error: incomplete definition 
>> of type 'struct fb_address'
  18 | adr->address += offset * (BITS_PER_LONG / BITS_PER_BYTE);
 | ~~~^
   drivers/video/fbdev/aty/../core/fb_draw.h:16:48: note: forward declaration 
of 'struct fb_address'
  16 | static inline void fb_address_move_long(struct fb_address *adr, int 
offset)
 |^
   drivers/video/fbdev/aty/../core/fb_draw.h:22:46: warning: declaration of 
'struct fb_address' will not be visible outside of this function [-Wvisibility]
  22 | static inline void fb_address_forward(struct fb_address *adr, 
unsigned int offset)
 |  ^
   drivers/video/fbdev/aty/../core/fb_draw.h:24:39: error: incomplete 
definition of type 'struct fb_address'
  24 | unsigned int bits = (unsigned int)adr->bits + offset;
 |   ~~~^
   drivers/video/fbdev/aty/../core/fb_draw.h:22:46: note: forward declaration 
of 'struct fb_address'
  22 | static inline void fb_address_forward(struct fb_address *adr, 
unsigned int offset)
 |  ^
   drivers/video/fbdev/aty/../core/fb_draw.h:26:5: error: incomplete definition 
of type 'struct fb_address'
  26 | adr->bits = bits & (BITS_PER_LONG - 1u);
 | ~~~^
   drivers/video/fbdev/aty/../core/fb_draw.h:22:46: note: forward declaration 
of 'struct fb_address'
  22 | static inline void fb_address_forward(struct fb_address *adr, 
unsigned int offset)
 |  ^
   drivers/video/fbdev/aty/../core/fb_draw.h:27:5: error: incomplete definition 
of type 'struct fb_address'
  27 | adr->address += (bits & ~(BITS_PER_LONG - 1u)) / 
BITS_PER_BYTE;
 | ~~~^
   drivers/video/fbdev/aty/../core/fb_draw.h:22:46: note: forward declaration 
of 'struct fb_address'
  22 | static inline void fb_address_forward(struct fb_address *adr, 
unsigned int offset)
 |  ^
   drivers/video/fbdev/aty/../core/fb_draw.h:31:47: warning: declaration of 
'struct fb_address' will not be visible outside of this function [-Wvisibility]
  31 | static inline void fb_address_backward(struct fb_address *adr, 
unsigned int offset)
 |   ^
   drivers/video/fbdev/aty/../core/fb_draw.h:33:16: error: incomplete 
definition of type 'struct fb_address'
  33 | int bits = adr->bits - (int)offset;
 |~~~^
   drivers/video/fbdev/aty/../core/fb_draw.h:31:47: note: forward declaration 
of 'struct fb_address'
  31 | static inline void fb_address_backward(struct fb_address *adr, 
unsigned int offset)
 |   ^
   drivers/video/fbdev/aty/../core/fb_draw.h:35:5: error: incomplete definition 
of type 'struct fb_address'
  35 | adr->bits = bits & (BITS_PER_LONG - 1);
 | ~~~^
   drivers/video/fbdev/aty/../core/fb_draw.h:31:47: note: forward declaration 
of 'stru

[PATCH 2/9] backlight: pcf50633-backlight: Remove

2025-03-09 Thread linux
From: "Dr. David Alan Gilbert" 

The pcf50633 was used as part of the OpenMoko devices but
the support for its main chip was recently removed in:
commit 61b7f8920b17 ("ARM: s3c: remove all s3c24xx support")

See https://lore.kernel.org/all/Z8z236h4B5A6Ki3D@gallifrey/

Remove it.

Signed-off-by: Dr. David Alan Gilbert 
---
 drivers/mfd/pcf50633-core.c  |   2 -
 drivers/video/backlight/Kconfig  |   7 -
 drivers/video/backlight/Makefile |   1 -
 drivers/video/backlight/pcf50633-backlight.c | 154 ---
 include/linux/mfd/pcf50633/backlight.h   |  42 -
 include/linux/mfd/pcf50633/core.h|   4 -
 6 files changed, 210 deletions(-)
 delete mode 100644 drivers/video/backlight/pcf50633-backlight.c
 delete mode 100644 include/linux/mfd/pcf50633/backlight.h

diff --git a/drivers/mfd/pcf50633-core.c b/drivers/mfd/pcf50633-core.c
index 70f8bbb89f76..08aa68ef2fbc 100644
--- a/drivers/mfd/pcf50633-core.c
+++ b/drivers/mfd/pcf50633-core.c
@@ -210,7 +210,6 @@ static int pcf50633_probe(struct i2c_client *client)
pcf50633_client_dev_register(pcf, "pcf50633-input", &pcf->input_pdev);
pcf50633_client_dev_register(pcf, "pcf50633-rtc", &pcf->rtc_pdev);
pcf50633_client_dev_register(pcf, "pcf50633-mbc", &pcf->mbc_pdev);
-   pcf50633_client_dev_register(pcf, "pcf50633-backlight", &pcf->bl_pdev);
 
 
for (i = 0; i < PCF50633_NUM_REGULATORS; i++) {
@@ -262,7 +261,6 @@ static void pcf50633_remove(struct i2c_client *client)
platform_device_unregister(pcf->input_pdev);
platform_device_unregister(pcf->rtc_pdev);
platform_device_unregister(pcf->mbc_pdev);
-   platform_device_unregister(pcf->bl_pdev);
 
for (i = 0; i < PCF50633_NUM_REGULATORS; i++)
platform_device_unregister(pcf->regulator_pdev[i]);
diff --git a/drivers/video/backlight/Kconfig b/drivers/video/backlight/Kconfig
index 3614a5d29c71..ef4ac1ac7520 100644
--- a/drivers/video/backlight/Kconfig
+++ b/drivers/video/backlight/Kconfig
@@ -359,13 +359,6 @@ config BACKLIGHT_88PM860X
help
  Say Y to enable the backlight driver for Marvell 88PM8606.
 
-config BACKLIGHT_PCF50633
-   tristate "Backlight driver for NXP PCF50633 MFD"
-   depends on MFD_PCF50633
-   help
- If you have a backlight driven by a NXP PCF50633 MFD, say Y here to
- enable its driver.
-
 config BACKLIGHT_AAT2870
tristate "AnalogicTech AAT2870 Backlight"
depends on MFD_AAT2870_CORE
diff --git a/drivers/video/backlight/Makefile b/drivers/video/backlight/Makefile
index 8fc98f760a8a..21bf62bcaccf 100644
--- a/drivers/video/backlight/Makefile
+++ b/drivers/video/backlight/Makefile
@@ -49,7 +49,6 @@ obj-$(CONFIG_BACKLIGHT_MP3309C)   += mp3309c.o
 obj-$(CONFIG_BACKLIGHT_MT6370) += mt6370-backlight.o
 obj-$(CONFIG_BACKLIGHT_OMAP1)  += omap1_bl.o
 obj-$(CONFIG_BACKLIGHT_PANDORA)+= pandora_bl.o
-obj-$(CONFIG_BACKLIGHT_PCF50633)   += pcf50633-backlight.o
 obj-$(CONFIG_BACKLIGHT_PWM)+= pwm_bl.o
 obj-$(CONFIG_BACKLIGHT_QCOM_WLED)  += qcom-wled.o
 obj-$(CONFIG_BACKLIGHT_RT4831) += rt4831-backlight.o
diff --git a/drivers/video/backlight/pcf50633-backlight.c 
b/drivers/video/backlight/pcf50633-backlight.c
deleted file mode 100644
index 157be2f366df..
--- a/drivers/video/backlight/pcf50633-backlight.c
+++ /dev/null
@@ -1,154 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0-or-later
-/*
- *  Copyright (C) 2009-2010, Lars-Peter Clausen 
- *  PCF50633 backlight device driver
- */
-
-#include 
-#include 
-#include 
-#include 
-
-#include 
-
-#include 
-#include 
-
-struct pcf50633_bl {
-   struct pcf50633 *pcf;
-   struct backlight_device *bl;
-
-   unsigned int brightness;
-   unsigned int brightness_limit;
-};
-
-/*
- * pcf50633_bl_set_brightness_limit
- *
- * Update the brightness limit for the pc50633 backlight. The actual brightness
- * will not go above the limit. This is useful to limit power drain for example
- * on low battery.
- *
- * @dev: Pointer to a pcf50633 device
- * @limit: The brightness limit. Valid values are 0-63
- */
-int pcf50633_bl_set_brightness_limit(struct pcf50633 *pcf, unsigned int limit)
-{
-   struct pcf50633_bl *pcf_bl = platform_get_drvdata(pcf->bl_pdev);
-
-   if (!pcf_bl)
-   return -ENODEV;
-
-   pcf_bl->brightness_limit = limit & 0x3f;
-   backlight_update_status(pcf_bl->bl);
-
-   return 0;
-}
-
-static int pcf50633_bl_update_status(struct backlight_device *bl)
-{
-   struct pcf50633_bl *pcf_bl = bl_get_data(bl);
-   unsigned int new_brightness;
-
-
-   if (bl->props.state & (BL_CORE_SUSPENDED | BL_CORE_FBBLANK) ||
-   bl->props.power != BACKLIGHT_POWER_ON)
-   new_brightness = 0;
-   else if (bl->props.brightness < pcf_bl->brightness_limit)
-   new_brightness = bl->props.brightness;
-   else
-  

[GIT PULL] Nova changes for v6.15

2025-03-09 Thread Danilo Krummrich
Hi Dave and Sima,

This is the inital PR for Nova (nova-core).

Besides the nova-core skeleton driver and the initial project documentation,
I picked up two firmware patches and one Rust patch (no conflicts expected) as
dependency of nova-core.

The following changes since commit 7eb172143d5508b4da468ed59ee857c6e5e01da6:

  Linux 6.14-rc5 (2025-03-02 11:48:20 -0800)

are available in the Git repository at:

  g...@gitlab.freedesktop.org:drm/nova.git tags/nova-next-6.15-2025-03-09

for you to fetch changes up to b28786b190d1ae2df5e6a5181ad78c6f226ea3e1:

  gpu: nova-core: add initial documentation (2025-03-09 19:24:29 +0100)


Nova changes for v6.15

nova-core:
  - initial skeleton driver
  - documentation
- project guidelines
- task (todo) list

firmware:
  - `module_firmware!` macro
  - `firmware::ModInfoBuilder`

Rust:
  - `LocalModule` type alias


Danilo Krummrich (5):
  rust: module: add type `LocalModule`
  rust: firmware: introduce `firmware::ModInfoBuilder`
  rust: firmware: add `module_firmware!` macro
  gpu: nova-core: add initial driver stub
  gpu: nova-core: add initial documentation

 Documentation/gpu/drivers.rst  |   1 +
 Documentation/gpu/nova/core/guidelines.rst |  24 ++
 Documentation/gpu/nova/core/todo.rst   | 446 
++
 Documentation/gpu/nova/guidelines.rst  |  69 +
 Documentation/gpu/nova/index.rst   |  30 
 MAINTAINERS|  11 +++
 drivers/gpu/Makefile   |   1 +
 drivers/gpu/nova-core/Kconfig  |  14 
 drivers/gpu/nova-core/Makefile |   3 +
 drivers/gpu/nova-core/driver.rs|  47 
 drivers/gpu/nova-core/firmware.rs  |  45 +++
 drivers/gpu/nova-core/gpu.rs   | 199 
+
 drivers/gpu/nova-core/nova_core.rs |  20 +
 drivers/gpu/nova-core/regs.rs  |  55 ++
 drivers/gpu/nova-core/util.rs  |  21 ++
 drivers/video/Kconfig  |   1 +
 rust/kernel/firmware.rs| 216 
+
 rust/macros/module.rs  |   4 +
 18 files changed, 1207 insertions(+)
 create mode 100644 Documentation/gpu/nova/core/guidelines.rst
 create mode 100644 Documentation/gpu/nova/core/todo.rst
 create mode 100644 Documentation/gpu/nova/guidelines.rst
 create mode 100644 Documentation/gpu/nova/index.rst
 create mode 100644 drivers/gpu/nova-core/Kconfig
 create mode 100644 drivers/gpu/nova-core/Makefile
 create mode 100644 drivers/gpu/nova-core/driver.rs
 create mode 100644 drivers/gpu/nova-core/firmware.rs
 create mode 100644 drivers/gpu/nova-core/gpu.rs
 create mode 100644 drivers/gpu/nova-core/nova_core.rs
 create mode 100644 drivers/gpu/nova-core/regs.rs
 create mode 100644 drivers/gpu/nova-core/util.rs