Re: [PATCH v2 1/2] drm: allow limiting the scatter list size.
On Mon, Sep 7, 2020 at 8:39 AM Gerd Hoffmann wrote:
>
> > > + /**
> > > +* @max_segment:
> > > +*
> > > +* Max size for scatter list segments. When unset the default
> > > +* (SCATTERLIST_MAX_SEGMENT) is used.
> > > +*/
> > > + size_t max_segment;
> >
> > Is there no better place for this then "at the bottom"? drm_device is a
> > huge structure, piling stuff up randomly doesn't make it better :-)
>
> Moved next to the other gem fields for now (v3 posted).
>
> > I think ideally we'd have a gem substruct like we have on the modeset side
> > at least.
>
> Phew, that'll be quite some churn in the tree. And there aren't that many
> gem-related fields in struct drm_device.
>
> So you are looking for something like below (header changes only)?
Hm yeah it's a lot less than I thought. And yes I think that would be neat.
-Daniel
>
> take care,
> Gerd
>
> diff --git a/include/drm/drm_device.h b/include/drm/drm_device.h
> index c455ef404ca6..950167ede98a 100644
> --- a/include/drm/drm_device.h
> +++ b/include/drm/drm_device.h
> @@ -299,22 +299,8 @@ struct drm_device {
> /** @mode_config: Current mode config */
> struct drm_mode_config mode_config;
>
> - /** @object_name_lock: GEM information */
> - struct mutex object_name_lock;
> -
> - /** @object_name_idr: GEM information */
> - struct idr object_name_idr;
> -
> - /** @vma_offset_manager: GEM information */
> - struct drm_vma_offset_manager *vma_offset_manager;
> -
> - /**
> -* @max_segment:
> -*
> -* Max size for scatter list segments for GEM objects. When
> -* unset the default (SCATTERLIST_MAX_SEGMENT) is used.
> -*/
> - size_t max_segment;
> + /** @gem_config: Current GEM config */
> + struct drm_gem_config gem_config;
>
> /** @vram_mm: VRAM MM memory manager */
> struct drm_vram_mm *vram_mm;
> diff --git a/include/drm/drm_gem.h b/include/drm/drm_gem.h
> index 337a48321705..74129fb29fb8 100644
> --- a/include/drm/drm_gem.h
> +++ b/include/drm/drm_gem.h
> @@ -39,6 +39,25 @@
>
> #include
>
> +struct drm_gem_config {
> + /** @object_name_lock: GEM information */
> + struct mutex object_name_lock;
> +
> + /** @object_name_idr: GEM information */
> + struct idr object_name_idr;
> +
> + /** @vma_offset_manager: GEM information */
> + struct drm_vma_offset_manager *vma_offset_manager;
> +
> + /**
> +* @max_segment:
> +*
> +* Max size for scatter list segments for GEM objects. When
> +* unset the default (SCATTERLIST_MAX_SEGMENT) is used.
> +*/
> + size_t max_segment;
> +};
> +
> struct drm_gem_object;
>
> /**
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 6/7] drm: Validate encoder->possible_crtcs
On Sun, Sep 6, 2020 at 1:19 PM Jan Kiszka wrote:
>
> On 11.02.20 18:04, Daniel Vetter wrote:
> > On Tue, Feb 11, 2020 at 06:22:07PM +0200, Ville Syrjala wrote:
> >> From: Ville Syrjälä
> >>
> >> WARN if the encoder possible_crtcs is effectively empty or contains
> >> bits for non-existing crtcs.
> >>
> >> v2: Move to drm_mode_config_validate() (Daniel)
> >> Make the docs say we WARN when this is wrong (Daniel)
> >> Extract full_crtc_mask()
> >>
> >> Cc: Thomas Zimmermann
> >> Cc: Daniel Vetter
> >> Signed-off-by: Ville Syrjälä
> >
> > When pushing the fixup needs to be applied before the validation patch
> > here, because we don't want to anger the bisect gods.
> >
> > Reviewed-by: Daniel Vetter
> >
> > I think with the fixup we should be good enough with the existing nonsense
> > in drivers. Fingers crossed.
> > -Daniel
> >
> >
> >> ---
> >> drivers/gpu/drm/drm_mode_config.c | 27 ++-
> >> include/drm/drm_encoder.h | 2 +-
> >> 2 files changed, 27 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/drm_mode_config.c
> >> b/drivers/gpu/drm/drm_mode_config.c
> >> index afc91447293a..4c1b350ddb95 100644
> >> --- a/drivers/gpu/drm/drm_mode_config.c
> >> +++ b/drivers/gpu/drm/drm_mode_config.c
> >> @@ -581,6 +581,29 @@ static void validate_encoder_possible_clones(struct
> >> drm_encoder *encoder)
> >> encoder->possible_clones, encoder_mask);
> >> }
> >>
> >> +static u32 full_crtc_mask(struct drm_device *dev)
> >> +{
> >> +struct drm_crtc *crtc;
> >> +u32 crtc_mask = 0;
> >> +
> >> +drm_for_each_crtc(crtc, dev)
> >> +crtc_mask |= drm_crtc_mask(crtc);
> >> +
> >> +return crtc_mask;
> >> +}
> >> +
> >> +static void validate_encoder_possible_crtcs(struct drm_encoder *encoder)
> >> +{
> >> +u32 crtc_mask = full_crtc_mask(encoder->dev);
> >> +
> >> +WARN((encoder->possible_crtcs & crtc_mask) == 0 ||
> >> + (encoder->possible_crtcs & ~crtc_mask) != 0,
> >> + "Bogus possible_crtcs: "
> >> + "[ENCODER:%d:%s] possible_crtcs=0x%x (full crtc mask=0x%x)\n",
> >> + encoder->base.id, encoder->name,
> >> + encoder->possible_crtcs, crtc_mask);
> >> +}
> >> +
> >> void drm_mode_config_validate(struct drm_device *dev)
> >> {
> >> struct drm_encoder *encoder;
> >> @@ -588,6 +611,8 @@ void drm_mode_config_validate(struct drm_device *dev)
> >> drm_for_each_encoder(encoder, dev)
> >> fixup_encoder_possible_clones(encoder);
> >>
> >> -drm_for_each_encoder(encoder, dev)
> >> +drm_for_each_encoder(encoder, dev) {
> >> validate_encoder_possible_clones(encoder);
> >> +validate_encoder_possible_crtcs(encoder);
> >> +}
> >> }
> >> diff --git a/include/drm/drm_encoder.h b/include/drm/drm_encoder.h
> >> index 3741963b9587..b236269f41ac 100644
> >> --- a/include/drm/drm_encoder.h
> >> +++ b/include/drm/drm_encoder.h
> >> @@ -142,7 +142,7 @@ struct drm_encoder {
> >> * the bits for all &drm_crtc objects this encoder can be connected to
> >> * before calling drm_dev_register().
> >> *
> >> - * In reality almost every driver gets this wrong.
> >> + * You will get a WARN if you get this wrong in the driver.
> >> *
> >> * Note that since CRTC objects can't be hotplugged the assigned
> >> indices
> >> * are stable and hence known before registering all objects.
> >> --
> >> 2.24.1
> >>
> >
>
> Triggers on an Advantech AIMB-228 (R1505G, 3 DP outputs):
Adding amdgpu display folks.
-Daniel
>
> [ 14.033246] [ cut here ]
> [ 14.033248] Bogus possible_crtcs: [ENCODER:65:TMDS-65] possible_crtcs=0xf
> (full crtc mask=0x7)
> [ 14.033279] WARNING: CPU: 0 PID: 282 at
> ../drivers/gpu/drm/drm_mode_config.c:622 drm_mode_config_validate+0x17d/0x200
> [drm]
> [ 14.033279] Modules linked in: amdgpu(E+) mfd_core(E)
> snd_hda_codec_realtek(E) kvm_amd(E) gpu_sched(E) i2c_algo_bit(E) ttm(E)
> snd_hda_codec_generic(E) kvm(E) ledtrig_audio(E) snd_hda_codec_hdmi(E)
> drm_kms_helper(E) snd_hda_intel(E) snd_intel_dspcfg(E) snd_hda_codec(E)
> cec(E) snd_hwdep(E) drm(E) irqbypass(E) snd_hda_core(E) crc32_pclmul(E)
> snd_pcm(E) ghash_clmulni_intel(E) snd_timer(E) sg(E) aesni_intel(E) snd(E)
> ccp(E) soundcore(E) rng_core(E) glue_helper(E) libaes(E) crypto_simd(E)
> k10temp(E) efi_pstore(E) sp5100_tco(E) evdev(E) cryptd(E) pcspkr(E)
> efivars(E) video(E) button(E) acpi_cpufreq(E) w83627hf_wdt(E) watchdog(E)
> nct6775(E) hwmon_vid(E) efivarfs(E) ip_tables(E) x_tables(E) autofs4(E)
> ext4(E) crc32c_generic(E) crc16(E) mbcache(E) jbd2(E) sd_mod(E) t10_pi(E)
> crc_t10dif(E) crct10dif_generic(E) uas(E) usb_storage(E) ahci(E) libahci(E)
> xhci_pci(E) r8169(E) realtek(E) mdio_devres(E) xhci_hcd(E) libata(E)
> i2c_amd_mp2_pci(E) crct10dif_pclmul(E) crct10dif_common(E) scsi_mod(E)
> [ 14.033306] crc32c_intel(E) i2c_piix4(E) usbcore(E) libphy(E)
> [ 14.033310] CPU: 0 PID: 282
[PATCH] drm/mediatek: add missing put_device() call in mtk_ddp_comp_init()
if of_find_device_by_node() succeed, mtk_ddp_comp_init() doesn't have
a corresponding put_device(). Thus add put_device() to fix the exception
handling for this function implementation.
Fixes: d0afe37f5209 ("drm/mediatek: support CMDQ interface in ddp component")
Signed-off-by: Yu Kuai
---
drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
index 57c88de9a329..526648885b97 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
@@ -496,6 +496,7 @@ int mtk_ddp_comp_init(struct device *dev, struct
device_node *node,
#if IS_REACHABLE(CONFIG_MTK_CMDQ)
if (of_address_to_resource(node, 0, &res) != 0) {
dev_err(dev, "Missing reg in %s node\n", node->full_name);
+ put_device(&larb_pdev->dev);
return -EINVAL;
}
comp->regs_pa = res.start;
--
2.25.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/2] drm/sun4i: sun8i-csc: Secondary CSC register correction
The secondary video layer (VI) on "Allwinner V3s" displays decoded video (YUV) in wrong colors. The secondary CSC should be programmed. Let's correct CSC register offset and extend regmap size. Regards. Martin Cerveny (2): drm/sun4i: sun8i-csc: Secondary CSC register correction drm/sun4i: mixer: Extend regmap max_register drivers/gpu/drm/sun4i/sun8i_csc.h | 2 +- drivers/gpu/drm/sun4i/sun8i_mixer.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/2] drm/sun4i: sun8i-csc: Secondary CSC register correction
"Allwinner V3s" has secondary video layer (VI). Decoded video is displayed in wrong colors until secondary CSC registers are programmed correctly. Signed-off-by: Martin Cerveny --- drivers/gpu/drm/sun4i/sun8i_csc.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/sun4i/sun8i_csc.h b/drivers/gpu/drm/sun4i/sun8i_csc.h index f42441b1b14d..a55a38ad849c 100644 --- a/drivers/gpu/drm/sun4i/sun8i_csc.h +++ b/drivers/gpu/drm/sun4i/sun8i_csc.h @@ -12,7 +12,7 @@ struct sun8i_mixer; /* VI channel CSC units offsets */ #define CCSC00_OFFSET 0xAA050 -#define CCSC01_OFFSET 0xFA000 +#define CCSC01_OFFSET 0xFA050 #define CCSC10_OFFSET 0xA #define CCSC11_OFFSET 0xF -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH v2 06/17] gpu: host1x: Cleanup and refcounting for syncpoints
05.09.2020 13:34, Mikko Perttunen пишет:
...
> +
> +/**
> + * host1x_syncpt_put() - free a requested syncpoint
> + * @sp: host1x syncpoint
> + *
> + * Release a syncpoint previously allocated using host1x_syncpt_request(). A
> + * host1x client driver should call this when the syncpoint is no longer in
> + * use.
> + */
> +void host1x_syncpt_put(struct host1x_syncpt *sp)
> +{
> + if (!sp)
> + return;
> +
> + kref_put(&sp->ref, syncpt_release);
> +}
> +EXPORT_SYMBOL(host1x_syncpt_put);
>
> void host1x_syncpt_deinit(struct host1x *host)
> {
> @@ -471,16 +478,48 @@ unsigned int host1x_syncpt_nb_mlocks(struct host1x
> *host)
> }
>
> /**
> - * host1x_syncpt_get() - obtain a syncpoint by ID
> + * host1x_syncpt_get_by_id() - obtain a syncpoint by ID
> + * @host: host1x controller
> + * @id: syncpoint ID
> + */
> +struct host1x_syncpt *host1x_syncpt_get_by_id(struct host1x *host,
> + unsigned int id)
> +{
> + if (id >= host->info->nb_pts)
> + return NULL;
> +
> + if (kref_get_unless_zero(&host->syncpt[id].ref))
> + return &host->syncpt[id];
> + else
> + return NULL;
> +}
> +EXPORT_SYMBOL(host1x_syncpt_get_by_id);
> +
> +/**
> + * host1x_syncpt_get_by_id_noref() - obtain a syncpoint by ID but don't
> + * increase the refcount.
> * @host: host1x controller
> * @id: syncpoint ID
> */
> -struct host1x_syncpt *host1x_syncpt_get(struct host1x *host, unsigned int id)
> +struct host1x_syncpt *host1x_syncpt_get_by_id_noref(struct host1x *host,
> + unsigned int id)
> {
> if (id >= host->info->nb_pts)
> return NULL;
>
> - return host->syncpt + id;
> + return &host->syncpt[id];
> +}
> +EXPORT_SYMBOL(host1x_syncpt_get_by_id_noref);
> +
> +/**
> + * host1x_syncpt_get() - increment syncpoint refcount
> + * @sp: syncpoint
> + */
> +struct host1x_syncpt *host1x_syncpt_get(struct host1x_syncpt *sp)
> +{
> + kref_get(&sp->ref);
> +
> + return sp;
> }
> EXPORT_SYMBOL(host1x_syncpt_get);
Hello, Mikko!
What do you think about to open-code all the host1x structs by moving
them all out into the public linux/host1x.h? Then we could inline all
these trivial single-line functions by having them defined in the public
header. This will avoid all the unnecessary overhead by allowing
compiler to optimize the code nicely.
Of course this could be a separate change and it could be done sometime
later, I just wanted to share this quick thought for the start of the
review.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v1 1/2] video: fbdev: aty: radeon_pm: remove redundant CONFIG_PM container
___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v1 2/2] fbdev: radeonfb:use generic power management
Drivers using legacy PCI power management .suspend()/.resume() callbacks
have to manage PCI states and device's PM states themselves. They also
need to take care of standard configuration registers.
Switch to generic power management framework using a "struct dev_pm_ops"
variable to take the unnecessary load from the driver.
This also avoids the need for the driver to directly call most of the PCI
helper functions and device power state control functions, as through
the generic framework PCI Core takes care of the necessary operations,
and drivers are required to do only device-specific jobs.
Signed-off-by: Vaibhav Gupta
---
drivers/video/fbdev/aty/radeon_base.c | 10 +---
drivers/video/fbdev/aty/radeon_pm.c | 36 +--
drivers/video/fbdev/aty/radeonfb.h| 3 +--
3 files changed, 35 insertions(+), 14 deletions(-)
diff --git a/drivers/video/fbdev/aty/radeon_base.c
b/drivers/video/fbdev/aty/radeon_base.c
index e116a3f9ad56..232dbe154666 100644
--- a/drivers/video/fbdev/aty/radeon_base.c
+++ b/drivers/video/fbdev/aty/radeon_base.c
@@ -2559,16 +2559,18 @@ static void radeonfb_pci_unregister(struct pci_dev
*pdev)
framebuffer_release(info);
}
+#ifdef CONFIG_PM
+#define RADEONFB_PCI_PM_OPS (&radeonfb_pci_pm_ops)
+#else
+#define RADEONFB_PCI_PM_OPS NULL
+#endif
static struct pci_driver radeonfb_driver = {
.name = "radeonfb",
.id_table = radeonfb_pci_table,
.probe = radeonfb_pci_register,
.remove = radeonfb_pci_unregister,
-#ifdef CONFIG_PM
- .suspend= radeonfb_pci_suspend,
- .resume = radeonfb_pci_resume,
-#endif /* CONFIG_PM */
+ .driver.pm = RADEONFB_PCI_PM_OPS,
};
#ifndef MODULE
diff --git a/drivers/video/fbdev/aty/radeon_pm.c
b/drivers/video/fbdev/aty/radeon_pm.c
index b9af70bd656a..352d0bb4773a 100644
--- a/drivers/video/fbdev/aty/radeon_pm.c
+++ b/drivers/video/fbdev/aty/radeon_pm.c
@@ -2611,8 +2611,9 @@ static void radeon_set_suspend(struct radeonfb_info
*rinfo, int suspend)
}
}
-int radeonfb_pci_suspend(struct pci_dev *pdev, pm_message_t mesg)
+static int radeonfb_pci_suspend_late(struct device *dev, pm_message_t mesg)
{
+ struct pci_dev *pdev = to_pci_dev(dev);
struct fb_info *info = pci_get_drvdata(pdev);
struct radeonfb_info *rinfo = info->par;
@@ -2660,11 +2661,6 @@ int radeonfb_pci_suspend(struct pci_dev *pdev,
pm_message_t mesg)
pmac_suspend_agp_for_card(pdev);
#endif /* CONFIG_PPC_PMAC */
- /* It's unclear whether or when the generic code will do that, so let's
-* do it ourselves. We save state before we do any power management
-*/
- pci_save_state(pdev);
-
/* If we support wakeup from poweroff, we save all regs we can
including cfg
* space
*/
@@ -2689,7 +2685,6 @@ int radeonfb_pci_suspend(struct pci_dev *pdev,
pm_message_t mesg)
msleep(20);
OUTREG(LVDS_GEN_CNTL, INREG(LVDS_GEN_CNTL) &
~(LVDS_DIGON));
}
- pci_disable_device(pdev);
}
/* If we support D2, we go to it (should be fixed later with a flag
forcing
* D3 only for some laptops)
@@ -2705,6 +2700,21 @@ int radeonfb_pci_suspend(struct pci_dev *pdev,
pm_message_t mesg)
return 0;
}
+static int radeonfb_pci_suspend(struct device *dev)
+{
+ return radeonfb_pci_suspend_late(dev, PMSG_SUSPEND);
+}
+
+static int radeonfb_pci_hibernate(struct device *dev)
+{
+ return radeonfb_pci_suspend_late(dev, PMSG_HIBERNATE);
+}
+
+static int radeonfb_pci_freeze(struct device *dev)
+{
+ return radeonfb_pci_suspend_late(dev, PMSG_FREEZE);
+}
+
static int radeon_check_power_loss(struct radeonfb_info *rinfo)
{
return rinfo->save_regs[4] != INPLL(CLK_PIN_CNTL) ||
@@ -2712,8 +2722,9 @@ static int radeon_check_power_loss(struct radeonfb_info
*rinfo)
rinfo->save_regs[3] != INPLL(SCLK_CNTL);
}
-int radeonfb_pci_resume(struct pci_dev *pdev)
+static int radeonfb_pci_resume(struct device *dev)
{
+ struct pci_dev *pdev = to_pci_dev(dev);
struct fb_info *info = pci_get_drvdata(pdev);
struct radeonfb_info *rinfo = info->par;
int rc = 0;
@@ -2795,6 +2806,15 @@ int radeonfb_pci_resume(struct pci_dev *pdev)
return rc;
}
+const struct dev_pm_ops radeonfb_pci_pm_ops = {
+ .suspend= radeonfb_pci_suspend,
+ .resume = radeonfb_pci_resume,
+ .freeze = radeonfb_pci_freeze,
+ .thaw = radeonfb_pci_resume,
+ .poweroff = radeonfb_pci_hibernate,
+ .restore= radeonfb_pci_resume,
+};
+
#ifdef CONFIG_PPC__disabled
static void radeonfb_early_resume(void *data)
{
diff --git a/drivers/video/fbdev/aty/radeonfb.h
b/drivers/video/fbdev/aty/radeonfb.h
index 131b34dd65af..93f403cbb415 100644
--- a/drivers/video/fbdev/aty/radeonfb.h
+++ b/drivers/vid
[PATCH 2/2] drm/sun4i: mixer: Extend regmap max_register
Better guess. Secondary CSC registers are from 0xF.
Signed-off-by: Martin Cerveny
---
drivers/gpu/drm/sun4i/sun8i_mixer.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/sun4i/sun8i_mixer.c
b/drivers/gpu/drm/sun4i/sun8i_mixer.c
index cc4fb916318f..c3304028e3dc 100644
--- a/drivers/gpu/drm/sun4i/sun8i_mixer.c
+++ b/drivers/gpu/drm/sun4i/sun8i_mixer.c
@@ -307,7 +307,7 @@ static struct regmap_config sun8i_mixer_regmap_config = {
.reg_bits = 32,
.val_bits = 32,
.reg_stride = 4,
- .max_register = 0xbfffc, /* guessed */
+ .max_register = 0xc, /* guessed */
};
static int sun8i_mixer_of_get_id(struct device_node *node)
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v1 1/2] video: fbdev: aty: radeon_pm: remove redundant CONFIG_PM container
Fixes commit 42ddb453a0cd ("radeon: Conditionally compile PM code")
Before the above mentioned patch, codes between the line number 547 and
2803 were already inside "#ifdef CONFIG_PM" container. Thus, addition of
"#if defined(CONFIG_PM)" was not required in the patch. It also affected
the "#ifdef CONFIG_PPC_OF" container (line 1943-2510).
>From the current snapshot of radeon_pm.c, remove:
1434 | #if defined(CONFIG_PM)
and,
2213 | #endif
This removes the redundant CONFIG_PM directive as well as fixes the
CONFIG_PPC (earlier CONFIG_PPC_OF) container.
Signed-off-by: Vaibhav Gupta
---
drivers/video/fbdev/aty/radeon_pm.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/video/fbdev/aty/radeon_pm.c
b/drivers/video/fbdev/aty/radeon_pm.c
index 7c4483c7f313..b9af70bd656a 100644
--- a/drivers/video/fbdev/aty/radeon_pm.c
+++ b/drivers/video/fbdev/aty/radeon_pm.c
@@ -1431,7 +1431,6 @@ static void radeon_pm_full_reset_sdram(struct
radeonfb_info *rinfo)
mdelay( 15);
}
-#if defined(CONFIG_PM)
#if defined(CONFIG_X86) || defined(CONFIG_PPC_PMAC)
static void radeon_pm_reset_pad_ctlr_strength(struct radeonfb_info *rinfo)
{
@@ -2210,7 +2209,6 @@ static void radeon_reinitialize_M9P(struct radeonfb_info
*rinfo)
radeon_pm_m10_enable_lvds_spread_spectrum(rinfo);
}
#endif
-#endif
#if 0 /* Not ready yet */
static void radeon_reinitialize_QW(struct radeonfb_info *rinfo)
--
2.27.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Linux-kernel-mentees] [PATCH v1 1/2] video: fbdev: aty: radeon_pm: remove redundant CONFIG_PM container
On Mon, Sep 07, 2020 at 08:48:10AM +0200, Greg KH wrote: > On Mon, Sep 07, 2020 at 12:03:47PM +0530, Vaibhav Gupta wrote: > > > > Why did you send empty emails out? > > greg k-h I was trying to re-ping the patches. Guess it went empty. I will send patches again. Vaibhav ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v1 2/2] fbdev: radeonfb:use generic power management
___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v1 0/2] video: fbdev: radeonfb: PCI PM framework upgrade and fix-ups.
Linux Kernel Mentee: Remove Legacy Power Management.
The original goal of the patch series is to upgrade the power management
framework of radeonfb fbdev driver. This has been done by upgrading .suspend()
and .resume() callbacks.
The upgrade makes sure that the involvement of PCI Core does not change the
order of operations executed in a driver. Thus, does not change its behavior.
During this process, it was found that "#if defined(CONFIG_PM)" at line 1434 is
redundant. This was introduced in the commit
42ddb453a0cd ("radeon: Conditionally compile PM code").
Before 42ddb453a0cd:
$ git show 65122f7e80b5:drivers/video/aty/radeon_pm.c | grep -n
"#ifdef\|#if\|#else\|#endif\|#elif\|#ifndef"
Based on output in terminal:
547:#ifdef CONFIG_PM
|-- 959:#ifdef CONFIG_PPC_PMAC
|-- 972:#endif
|-- 1291:#ifdef CONFIG_PPC_OF
|-- 1301:#endif /* CONFIG_PPC_OF */
|-- 1943:#ifdef CONFIG_PPC_OF
|-- 2206:#if 0 /* Not ready yet */
|-- 2508:#endif /* 0 */
|-- 2510:#endif /* CONFIG_PPC_OF */
|-- 2648:#ifdef CONFIG_PPC_PMAC
|-- 2654:#endif /* CONFIG_PPC_PMAC */
|-- 2768:#ifdef CONFIG_PPC_PMAC
|-- 2774:#endif /* CONFIG_PPC_PMAC */
|-- 2791:#ifdef CONFIG_PPC_OF__disabled
|-- 2801:#endif /* CONFIG_PPC_OF */
2803:#endif /* CONFIG_PM */
After 42ddb453a0cd:
$ git show 42ddb453a0cd:drivers/video/aty/radeon_pm.c | grep -n
"#ifdef\|#if\|#else\|#endif\|#elif\|#ifndef"
Based on output in terminal:
547:#ifdef CONFIG_PM
|-- 959:#ifdef CONFIG_PPC_PMAC
|-- 972:#endif
|-- 1291:#ifdef CONFIG_PPC_OF
|-- 1301:#endif /* CONFIG_PPC_OF */
|-- 1430:#if defined(CONFIG_PM)
|-- 1431:#if defined(CONFIG_X86) || defined(CONFIG_PPC_PMAC)
|-- 1944:#endif
|-- 1946:#ifdef CONFIG_PPC_OF
|-- 1947:#ifdef CONFIG_PPC_PMAC
|-- 2208:#endif
|-- 2209:#endif
|-- 2211:#if 0 /* Not ready yet */
|-- 2513:#endif /* 0 */
|-- 2515:#endif /* CONFIG_PPC_OF */
|-- 2653:#ifdef CONFIG_PPC_PMAC
|-- 2659:#endif /* CONFIG_PPC_PMAC */
|-- 2773:#ifdef CONFIG_PPC_PMAC
|-- 2779:#endif /* CONFIG_PPC_PMAC */
|-- 2796:#ifdef CONFIG_PPC_OF__disabled
|-- 2806:#endif /* CONFIG_PPC_OF */
2808:#endif /* CONFIG_PM */
This also affected the CONFIG_PPC_OF container (line 1943 at commit
65122f7e80b5)
The patch-series fixes it along with PM upgrade.
All patches are compile-tested only.
Test tools:
- Compiler: gcc (GCC) 10.1.0
- allmodconfig build: make -j$(nproc) W=1 all
Vaibhav Gupta (2):
video: fbdev: aty: radeon_pm: remove redundant CONFIG_PM container
fbdev: radeonfb:use generic power management
drivers/video/fbdev/aty/radeon_base.c | 10 ---
drivers/video/fbdev/aty/radeon_pm.c | 38 ---
drivers/video/fbdev/aty/radeonfb.h| 3 +--
3 files changed, 35 insertions(+), 16 deletions(-)
--
2.27.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 6/7] drm: Validate encoder->possible_crtcs
On 11.02.20 18:04, Daniel Vetter wrote:
> On Tue, Feb 11, 2020 at 06:22:07PM +0200, Ville Syrjala wrote:
>> From: Ville Syrjälä
>>
>> WARN if the encoder possible_crtcs is effectively empty or contains
>> bits for non-existing crtcs.
>>
>> v2: Move to drm_mode_config_validate() (Daniel)
>> Make the docs say we WARN when this is wrong (Daniel)
>> Extract full_crtc_mask()
>>
>> Cc: Thomas Zimmermann
>> Cc: Daniel Vetter
>> Signed-off-by: Ville Syrjälä
>
> When pushing the fixup needs to be applied before the validation patch
> here, because we don't want to anger the bisect gods.
>
> Reviewed-by: Daniel Vetter
>
> I think with the fixup we should be good enough with the existing nonsense
> in drivers. Fingers crossed.
> -Daniel
>
>
>> ---
>> drivers/gpu/drm/drm_mode_config.c | 27 ++-
>> include/drm/drm_encoder.h | 2 +-
>> 2 files changed, 27 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/drm_mode_config.c
>> b/drivers/gpu/drm/drm_mode_config.c
>> index afc91447293a..4c1b350ddb95 100644
>> --- a/drivers/gpu/drm/drm_mode_config.c
>> +++ b/drivers/gpu/drm/drm_mode_config.c
>> @@ -581,6 +581,29 @@ static void validate_encoder_possible_clones(struct
>> drm_encoder *encoder)
>> encoder->possible_clones, encoder_mask);
>> }
>>
>> +static u32 full_crtc_mask(struct drm_device *dev)
>> +{
>> +struct drm_crtc *crtc;
>> +u32 crtc_mask = 0;
>> +
>> +drm_for_each_crtc(crtc, dev)
>> +crtc_mask |= drm_crtc_mask(crtc);
>> +
>> +return crtc_mask;
>> +}
>> +
>> +static void validate_encoder_possible_crtcs(struct drm_encoder *encoder)
>> +{
>> +u32 crtc_mask = full_crtc_mask(encoder->dev);
>> +
>> +WARN((encoder->possible_crtcs & crtc_mask) == 0 ||
>> + (encoder->possible_crtcs & ~crtc_mask) != 0,
>> + "Bogus possible_crtcs: "
>> + "[ENCODER:%d:%s] possible_crtcs=0x%x (full crtc mask=0x%x)\n",
>> + encoder->base.id, encoder->name,
>> + encoder->possible_crtcs, crtc_mask);
>> +}
>> +
>> void drm_mode_config_validate(struct drm_device *dev)
>> {
>> struct drm_encoder *encoder;
>> @@ -588,6 +611,8 @@ void drm_mode_config_validate(struct drm_device *dev)
>> drm_for_each_encoder(encoder, dev)
>> fixup_encoder_possible_clones(encoder);
>>
>> -drm_for_each_encoder(encoder, dev)
>> +drm_for_each_encoder(encoder, dev) {
>> validate_encoder_possible_clones(encoder);
>> +validate_encoder_possible_crtcs(encoder);
>> +}
>> }
>> diff --git a/include/drm/drm_encoder.h b/include/drm/drm_encoder.h
>> index 3741963b9587..b236269f41ac 100644
>> --- a/include/drm/drm_encoder.h
>> +++ b/include/drm/drm_encoder.h
>> @@ -142,7 +142,7 @@ struct drm_encoder {
>> * the bits for all &drm_crtc objects this encoder can be connected to
>> * before calling drm_dev_register().
>> *
>> - * In reality almost every driver gets this wrong.
>> + * You will get a WARN if you get this wrong in the driver.
>> *
>> * Note that since CRTC objects can't be hotplugged the assigned indices
>> * are stable and hence known before registering all objects.
>> --
>> 2.24.1
>>
>
Triggers on an Advantech AIMB-228 (R1505G, 3 DP outputs):
[ 14.033246] [ cut here ]
[ 14.033248] Bogus possible_crtcs: [ENCODER:65:TMDS-65] possible_crtcs=0xf
(full crtc mask=0x7)
[ 14.033279] WARNING: CPU: 0 PID: 282 at
../drivers/gpu/drm/drm_mode_config.c:622 drm_mode_config_validate+0x17d/0x200
[drm]
[ 14.033279] Modules linked in: amdgpu(E+) mfd_core(E)
snd_hda_codec_realtek(E) kvm_amd(E) gpu_sched(E) i2c_algo_bit(E) ttm(E)
snd_hda_codec_generic(E) kvm(E) ledtrig_audio(E) snd_hda_codec_hdmi(E)
drm_kms_helper(E) snd_hda_intel(E) snd_intel_dspcfg(E) snd_hda_codec(E) cec(E)
snd_hwdep(E) drm(E) irqbypass(E) snd_hda_core(E) crc32_pclmul(E) snd_pcm(E)
ghash_clmulni_intel(E) snd_timer(E) sg(E) aesni_intel(E) snd(E) ccp(E)
soundcore(E) rng_core(E) glue_helper(E) libaes(E) crypto_simd(E) k10temp(E)
efi_pstore(E) sp5100_tco(E) evdev(E) cryptd(E) pcspkr(E) efivars(E) video(E)
button(E) acpi_cpufreq(E) w83627hf_wdt(E) watchdog(E) nct6775(E) hwmon_vid(E)
efivarfs(E) ip_tables(E) x_tables(E) autofs4(E) ext4(E) crc32c_generic(E)
crc16(E) mbcache(E) jbd2(E) sd_mod(E) t10_pi(E) crc_t10dif(E)
crct10dif_generic(E) uas(E) usb_storage(E) ahci(E) libahci(E) xhci_pci(E)
r8169(E) realtek(E) mdio_devres(E) xhci_hcd(E) libata(E) i2c_amd_mp2_pci(E)
crct10dif_pclmul(E) crct10dif_common(E) scsi_mod(E)
[ 14.033306] crc32c_intel(E) i2c_piix4(E) usbcore(E) libphy(E)
[ 14.033310] CPU: 0 PID: 282 Comm: systemd-udevd Tainted: GE
5.9.0-rc3+ #2
[ 14.033311] Hardware name: Default string Default string/Default string,
BIOS 5.0.1.4 02/14/2020
[ 14.033324] RIP: 0010:drm_mode_config_validate+0x17d/0x200 [drm]
[ 14.033327] Code: 42 f0 75 e6 41 85 f8 74 09 44 89 c0 f7 d0 85 f8 74 1a 49
8b 54 24
Re: [PATCH v1 0/2] video: fbdev: radeonfb: PCI PM framework upgrade and fix-ups.
Please review this patch-series. Thank you Vaibhav Gupta ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/3] backlight: pwm_bl: Artificially add 0% during interpolation
On Fri, Sep 04, 2020 at 12:38:22PM +0100, Daniel Thompson wrote: > On Mon, Jul 20, 2020 at 09:25:21PM -0700, Alexandru Stan wrote: > > Some displays need the low end of the curve cropped in order to make > > them happy. In that case we still want to have the 0% point, even though > > anything between 0% and 5%(example) would be skipped. > > For backlights it is not defined that 0 means off and, to be honest, 0 > means off is actually rather weird for anything except transflexive > or front lit reflective displays[1]. There is a problem on several > systems that when the backlight slider is reduced to zero you can't > see the screen properly to turn it back up. This patch looks like it > would make that problem worse by hurting systems with will written > device trees. > > There is some nasty legacy here: some backlight displays that are off > at zero and that sucks because userspace doesn't know whether zero is > off or lowest possible setting. > > Nevertheless perhaps a better way to handle this case is for 0 to map to > 5% power and for the userspace to turn the backlight on/off as final > step in an animated backlight fade out (and one again for a fade in). Afaik chromeos encodes "0 means off" somewhere in there stack. We've gotten similar patches for the i915 backlight driver when we started obeying the panel's lower limit in our pwm backlight driver thing that's sometimes used instead of acpi. There's also the problem that with fancy panels with protocol (dsi, edp, ...) shutting of the backlight completely out of the proper power sequence hangs the panel (for some panels at least), so providing a backlight off that doesn't go through the drm modeset sequence isn't always possible. It's a bit a mess indeed :-/ -Daniel > > > Daniel. > > > > > Signed-off-by: Alexandru Stan > > --- > > > > drivers/video/backlight/pwm_bl.c | 8 > > 1 file changed, 8 insertions(+) > > > > diff --git a/drivers/video/backlight/pwm_bl.c > > b/drivers/video/backlight/pwm_bl.c > > index 5193a72305a2..b24711ddf504 100644 > > --- a/drivers/video/backlight/pwm_bl.c > > +++ b/drivers/video/backlight/pwm_bl.c > > @@ -349,6 +349,14 @@ static int pwm_backlight_parse_dt(struct device *dev, > > /* Fill in the last point, since no line starts here. */ > > table[x2] = y2; > > > > + /* > > +* If we don't start at 0 yet we're increasing, assume > > +* the dts wanted to crop the low end of the range, so > > +* insert a 0 to provide a display off mode. > > +*/ > > + if (table[0] > 0 && table[0] < table[num_levels - 1]) > > + table[0] = 0; > > + > > /* > > * As we use interpolation lets remove current > > * brightness levels table and replace for the > > -- > > 2.27.0 > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v1 0/2] video: fbdev: radeonfb: PCI PM framework upgrade and fix-ups.
On Thu, Aug 06, 2020 at 12:52:54PM +0530, Vaibhav Gupta wrote:
> Linux Kernel Mentee: Remove Legacy Power Management.
>
> The original goal of the patch series is to upgrade the power management
> framework of radeonfb fbdev driver. This has been done by upgrading .suspend()
> and .resume() callbacks.
>
> The upgrade makes sure that the involvement of PCI Core does not change the
> order of operations executed in a driver. Thus, does not change its behavior.
>
> During this process, it was found that "#if defined(CONFIG_PM)" at line 1434
> is
> redundant. This was introduced in the commit
> 42ddb453a0cd ("radeon: Conditionally compile PM code").
I do wonder whether it wouldn't be better to just outright delete these,
we have the drm radeon driver for pretty much all the same hardware ...
-Daniel
>
>
>
> Before 42ddb453a0cd:
> $ git show 65122f7e80b5:drivers/video/aty/radeon_pm.c | grep -n
> "#ifdef\|#if\|#else\|#endif\|#elif\|#ifndef"
>
> Based on output in terminal:
>
> 547:#ifdef CONFIG_PM
>|-- 959:#ifdef CONFIG_PPC_PMAC
>|-- 972:#endif
>|-- 1291:#ifdef CONFIG_PPC_OF
>|-- 1301:#endif /* CONFIG_PPC_OF */
>|-- 1943:#ifdef CONFIG_PPC_OF
>|-- 2206:#if 0 /* Not ready yet */
>|-- 2508:#endif /* 0 */
>|-- 2510:#endif /* CONFIG_PPC_OF */
>|-- 2648:#ifdef CONFIG_PPC_PMAC
>|-- 2654:#endif /* CONFIG_PPC_PMAC */
>|-- 2768:#ifdef CONFIG_PPC_PMAC
>|-- 2774:#endif /* CONFIG_PPC_PMAC */
>|-- 2791:#ifdef CONFIG_PPC_OF__disabled
>|-- 2801:#endif /* CONFIG_PPC_OF */
> 2803:#endif /* CONFIG_PM */
>
>
>
> After 42ddb453a0cd:
> $ git show 42ddb453a0cd:drivers/video/aty/radeon_pm.c | grep -n
> "#ifdef\|#if\|#else\|#endif\|#elif\|#ifndef"
>
> Based on output in terminal:
>
> 547:#ifdef CONFIG_PM
>|-- 959:#ifdef CONFIG_PPC_PMAC
>|-- 972:#endif
>|-- 1291:#ifdef CONFIG_PPC_OF
>|-- 1301:#endif /* CONFIG_PPC_OF */
>|-- 1430:#if defined(CONFIG_PM)
>|-- 1431:#if defined(CONFIG_X86) ||
> defined(CONFIG_PPC_PMAC)
>|-- 1944:#endif
>|-- 1946:#ifdef CONFIG_PPC_OF
>|-- 1947:#ifdef CONFIG_PPC_PMAC
>|-- 2208:#endif
>|-- 2209:#endif
>|-- 2211:#if 0 /* Not ready yet */
>|-- 2513:#endif /* 0 */
>|-- 2515:#endif /* CONFIG_PPC_OF */
>|-- 2653:#ifdef CONFIG_PPC_PMAC
>|-- 2659:#endif /* CONFIG_PPC_PMAC */
>|-- 2773:#ifdef CONFIG_PPC_PMAC
>|-- 2779:#endif /* CONFIG_PPC_PMAC */
>|-- 2796:#ifdef CONFIG_PPC_OF__disabled
>|-- 2806:#endif /* CONFIG_PPC_OF */
> 2808:#endif /* CONFIG_PM */
>
>
>
> This also affected the CONFIG_PPC_OF container (line 1943 at commit
> 65122f7e80b5)
>
> The patch-series fixes it along with PM upgrade.
>
> All patches are compile-tested only.
>
> Test tools:
> - Compiler: gcc (GCC) 10.1.0
> - allmodconfig build: make -j$(nproc) W=1 all
>
> Vaibhav Gupta (2):
> video: fbdev: aty: radeon_pm: remove redundant CONFIG_PM container
> fbdev: radeonfb:use generic power management
>
> drivers/video/fbdev/aty/radeon_base.c | 10 ---
> drivers/video/fbdev/aty/radeon_pm.c | 38 ---
> drivers/video/fbdev/aty/radeonfb.h| 3 +--
> 3 files changed, 35 insertions(+), 16 deletions(-)
>
> --
> 2.27.0
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] drm/amdgpu/dc: Require primary plane to be enabled whenever the CRTC is
On Fri, Sep 04, 2020 at 12:43:04PM +0200, Michel Dänzer wrote:
> From: Michel Dänzer
>
> Don't check drm_crtc_state::active for this either, per its
> documentation in include/drm/drm_crtc.h:
>
> * Hence drivers must not consult @active in their various
> * &drm_mode_config_funcs.atomic_check callback to reject an atomic
> * commit.
>
> atomic_remove_fb disables the CRTC as needed for disabling the primary
> plane.
>
> This prevents at least the following problems if the primary plane gets
> disabled (e.g. due to destroying the FB assigned to the primary plane,
> as happens e.g. with mutter in Wayland mode):
>
> * The legacy cursor ioctl returned EINVAL for a non-0 cursor FB ID
> (which enables the cursor plane).
> * If the cursor plane was enabled, changing the legacy DPMS property
> value from off to on returned EINVAL.
>
> v2:
> * Minor changes to code comment and commit log, per review feedback.
>
> GitLab: https://gitlab.gnome.org/GNOME/mutter/-/issues/1108
> GitLab: https://gitlab.gnome.org/GNOME/mutter/-/issues/1165
> GitLab: https://gitlab.gnome.org/GNOME/mutter/-/issues/1344
> Suggested-by: Daniel Vetter
> Signed-off-by: Michel Dänzer
Commit message agrees with my understand of this maze now, so:
Acked-by: Daniel Vetter
> ---
> .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 32 ++-
> 1 file changed, 10 insertions(+), 22 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> index 45f5f4b7024d..c5f9452490d6 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> @@ -5269,19 +5269,6 @@ static void dm_crtc_helper_disable(struct drm_crtc
> *crtc)
> {
> }
>
> -static bool does_crtc_have_active_cursor(struct drm_crtc_state
> *new_crtc_state)
> -{
> - struct drm_device *dev = new_crtc_state->crtc->dev;
> - struct drm_plane *plane;
> -
> - drm_for_each_plane_mask(plane, dev, new_crtc_state->plane_mask) {
> - if (plane->type == DRM_PLANE_TYPE_CURSOR)
> - return true;
> - }
> -
> - return false;
> -}
> -
> static int count_crtc_active_planes(struct drm_crtc_state *new_crtc_state)
> {
> struct drm_atomic_state *state = new_crtc_state->state;
> @@ -5345,19 +5332,20 @@ static int dm_crtc_helper_atomic_check(struct
> drm_crtc *crtc,
> return ret;
> }
>
> - /* In some use cases, like reset, no stream is attached */
> - if (!dm_crtc_state->stream)
> - return 0;
> -
> /*
> - * We want at least one hardware plane enabled to use
> - * the stream with a cursor enabled.
> + * We require the primary plane to be enabled whenever the CRTC is,
> otherwise
> + * drm_mode_cursor_universal may end up trying to enable the cursor
> plane while all other
> + * planes are disabled, which is not supported by the hardware. And
> there is legacy
> + * userspace which stops using the HW cursor altogether in response to
> the resulting EINVAL.
>*/
> - if (state->enable && state->active &&
> - does_crtc_have_active_cursor(state) &&
> - dm_crtc_state->active_planes == 0)
> + if (state->enable &&
> + !(state->plane_mask & drm_plane_mask(crtc->primary)))
> return -EINVAL;
>
> + /* In some use cases, like reset, no stream is attached */
> + if (!dm_crtc_state->stream)
> + return 0;
> +
> if (dc_validate_stream(dc, dm_crtc_state->stream) == DC_OK)
> return 0;
>
> --
> 2.28.0
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/bridge/synopsys: dsi: allow sending longer LP commands
On 01/07/2020 16:31, Yannick Fertre wrote: > From: Antonio Borneo > > Current code does not properly computes the max length of LP > commands that can be send during H or V sync, and rely on static > values. > Limiting the max LP length to 4 byte during the V-sync is overly > conservative. > > Relax the limit and allows longer LP commands (16 bytes) to be > sent during V-sync. > > Signed-off-by: Antonio Borneo > --- > drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 17 + > 1 file changed, 9 insertions(+), 8 deletions(-) > > diff --git a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c > b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c > index d580b2aa4ce9..1a24ea648ef8 100644 > --- a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c > +++ b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c > @@ -360,6 +360,15 @@ static void dw_mipi_message_config(struct dw_mipi_dsi > *dsi, > bool lpm = msg->flags & MIPI_DSI_MSG_USE_LPM; > u32 val = 0; > > + /* > + * TODO dw drv improvements > + * largest packet sizes during hfp or during vsa/vpb/vfp > + * should be computed according to byte lane, lane number and only > + * if sending lp cmds in high speed is enable (PHY_TXREQUESTCLKHS) > + */ > + dsi_write(dsi, DSI_DPI_LP_CMD_TIM, OUTVACT_LPCMD_TIME(16) > + | INVACT_LPCMD_TIME(4)); > + > if (msg->flags & MIPI_DSI_MSG_REQ_ACK) > val |= ACK_RQST_EN; > if (lpm) > @@ -611,14 +620,6 @@ static void dw_mipi_dsi_dpi_config(struct dw_mipi_dsi > *dsi, > dsi_write(dsi, DSI_DPI_VCID, DPI_VCID(dsi->channel)); > dsi_write(dsi, DSI_DPI_COLOR_CODING, color); > dsi_write(dsi, DSI_DPI_CFG_POL, val); > - /* > - * TODO dw drv improvements > - * largest packet sizes during hfp or during vsa/vpb/vfp > - * should be computed according to byte lane, lane number and only > - * if sending lp cmds in high speed is enable (PHY_TXREQUESTCLKHS) > - */ > - dsi_write(dsi, DSI_DPI_LP_CMD_TIM, OUTVACT_LPCMD_TIME(4) > - | INVACT_LPCMD_TIME(4)); > } > > static void dw_mipi_dsi_packet_handler_config(struct dw_mipi_dsi *dsi) > Tested on Amlogic AXG (v1.21a) Acked-by: Neil Armstrong Applying to drm-misc-next Thanks ! Neil ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/bridge/synopsys: dsi: add support for non-continuous HS clock
On 01/07/2020 21:42, Yannick Fertre wrote:
> From: Antonio Borneo
>
> Current code enables the HS clock when video mode is started or to
> send out a HS command, and disables the HS clock to send out a LP
> command. This is not what DSI spec specify.
>
> Enable HS clock either in command and in video mode.
> Set automatic HS clock management for panels and devices that
> support non-continuous HS clock.
>
> Signed-off-by: Antonio Borneo
> ---
> drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 9 +++--
> 1 file changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
> b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
> index d580b2aa4ce9..979acaa90d00 100644
> --- a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
> +++ b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
> @@ -365,7 +365,6 @@ static void dw_mipi_message_config(struct dw_mipi_dsi
> *dsi,
> if (lpm)
> val |= CMD_MODE_ALL_LP;
>
> - dsi_write(dsi, DSI_LPCLK_CTRL, lpm ? 0 : PHY_TXREQUESTCLKHS);
> dsi_write(dsi, DSI_CMD_MODE_CFG, val);
> }
>
> @@ -541,16 +540,22 @@ static void dw_mipi_dsi_video_mode_config(struct
> dw_mipi_dsi *dsi)
> static void dw_mipi_dsi_set_mode(struct dw_mipi_dsi *dsi,
>unsigned long mode_flags)
> {
> + u32 val;
> +
> dsi_write(dsi, DSI_PWR_UP, RESET);
>
> if (mode_flags & MIPI_DSI_MODE_VIDEO) {
> dsi_write(dsi, DSI_MODE_CFG, ENABLE_VIDEO_MODE);
> dw_mipi_dsi_video_mode_config(dsi);
> - dsi_write(dsi, DSI_LPCLK_CTRL, PHY_TXREQUESTCLKHS);
> } else {
> dsi_write(dsi, DSI_MODE_CFG, ENABLE_CMD_MODE);
> }
>
> + val = PHY_TXREQUESTCLKHS;
> + if (dsi->mode_flags & MIPI_DSI_CLOCK_NON_CONTINUOUS)
> + val |= AUTO_CLKLANE_CTRL;
> + dsi_write(dsi, DSI_LPCLK_CTRL, val);
> +
> dsi_write(dsi, DSI_PWR_UP, POWERUP);
> }
>
>
Tested on Amlogic AXG (v1.21a)
Acked-by: Neil Armstrong
Applying to drm-misc-next
Thanks !
Neil
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] drm/bridge/synopsys: dsi: allow LP commands in video mode
On 08/07/2020 16:08, Yannick Fertre wrote: > From: Antonio Borneo > > Current code only sends LP commands in command mode. > > Allows sending LP commands also in video mode by setting the > proper flag in DSI_VID_MODE_CFG. > > Signed-off-by: Antonio Borneo > --- > drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 8 > 1 file changed, 8 insertions(+) > > diff --git a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c > b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c > index 1a24ea648ef8..e9a0f42ff99f 100644 > --- a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c > +++ b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c > @@ -89,6 +89,7 @@ > #define VID_MODE_TYPE_NON_BURST_SYNC_EVENTS 0x1 > #define VID_MODE_TYPE_BURST 0x2 > #define VID_MODE_TYPE_MASK 0x3 > +#define ENABLE_LOW_POWER_CMD BIT(15) > #define VID_MODE_VPG_ENABLE BIT(16) > #define VID_MODE_VPG_HORIZONTAL BIT(24) > > @@ -376,6 +377,13 @@ static void dw_mipi_message_config(struct dw_mipi_dsi > *dsi, > > dsi_write(dsi, DSI_LPCLK_CTRL, lpm ? 0 : PHY_TXREQUESTCLKHS); > dsi_write(dsi, DSI_CMD_MODE_CFG, val); > + > + val = dsi_read(dsi, DSI_VID_MODE_CFG); > + if (lpm) > + val |= ENABLE_LOW_POWER_CMD; > + else > + val &= ~ENABLE_LOW_POWER_CMD; > + dsi_write(dsi, DSI_VID_MODE_CFG, val); > } > > static int dw_mipi_dsi_gen_pkt_hdr_write(struct dw_mipi_dsi *dsi, u32 > hdr_val) > Tested on Amlogic AXG (v1.21a) Acked-by: Neil Armstrong Applying to drm-misc-next Thanks ! Neil ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/1] drm/amdgpu: Convert to using devm_drm_dev_alloc()
On Sat, Sep 05, 2020 at 11:50:05AM -0400, Alex Deucher wrote: > On Thu, Sep 3, 2020 at 9:22 PM Luben Tuikov wrote: > > > > Convert to using devm_drm_dev_alloc(), > > as drm_dev_init() is going away. > > > > Signed-off-by: Luben Tuikov > > I think we can drop the final drm_put in the error case? I think the > unwinding in current devm code should take care of it. Same applies for the pci remove hook too. -Daniel > > Alex > > > --- > > drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 11 +++ > > 1 file changed, 3 insertions(+), 8 deletions(-) > > > > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c > > b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c > > index 146a85c8df1c..06d994187c24 100644 > > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c > > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c > > @@ -1142,18 +1142,13 @@ static int amdgpu_pci_probe(struct pci_dev *pdev, > > if (ret) > > return ret; > > > > - adev = kzalloc(sizeof(*adev), GFP_KERNEL); > > - if (!adev) > > - return -ENOMEM; > > + adev = devm_drm_dev_alloc(&pdev->dev, &kms_driver, typeof(*adev), > > ddev); > > + if (IS_ERR(adev)) > > + return PTR_ERR(adev); > > > > adev->dev = &pdev->dev; > > adev->pdev = pdev; > > ddev = adev_to_drm(adev); > > - ret = drm_dev_init(ddev, &kms_driver, &pdev->dev); > > - if (ret) > > - goto err_free; > > - > > - drmm_add_final_kfree(ddev, adev); > > > > if (!supports_atomic) > > ddev->driver_features &= ~DRIVER_ATOMIC; > > -- > > 2.28.0.394.ge197136389 > > > > ___ > > amd-gfx mailing list > > amd-...@lists.freedesktop.org > > https://lists.freedesktop.org/mailman/listinfo/amd-gfx -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/1] drm/amdgpu: Convert to using devm_drm_dev_alloc()
On Mon, Sep 07, 2020 at 10:06:08AM +0200, Daniel Vetter wrote: > On Sat, Sep 05, 2020 at 11:50:05AM -0400, Alex Deucher wrote: > > On Thu, Sep 3, 2020 at 9:22 PM Luben Tuikov wrote: > > > > > > Convert to using devm_drm_dev_alloc(), > > > as drm_dev_init() is going away. > > > > > > Signed-off-by: Luben Tuikov > > > > I think we can drop the final drm_put in the error case? I think the > > unwinding in current devm code should take care of it. > > Same applies for the pci remove hook too. KASAN run with unload should have caught this. I strongly recommend doing that for any changes to the unload code, it's way to easy to mix up something and release it in the wrong order or from the wrong callback or with the wrong managed (devm_ vs drmm_) functions. -Daniel > -Daniel > > > > Alex > > > > > --- > > > drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 11 +++ > > > 1 file changed, 3 insertions(+), 8 deletions(-) > > > > > > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c > > > b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c > > > index 146a85c8df1c..06d994187c24 100644 > > > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c > > > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c > > > @@ -1142,18 +1142,13 @@ static int amdgpu_pci_probe(struct pci_dev *pdev, > > > if (ret) > > > return ret; > > > > > > - adev = kzalloc(sizeof(*adev), GFP_KERNEL); > > > - if (!adev) > > > - return -ENOMEM; > > > + adev = devm_drm_dev_alloc(&pdev->dev, &kms_driver, typeof(*adev), > > > ddev); > > > + if (IS_ERR(adev)) > > > + return PTR_ERR(adev); > > > > > > adev->dev = &pdev->dev; > > > adev->pdev = pdev; > > > ddev = adev_to_drm(adev); > > > - ret = drm_dev_init(ddev, &kms_driver, &pdev->dev); > > > - if (ret) > > > - goto err_free; > > > - > > > - drmm_add_final_kfree(ddev, adev); > > > > > > if (!supports_atomic) > > > ddev->driver_features &= ~DRIVER_ATOMIC; > > > -- > > > 2.28.0.394.ge197136389 > > > > > > ___ > > > amd-gfx mailing list > > > amd-...@lists.freedesktop.org > > > https://lists.freedesktop.org/mailman/listinfo/amd-gfx > > -- > Daniel Vetter > Software Engineer, Intel Corporation > http://blog.ffwll.ch -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] drm/bridge: dw-mipi-dsi.c: Add VPG runtime config through debugfs
Hi,
On 06/04/2020 15:49, Angelo Ribeiro wrote:
> Add support for the video pattern generator (VPG) BER pattern mode and
> configuration in runtime.
>
> This enables using the debugfs interface to manipulate the VPG after
> the pipeline is set.
> Also, enables the usage of the VPG BER pattern.
>
> Changes in v2:
> - Added VID_MODE_VPG_MODE
> - Solved incompatible return type on __get and __set
>
> Reported-by: kbuild test robot
> Reported-by: Adrian Pop
> Cc: Gustavo Pimentel
> Cc: Joao Pinto
> Cc: Jose Abreu
> Signed-off-by: Angelo Ribeiro
> ---
> drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 98
> ---
> 1 file changed, 90 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
> b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
> index b18351b..9de3645 100644
> --- a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
> +++ b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
> @@ -91,6 +91,7 @@
> #define VID_MODE_TYPE_BURST 0x2
> #define VID_MODE_TYPE_MASK 0x3
> #define VID_MODE_VPG_ENABLE BIT(16)
> +#define VID_MODE_VPG_MODEBIT(20)
> #define VID_MODE_VPG_HORIZONTAL BIT(24)
>
> #define DSI_VID_PKT_SIZE 0x3c
> @@ -221,6 +222,21 @@
> #define PHY_STATUS_TIMEOUT_US1
> #define CMD_PKT_STATUS_TIMEOUT_US2
>
> +#ifdef CONFIG_DEBUG_FS
> +#define VPG_DEFS(name, dsi) \
> + ((void __force *)&((*dsi).vpg_defs.name))
> +
> +#define REGISTER(name, mask, dsi) \
> + { #name, VPG_DEFS(name, dsi), mask, dsi }
> +
> +struct debugfs_entries {
> + const char *name;
> + bool*reg;
> + u32 mask;
> + struct dw_mipi_dsi *dsi;
> +};
> +#endif /* CONFIG_DEBUG_FS */
> +
> struct dw_mipi_dsi {
> struct drm_bridge bridge;
> struct mipi_dsi_host dsi_host;
> @@ -238,9 +254,12 @@ struct dw_mipi_dsi {
>
> #ifdef CONFIG_DEBUG_FS
> struct dentry *debugfs;
> -
> - bool vpg;
> - bool vpg_horizontal;
> + struct debugfs_entries *debugfs_vpg;
> + struct {
> + bool vpg;
> + bool vpg_horizontal;
> + bool vpg_ber_pattern;
> + } vpg_defs;
> #endif /* CONFIG_DEBUG_FS */
>
> struct dw_mipi_dsi *master; /* dual-dsi master ptr */
> @@ -530,9 +549,11 @@ static void dw_mipi_dsi_video_mode_config(struct
> dw_mipi_dsi *dsi)
> val |= VID_MODE_TYPE_NON_BURST_SYNC_EVENTS;
>
> #ifdef CONFIG_DEBUG_FS
> - if (dsi->vpg) {
> + if (dsi->vpg_defs.vpg) {
> val |= VID_MODE_VPG_ENABLE;
> - val |= dsi->vpg_horizontal ? VID_MODE_VPG_HORIZONTAL : 0;
> + val |= dsi->vpg_defs.vpg_horizontal ?
> +VID_MODE_VPG_HORIZONTAL : 0;
> + val |= dsi->vpg_defs.vpg_ber_pattern ? VID_MODE_VPG_MODE : 0;
> }
> #endif /* CONFIG_DEBUG_FS */
>
> @@ -961,6 +982,68 @@ static const struct drm_bridge_funcs
> dw_mipi_dsi_bridge_funcs = {
>
> #ifdef CONFIG_DEBUG_FS
>
> +int dw_mipi_dsi_debugfs_write(void *data, u64 val)
> +{
> + struct debugfs_entries *vpg = data;
> + struct dw_mipi_dsi *dsi;
> + u32 mode_cfg;
> +
> + if (!vpg)
> + return -ENODEV;
> +
> + dsi = vpg->dsi;
> +
> + *vpg->reg = (bool)val;
> +
> + mode_cfg = dsi_read(dsi, DSI_VID_MODE_CFG);
> +
> + if (*vpg->reg)
> + mode_cfg |= vpg->mask;
> + else
> + mode_cfg &= ~vpg->mask;
> +
> + dsi_write(dsi, DSI_VID_MODE_CFG, mode_cfg);
> +
> + return 0;
> +}
> +
> +int dw_mipi_dsi_debugfs_show(void *data, u64 *val)
> +{
> + struct debugfs_entries *vpg = data;
> +
> + if (!vpg)
> + return -ENODEV;
> +
> + *val = *vpg->reg;
> +
> + return 0;
> +}
> +
> +DEFINE_DEBUGFS_ATTRIBUTE(fops_x32, dw_mipi_dsi_debugfs_show,
> + dw_mipi_dsi_debugfs_write, "%llu\n");
> +
> +static void debugfs_create_files(void *data)
> +{
> + struct dw_mipi_dsi *dsi = data;
> + struct debugfs_entries debugfs[] = {
> + REGISTER(vpg, VID_MODE_VPG_ENABLE, dsi),
> + REGISTER(vpg_horizontal, VID_MODE_VPG_HORIZONTAL, dsi),
> + REGISTER(vpg_ber_pattern, VID_MODE_VPG_MODE, dsi),
> + };
> + int i;
> +
> + dsi->debugfs_vpg = kmalloc(sizeof(debugfs), GFP_KERNEL);
> + if (!dsi->debugfs_vpg)
> + return;
> +
> + memcpy(dsi->debugfs_vpg, debugfs, sizeof(debugfs));
> +
> + for (i = 0; i < ARRAY_SIZE(debugfs); i++)
> + debugfs_create_file(dsi->debugfs_vpg[i].name, 0644,
> + dsi->debugfs, &dsi->debugfs_vpg[i],
> + &fops_x32);
> +}
> +
> static void dw_mipi_dsi_debugfs_init(struct dw_mipi_dsi *dsi)
> {
> dsi->debugfs = debugfs_create_dir(dev_name(dsi->dev), NULL);
> @@ -969,14 +1052,13 @
[PATCH 6/6] drm/meson: add support for MIPI-DSI transceiver
The Amlogic AXg SoCs embeds a Synopsys DW-MIPI-DSI transceiver (ver 1.21a),
with a custom
glue managing the IP resets, clock and data input similar to the DW-HDMI Glue
on other
Amlogic SoCs.
This adds support for the Glue managing the transceiver, mimicing the init flow
provided
by Amlogic to setup the ENCl encoder, the glue, the transceiver, the digital
D-PHY and the
Analog PHY in the proper way.
The DW-MIPI-DSI transceiver + D-PHY are directly clocked by the VCLK2 clock,
which pixel clock
is derived and feeds the ENCL encoder and the VIU pixel reader.
An optional "MEAS" clock can be enabled to measure the delay between each vsync
feeding the
DW-MIPI-DSI transceiver.
Signed-off-by: Neil Armstrong
---
drivers/gpu/drm/meson/Kconfig | 7 +
drivers/gpu/drm/meson/Makefile| 1 +
drivers/gpu/drm/meson/meson_dw_mipi_dsi.c | 562 ++
3 files changed, 570 insertions(+)
create mode 100644 drivers/gpu/drm/meson/meson_dw_mipi_dsi.c
diff --git a/drivers/gpu/drm/meson/Kconfig b/drivers/gpu/drm/meson/Kconfig
index 9f9281dd49f8..385f6f23839b 100644
--- a/drivers/gpu/drm/meson/Kconfig
+++ b/drivers/gpu/drm/meson/Kconfig
@@ -16,3 +16,10 @@ config DRM_MESON_DW_HDMI
default y if DRM_MESON
select DRM_DW_HDMI
imply DRM_DW_HDMI_I2S_AUDIO
+
+config DRM_MESON_DW_MIPI_DSI
+ tristate "MIPI DSI Synopsys Controller support for Amlogic Meson
Display"
+ depends on DRM_MESON
+ default y if DRM_MESON
+ select DRM_DW_MIPI_DSI
+ select GENERIC_PHY_MIPI_DPHY
diff --git a/drivers/gpu/drm/meson/Makefile b/drivers/gpu/drm/meson/Makefile
index 28a519cdf66b..2cc870e91182 100644
--- a/drivers/gpu/drm/meson/Makefile
+++ b/drivers/gpu/drm/meson/Makefile
@@ -5,3 +5,4 @@ meson-drm-y += meson_rdma.o meson_osd_afbcd.o
obj-$(CONFIG_DRM_MESON) += meson-drm.o
obj-$(CONFIG_DRM_MESON_DW_HDMI) += meson_dw_hdmi.o
+obj-$(CONFIG_DRM_MESON_DW_MIPI_DSI) += meson_dw_mipi_dsi.o
diff --git a/drivers/gpu/drm/meson/meson_dw_mipi_dsi.c
b/drivers/gpu/drm/meson/meson_dw_mipi_dsi.c
new file mode 100644
index ..bbe1294fce7c
--- /dev/null
+++ b/drivers/gpu/drm/meson/meson_dw_mipi_dsi.c
@@ -0,0 +1,562 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Copyright (C) 2016 BayLibre, SAS
+ * Author: Neil Armstrong
+ * Copyright (C) 2015 Amlogic, Inc. All rights reserved.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+#include
+#include
+
+#include
+#include
+#include
+#include
+
+#include "meson_drv.h"
+#include "meson_dw_mipi_dsi.h"
+#include "meson_registers.h"
+#include "meson_venc.h"
+
+#define DRIVER_NAME "meson-dw-mipi-dsi"
+#define DRIVER_DESC "Amlogic Meson MIPI-DSI DRM driver"
+
+/* MIPI DSI/VENC Color Format Definitions */
+#define MIPI_DSI_VENC_COLOR_30B 0x0
+#define MIPI_DSI_VENC_COLOR_24B 0x1
+#define MIPI_DSI_VENC_COLOR_18B 0x2
+#define MIPI_DSI_VENC_COLOR_16B 0x3
+
+#define COLOR_16BIT_CFG_1 0x0
+#define COLOR_16BIT_CFG_2 0x1
+#define COLOR_16BIT_CFG_3 0x2
+#define COLOR_18BIT_CFG_1 0x3
+#define COLOR_18BIT_CFG_2 0x4
+#define COLOR_24BIT 0x5
+#define COLOR_20BIT_LOOSE 0x6
+#define COLOR_24_BIT_YCBCR0x7
+#define COLOR_16BIT_YCBCR 0x8
+#define COLOR_30BIT 0x9
+#define COLOR_36BIT 0xa
+#define COLOR_12BIT 0xb
+#define COLOR_RGB_111 0xc
+#define COLOR_RGB_332 0xd
+#define COLOR_RGB_444 0xe
+
+/* MIPI DSI Relative REGISTERs Definitions */
+/* For MIPI_DSI_TOP_CNTL */
+#define BIT_DPI_COLOR_MODE20
+#define BIT_IN_COLOR_MODE 16
+#define BIT_CHROMA_SUBSAMPLE 14
+#define BIT_COMP2_SEL 12
+#define BIT_COMP1_SEL 10
+#define BIT_COMP0_SEL 8
+#define BIT_DE_POL 6
+#define BIT_HSYNC_POL 5
+#define BIT_VSYNC_POL 4
+#define BIT_DPICOLORM 3
+#define BIT_DPISHUTDN 2
+#define BIT_EDPITE_INTR_PULSE 1
+#define BIT_ERR_INTR_PULSE 0
+
+/* HHI Registers */
+#define HHI_VIID_CLK_DIV 0x128 /* 0x4a offset in data sheet */
+#define VCLK2_DIV_MASK 0xff
+#define VCLK2_DIV_EN BIT(16)
+#define VCLK2_DIV_RESETBIT(17)
+#define CTS_ENCL_SEL_MASK (0xf << 12)
+#define CTS_ENCL_SEL_SHIFT 12
+#define HHI_VIID_CLK_CNTL 0x12c /* 0x4b offset in data sheet */
+#define VCLK2_EN BIT(19)
+#define VCLK2_SEL_MASK (0x7 << 16)
+#define VCLK2_SEL_SHIFT16
+#define VCLK2_SOFT_RESET BIT(15)
+#define VCLK2_DIV1_EN BIT(0)
+#define HHI_VID_CLK_CNTL2 0x194 /* 0x65 offset in data sheet */
+#define CTS_ENCL_ENBIT(3)
+
+/**
+ * DOC: MIPI DSI
+ *
+ */
+
+struct meson_dw_mipi_dsi {
+ struct drm_encoder encoder;
+ struct meson_drm *priv;
+ struct device *dev;
+ void __iomem *ba
[PATCH 1/6] dt-bindings: display: amlogic, meson-vpu: add bindings for VPU found in AXG SoCs
The Amlogic AXG SoC family has a downgraded VPU supporting only MIPI-DSI output after it's ENCL DPI encoder output. Signed-off-by: Neil Armstrong --- .../bindings/display/amlogic,meson-vpu.yaml | 36 +-- 1 file changed, 33 insertions(+), 3 deletions(-) diff --git a/Documentation/devicetree/bindings/display/amlogic,meson-vpu.yaml b/Documentation/devicetree/bindings/display/amlogic,meson-vpu.yaml index a8d202c9d004..e2e7d99d8ace 100644 --- a/Documentation/devicetree/bindings/display/amlogic,meson-vpu.yaml +++ b/Documentation/devicetree/bindings/display/amlogic,meson-vpu.yaml @@ -31,8 +31,10 @@ description: | The Video Input Unit is in charge of the pixel scanout from the DDR memory. It fetches the frames addresses, stride and parameters from the "Canvas" memory. + On the AXG family, the Video Input Unit direclty reads from DDR memory. This part is also in charge of the CSC (Colorspace Conversion). It can handle 2 OSD Planes and 2 Video Planes. + On the AXG family, only a single OSD plane without scalins is supported. VPP: Video Post Processing -- @@ -49,11 +51,13 @@ description: | The VENC is composed of the multiple pixel encoders - ENCI : Interlace Video encoder for CVBS and Interlace HDMI - ENCP : Progressive Video Encoder for HDMI - - ENCL : LCD LVDS Encoder + - ENCL : LCD DPI Encoder The VENC Unit gets a Pixel Clocks (VCLK) from a dedicated HDMI PLL and clock tree and provides the scanout clock to the VPP and VIU. The ENCI is connected to a single VDAC for Composite Output. The ENCI and ENCP are connected to an on-chip HDMI Transceiver. + On the AXG and G12A family, the ENCL is connected to a DPI-to-DSI + transceiver. properties: compatible: @@ -65,6 +69,7 @@ properties: - amlogic,meson-gxm-vpu # GXM (S912) - const: amlogic,meson-gx-vpu - enum: + - amlogic,meson-axg-vpu # AXG (A113D, A113X) - amlogic,meson-g12a-vpu # G12A (S905X2, S905Y2, S905D2) reg: @@ -92,6 +97,11 @@ properties: description: A port node pointing to the HDMI-TX port node. + port@2: +type: object +description: + A port node pointing to the DPI port node. + "#address-cells": const: 1 @@ -102,11 +112,31 @@ required: - compatible - reg - interrupts - - port@0 - - port@1 - "#address-cells" - "#size-cells" +allOf: + - if: + properties: +compatible: + enum: +- amlogic,meson-gx-vpu +- amlogic,meson-g12a-vpu + +then: + required: +- port@0 +- port@1 + - if: + properties: +compatible: + enum: +- amlogic,meson-axg-vpu + +then: + required: +- port@2 + additionalProperties: false examples: -- 2.22.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/6] drm/meson: add support for VPU found in AXG SoCs
The Amlogic AXG SoC family has a downgraded VPU with the following
changes :
- Only a single OSD plane, no overlay video plane
- The primary plane doesn't support HW scaling
- The pixels are read directly from DDR without any Canvas module
- Doesn't support HDMI or CVBS
- Ouputs only with ENCL encoder to a DPI-to-DSI Synopsys DW-MIPI-DSI transceiver
Signed-off-by: Neil Armstrong
---
drivers/gpu/drm/meson/meson_crtc.c | 8 +-
drivers/gpu/drm/meson/meson_drv.c | 115
drivers/gpu/drm/meson/meson_drv.h | 10 ++-
drivers/gpu/drm/meson/meson_plane.c | 74 +--
drivers/gpu/drm/meson/meson_registers.h | 1 +
drivers/gpu/drm/meson/meson_viu.c | 50 ++-
drivers/gpu/drm/meson/meson_vpp.c | 6 +-
7 files changed, 215 insertions(+), 49 deletions(-)
diff --git a/drivers/gpu/drm/meson/meson_crtc.c
b/drivers/gpu/drm/meson/meson_crtc.c
index 2854272dc2d9..430599caa5a0 100644
--- a/drivers/gpu/drm/meson/meson_crtc.c
+++ b/drivers/gpu/drm/meson/meson_crtc.c
@@ -366,7 +366,13 @@ void meson_crtc_irq(struct meson_drm *priv)
writel_relaxed(priv->viu.osd_sc_v_ctrl0,
priv->io_base + _REG(VPP_OSD_VSC_CTRL0));
- if (!priv->viu.osd1_afbcd)
+ /* AXG doesn't use CANVAS since it support a single plane */
+ if (meson_vpu_is_compatible(priv, VPU_COMPATIBLE_AXG)) {
+ writel_relaxed(priv->viu.osd1_addr,
+ priv->io_base + _REG(VIU_OSD1_BLK1_CFG_W4));
+ writel_relaxed(priv->viu.osd1_blk2_cfg4,
+ priv->io_base + _REG(VIU_OSD1_BLK2_CFG_W4));
+ } else if (!priv->viu.osd1_afbcd)
meson_canvas_config(priv->canvas, priv->canvas_id_osd1,
priv->viu.osd1_addr,
priv->viu.osd1_stride,
diff --git a/drivers/gpu/drm/meson/meson_drv.c
b/drivers/gpu/drm/meson/meson_drv.c
index 8b9c8dd788c4..92346653223f 100644
--- a/drivers/gpu/drm/meson/meson_drv.c
+++ b/drivers/gpu/drm/meson/meson_drv.c
@@ -223,6 +223,7 @@ static int meson_drv_bind_master(struct device *dev, bool
has_components)
drm->dev_private = priv;
priv->drm = drm;
priv->dev = dev;
+ priv->data = match;
priv->compat = match->compat;
priv->afbcd.ops = match->afbcd_ops;
@@ -255,32 +256,34 @@ static int meson_drv_bind_master(struct device *dev, bool
has_components)
goto free_drm;
}
- priv->canvas = meson_canvas_get(dev);
- if (IS_ERR(priv->canvas)) {
- ret = PTR_ERR(priv->canvas);
- goto free_drm;
- }
+ if (priv->data->requires_canvas) {
+ priv->canvas = meson_canvas_get(dev);
+ if (IS_ERR(priv->canvas)) {
+ ret = PTR_ERR(priv->canvas);
+ goto free_drm;
+ }
- ret = meson_canvas_alloc(priv->canvas, &priv->canvas_id_osd1);
- if (ret)
- goto free_drm;
- ret = meson_canvas_alloc(priv->canvas, &priv->canvas_id_vd1_0);
- if (ret) {
- meson_canvas_free(priv->canvas, priv->canvas_id_osd1);
- goto free_drm;
- }
- ret = meson_canvas_alloc(priv->canvas, &priv->canvas_id_vd1_1);
- if (ret) {
- meson_canvas_free(priv->canvas, priv->canvas_id_osd1);
- meson_canvas_free(priv->canvas, priv->canvas_id_vd1_0);
- goto free_drm;
- }
- ret = meson_canvas_alloc(priv->canvas, &priv->canvas_id_vd1_2);
- if (ret) {
- meson_canvas_free(priv->canvas, priv->canvas_id_osd1);
- meson_canvas_free(priv->canvas, priv->canvas_id_vd1_0);
- meson_canvas_free(priv->canvas, priv->canvas_id_vd1_1);
- goto free_drm;
+ ret = meson_canvas_alloc(priv->canvas, &priv->canvas_id_osd1);
+ if (ret)
+ goto free_drm;
+ ret = meson_canvas_alloc(priv->canvas, &priv->canvas_id_vd1_0);
+ if (ret) {
+ meson_canvas_free(priv->canvas, priv->canvas_id_osd1);
+ goto free_drm;
+ }
+ ret = meson_canvas_alloc(priv->canvas, &priv->canvas_id_vd1_1);
+ if (ret) {
+ meson_canvas_free(priv->canvas, priv->canvas_id_osd1);
+ meson_canvas_free(priv->canvas, priv->canvas_id_vd1_0);
+ goto free_drm;
+ }
+ ret = meson_canvas_alloc(priv->canvas, &priv->canvas_id_vd1_2);
+ if (ret) {
+ meson_canvas_free(priv->canvas, priv->canvas_id_osd1);
+ meson_canvas_free(priv->canvas, priv->canvas_id_vd1_0);
+ meson_canvas_free(priv->canvas, pri
[PATCH 4/6] drm/meson: venc: add ENCL encoder setup for MIPI-DSI output
This adds supports for the ENCL encoder connected to a MIPI-DSI transceiver on
the
Amlogic AXG SoCs.
Signed-off-by: Neil Armstrong
---
drivers/gpu/drm/meson/meson_venc.c | 230 -
drivers/gpu/drm/meson/meson_venc.h | 6 +
drivers/gpu/drm/meson/meson_vpp.h | 2 +
3 files changed, 236 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/meson/meson_venc.c
b/drivers/gpu/drm/meson/meson_venc.c
index f93c725b6f02..3090418deffb 100644
--- a/drivers/gpu/drm/meson/meson_venc.c
+++ b/drivers/gpu/drm/meson/meson_venc.c
@@ -6,6 +6,7 @@
*/
#include
+#include
#include
@@ -1557,6 +1558,224 @@ void meson_venc_hdmi_mode_set(struct meson_drm *priv,
int vic,
}
EXPORT_SYMBOL_GPL(meson_venc_hdmi_mode_set);
+static unsigned short meson_encl_gamma_table[256] = {
+ 0, 4, 8, 12, 16, 20, 24, 28, 32, 36, 40, 44, 48, 52, 56, 60,
+ 64, 68, 72, 76, 80, 84, 88, 92, 96, 100, 104, 108, 112, 116, 120, 124,
+ 128, 132, 136, 140, 144, 148, 152, 156, 160, 164, 168, 172, 176, 180,
184, 188,
+ 192, 196, 200, 204, 208, 212, 216, 220, 224, 228, 232, 236, 240, 244,
248, 252,
+ 256, 260, 264, 268, 272, 276, 280, 284, 288, 292, 296, 300, 304, 308,
312, 316,
+ 320, 324, 328, 332, 336, 340, 344, 348, 352, 356, 360, 364, 368, 372,
376, 380,
+ 384, 388, 392, 396, 400, 404, 408, 412, 416, 420, 424, 428, 432, 436,
440, 444,
+ 448, 452, 456, 460, 464, 468, 472, 476, 480, 484, 488, 492, 496, 500,
504, 508,
+ 512, 516, 520, 524, 528, 532, 536, 540, 544, 548, 552, 556, 560, 564,
568, 572,
+ 576, 580, 584, 588, 592, 596, 600, 604, 608, 612, 616, 620, 624, 628,
632, 636,
+ 640, 644, 648, 652, 656, 660, 664, 668, 672, 676, 680, 684, 688, 692,
696, 700,
+ 704, 708, 712, 716, 720, 724, 728, 732, 736, 740, 744, 748, 752, 756,
760, 764,
+ 768, 772, 776, 780, 784, 788, 792, 796, 800, 804, 808, 812, 816, 820,
824, 828,
+ 832, 836, 840, 844, 848, 852, 856, 860, 864, 868, 872, 876, 880, 884,
888, 892,
+ 896, 900, 904, 908, 912, 916, 920, 924, 928, 932, 936, 940, 944, 948,
952, 956,
+ 960, 964, 968, 972, 976, 980, 984, 988, 992, 996, 1000, 1004, 1008,
1012, 1016, 1020,
+};
+
+#define GAMMA_VCOM_POL7 /* RW */
+#define GAMMA_RVS_OUT 6 /* RW */
+#define ADR_RDY 5 /* Read Only */
+#define WR_RDY4 /* Read Only */
+#define RD_RDY3 /* Read Only */
+#define GAMMA_TR 2 /* RW */
+#define GAMMA_SET 1 /* RW */
+#define GAMMA_EN 0 /* RW */
+
+#define H_RD 12
+#define H_AUTO_INC11
+#define H_SEL_R 10
+#define H_SEL_G 9
+#define H_SEL_B 8
+#define HADR_MSB 7/* 7:0 */
+#define HADR 0/* 7:0 */
+
+#define GAMMA_RETRY 1000
+
+static void meson_encl_set_gamma_table(struct meson_drm *priv, u16 *data,
+ u32 rgb_mask)
+{
+ int i, ret;
+ u32 reg;
+
+ writel_bits_relaxed(BIT(GAMMA_EN), 0,
+ priv->io_base + _REG(L_GAMMA_CNTL_PORT));
+
+ ret = readl_relaxed_poll_timeout(priv->io_base +
+ _REG(L_GAMMA_CNTL_PORT),
+reg, reg & BIT(ADR_RDY), 10, 1);
+ if (ret)
+ pr_warn("%s: GAMMA ADR_RDY timeout\n", __func__);
+
+ writel_relaxed(BIT(H_AUTO_INC) |
+ BIT(rgb_mask) |
+ (0 << HADR),
+ priv->io_base + _REG(L_GAMMA_ADDR_PORT));
+
+ for (i = 0; i < 256; i++) {
+ ret = readl_relaxed_poll_timeout(priv->io_base +
+ _REG(L_GAMMA_CNTL_PORT),
+reg, reg & BIT(WR_RDY),
+10, 1);
+ if (ret)
+ pr_warn_once("%s: GAMMA WR_RDY timeout\n", __func__);
+
+ writel_relaxed(data[i],
+ priv->io_base + _REG(L_GAMMA_DATA_PORT));
+ }
+
+ ret = readl_relaxed_poll_timeout(priv->io_base +
+ _REG(L_GAMMA_CNTL_PORT),
+reg, reg & BIT(ADR_RDY), 10, 1);
+ if (ret)
+ pr_warn("%s: GAMMA ADR_RDY timeout\n", __func__);
+
+ writel_relaxed(BIT(H_AUTO_INC) |
+ BIT(rgb_mask) |
+ (0x23 << HADR),
+ priv->io_base + _REG(L_GAMMA_ADDR_PORT));
+}
+
+void meson_encl_load_gamma(struct meson_drm *priv)
+{
+ meson_encl_set_gamma_table(priv, meson_encl_gamma_table, H_SEL_R);
+ meson_encl_set_gamma_table(priv, meson_encl_gamma_table, H_SEL_G);
+ meson_encl_set_gamma_table(priv, meson_encl_gamma_table, H_SEL_B);
+
+ writel_bits_relaxed(BIT(GAMMA_EN), BIT(GAMMA_EN),
+
[PATCH 2/6] dt-bindings: display: add Amlogic MIPI DSI Host Controller bindings
The Amlogic AXg SoCs embeds a Synopsys DW-MIPI-DSI transceiver (ver 1.21a),
with a custom
glue managing the IP resets, clock and data input similar to the DW-HDMI Glue
on other
Amlogic SoCs.
Signed-off-by: Neil Armstrong
---
.../display/amlogic,meson-dw-mipi-dsi.yaml| 115 ++
1 file changed, 115 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/amlogic,meson-dw-mipi-dsi.yaml
diff --git
a/Documentation/devicetree/bindings/display/amlogic,meson-dw-mipi-dsi.yaml
b/Documentation/devicetree/bindings/display/amlogic,meson-dw-mipi-dsi.yaml
new file mode 100644
index ..6177f45ea1a6
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/amlogic,meson-dw-mipi-dsi.yaml
@@ -0,0 +1,115 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+# Copyright 2020 BayLibre, SAS
+%YAML 1.2
+---
+$id: "http://devicetree.org/schemas/display/amlogic,meson-dw-mipi-dsi.yaml#";
+$schema: "http://devicetree.org/meta-schemas/core.yaml#";
+
+title: Amlogic specific extensions to the Synopsys Designware MIPI DSI Host
Controller
+
+maintainers:
+ - Neil Armstrong
+
+description: |
+ The Amlogic Meson Synopsys Designware Integration is composed of
+ - A Synopsys DesignWare MIPI DSI Host Controller IP
+ - A TOP control block controlling the Clocks & Resets of the IP
+
+allOf:
+ - $ref: dsi-controller.yaml#
+
+properties:
+ compatible:
+enum:
+ - amlogic,meson-axg-dw-mipi-dsi
+
+ reg:
+maxItems: 1
+
+ clocks:
+minItems: 2
+
+ clock-names:
+minItems: 2
+items:
+ - const: pclk
+ - const: px_clk
+ - const: meas_clk
+
+ resets:
+minItems: 1
+
+ reset-names:
+items:
+ - const: top
+
+ phys:
+minItems: 1
+
+ phy-names:
+items:
+ - const: dphy
+
+ ports:
+type: object
+
+properties:
+ port@0:
+type: object
+description: Input node to receive pixel data.
+ port@1:
+type: object
+description: DSI output node to panel.
+
+required:
+ - port@0
+ - port@1
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - resets
+ - reset-names
+ - phys
+ - phy-names
+ - ports
+
+additionalProperties: false
+
+examples:
+ - |
+dsi@7000 {
+ compatible = "amlogic,meson-axg-dw-mipi-dsi";
+ reg = <0x6000 0x400>;
+ resets = <&reset_top>;
+ reset-names = "top";
+ clocks = <&clk_pclk>, <&clk_px>;
+ clock-names = "pclk", "px_clk";
+ phys = <&mipi_dphy>;
+ phy-names = "dphy";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ /* VPU VENC Input */
+ mipi_dsi_venc_port: port@0 {
+ reg = <0>;
+
+ mipi_dsi_in: endpoint {
+ remote-endpoint = <&dpi_out>;
+ };
+ };
+
+ /* DSI Output */
+ mipi_dsi_panel_port: port@1 {
+ reg = <1>;
+
+ mipi_out_panel: endpoint {
+ remote-endpoint = <&mipi_in_panel>;
+ };
+ };
+ };
+};
--
2.22.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/6] drm/meson: add support for AXG & MIPI-DSI
The Amlogic AXG SoC family has a downgraded VPU with the following changes : - Only a single OSD plane, no overlay video plane - The primary plane doesn't support HW scaling - The pixels are read directly from DDR without any Canvas module - Doesn't support HDMI or CVBS - Ouputs only with ENCL encoder to a DPI-to-DSI Synopsys DW-MIPI-DSI transceiver The Amlogic AXg SoCs embeds a Synopsys DW-MIPI-DSI transceiver (ver 1.21a), with a custom glue managing the IP resets, clock and data input similar to the DW-HDMI Glue on other Amlogic SoCs. This adds support for the Glue managing the transceiver, mimicing the init flow provided by Amlogic to setup the ENCl encoder, the glue, the transceiver, the digital D-PHY and the Analog PHY in the proper way. The DW-MIPI-DSI transceiver + D-PHY are directly clocked by the VCLK2 clock, which pixel clock is derived and feeds the ENCL encoder and the VIU pixel reader. An optional "MEAS" clock can be enabled to measure the delay between each vsync feeding the DW-MIPI-DSI transceiver. Neil Armstrong (6): dt-bindings: display: amlogic,meson-vpu: add bindings for VPU found in AXG SoCs dt-bindings: display: add Amlogic MIPI DSI Host Controller bindings drm/meson: add support for VPU found in AXG SoCs drm/meson: venc: add ENCL encoder setup for MIPI-DSI output drm/meson: remove useless recursive components matching drm/meson: add support for MIPI-DSI transceiver .../display/amlogic,meson-dw-mipi-dsi.yaml| 115 .../bindings/display/amlogic,meson-vpu.yaml | 36 +- drivers/gpu/drm/meson/Kconfig | 7 + drivers/gpu/drm/meson/Makefile| 1 + drivers/gpu/drm/meson/meson_crtc.c| 8 +- drivers/gpu/drm/meson/meson_drv.c | 163 ++--- drivers/gpu/drm/meson/meson_drv.h | 10 +- drivers/gpu/drm/meson/meson_dw_mipi_dsi.c | 562 ++ drivers/gpu/drm/meson/meson_plane.c | 74 ++- drivers/gpu/drm/meson/meson_registers.h | 1 + drivers/gpu/drm/meson/meson_venc.c| 230 ++- drivers/gpu/drm/meson/meson_venc.h| 6 + drivers/gpu/drm/meson/meson_viu.c | 50 +- drivers/gpu/drm/meson/meson_vpp.c | 6 +- drivers/gpu/drm/meson/meson_vpp.h | 2 + 15 files changed, 1176 insertions(+), 95 deletions(-) create mode 100644 Documentation/devicetree/bindings/display/amlogic,meson-dw-mipi-dsi.yaml create mode 100644 drivers/gpu/drm/meson/meson_dw_mipi_dsi.c -- 2.22.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 5/6] drm/meson: remove useless recursive components matching
The initial design was recursive to cover all port/endpoints, but only the
first layer
of endpoints should be covered by the components list.
This also breaks the MIPI-DSI init/bridge attach sequence, thus only parse the
first endpoints instead of recursing.
Signed-off-by: Neil Armstrong
---
drivers/gpu/drm/meson/meson_drv.c | 48 +--
1 file changed, 7 insertions(+), 41 deletions(-)
diff --git a/drivers/gpu/drm/meson/meson_drv.c
b/drivers/gpu/drm/meson/meson_drv.c
index 92346653223f..1a4cf910c6a0 100644
--- a/drivers/gpu/drm/meson/meson_drv.c
+++ b/drivers/gpu/drm/meson/meson_drv.c
@@ -449,46 +449,6 @@ static int compare_of(struct device *dev, void *data)
return dev->of_node == data;
}
-/* Possible connectors nodes to ignore */
-static const struct of_device_id connectors_match[] = {
- { .compatible = "composite-video-connector" },
- { .compatible = "svideo-connector" },
- { .compatible = "hdmi-connector" },
- { .compatible = "dvi-connector" },
- {}
-};
-
-static int meson_probe_remote(struct platform_device *pdev,
- struct component_match **match,
- struct device_node *parent,
- struct device_node *remote)
-{
- struct device_node *ep, *remote_node;
- int count = 1;
-
- /* If node is a connector, return and do not add to match table */
- if (of_match_node(connectors_match, remote))
- return 1;
-
- component_match_add(&pdev->dev, match, compare_of, remote);
-
- for_each_endpoint_of_node(remote, ep) {
- remote_node = of_graph_get_remote_port_parent(ep);
- if (!remote_node ||
- remote_node == parent || /* Ignore parent endpoint */
- !of_device_is_available(remote_node)) {
- of_node_put(remote_node);
- continue;
- }
-
- count += meson_probe_remote(pdev, match, remote, remote_node);
-
- of_node_put(remote_node);
- }
-
- return count;
-}
-
static int meson_drv_probe(struct platform_device *pdev)
{
struct component_match *match = NULL;
@@ -503,8 +463,14 @@ static int meson_drv_probe(struct platform_device *pdev)
continue;
}
- count += meson_probe_remote(pdev, &match, np, remote);
+ DRM_DEBUG_DRIVER("parent %pOF remote %pOF\n", np, remote);
+
+ DRM_DEBUG_DRIVER("match add %pOF parent %s\n", remote,
dev_name(&pdev->dev));
+ component_match_add(&pdev->dev, &match, compare_of, remote);
+
of_node_put(remote);
+
+ ++count;
}
if (count && !match)
--
2.22.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/xlnx: Use devm_drm_dev_alloc
Gets rid of drmm_add_final_kfree, which I want to unexport so that it
stops confusion people about this transitional state of rolling drm
managed memory out.
This also fixes the missing drm_dev_put in the error path of the probe
code.
v2: Drop the misplaced drm_dev_put from zynqmp_dpsub_drm_init (all
other paths leaked on error, this should have been in
zynqmp_dpsub_probe), now that subsumed by the auto-cleanup of
devm_drm_dev_alloc.
Signed-off-by: Daniel Vetter
Cc: Hyun Kwon
Cc: Laurent Pinchart
Cc: Michal Simek
Cc: linux-arm-ker...@lists.infradead.org
---
drivers/gpu/drm/xlnx/zynqmp_dpsub.c | 27 ++-
1 file changed, 6 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/xlnx/zynqmp_dpsub.c
b/drivers/gpu/drm/xlnx/zynqmp_dpsub.c
index 26328c76305b..8e69303aad3f 100644
--- a/drivers/gpu/drm/xlnx/zynqmp_dpsub.c
+++ b/drivers/gpu/drm/xlnx/zynqmp_dpsub.c
@@ -111,7 +111,7 @@ static int zynqmp_dpsub_drm_init(struct zynqmp_dpsub *dpsub)
/* Initialize mode config, vblank and the KMS poll helper. */
ret = drmm_mode_config_init(drm);
if (ret < 0)
- goto err_dev_put;
+ return ret;
drm->mode_config.funcs = &zynqmp_dpsub_mode_config_funcs;
drm->mode_config.min_width = 0;
@@ -121,7 +121,7 @@ static int zynqmp_dpsub_drm_init(struct zynqmp_dpsub *dpsub)
ret = drm_vblank_init(drm, 1);
if (ret)
- goto err_dev_put;
+ return ret;
drm->irq_enabled = 1;
@@ -154,8 +154,6 @@ static int zynqmp_dpsub_drm_init(struct zynqmp_dpsub *dpsub)
err_poll_fini:
drm_kms_helper_poll_fini(drm);
-err_dev_put:
- drm_dev_put(drm);
return ret;
}
@@ -208,27 +206,16 @@ static int zynqmp_dpsub_probe(struct platform_device
*pdev)
int ret;
/* Allocate private data. */
- dpsub = kzalloc(sizeof(*dpsub), GFP_KERNEL);
- if (!dpsub)
- return -ENOMEM;
+ dpsub = devm_drm_dev_alloc(&pdev->dev, &zynqmp_dpsub_drm_driver,
+ struct zynqmp_dpsub, drm);
+ if (IS_ERR(dpsub))
+ return PTR_ERR(dpsub);
dpsub->dev = &pdev->dev;
platform_set_drvdata(pdev, dpsub);
dma_set_mask(dpsub->dev, DMA_BIT_MASK(ZYNQMP_DISP_MAX_DMA_BIT));
- /*
-* Initialize the DRM device early, as the DRM core mandates usage of
-* the managed memory helpers tied to the DRM device.
-*/
- ret = drm_dev_init(&dpsub->drm, &zynqmp_dpsub_drm_driver, &pdev->dev);
- if (ret < 0) {
- kfree(dpsub);
- return ret;
- }
-
- drmm_add_final_kfree(&dpsub->drm, dpsub);
-
/* Try the reserved memory. Proceed if there's none. */
of_reserved_mem_device_init(&pdev->dev);
@@ -286,8 +273,6 @@ static int zynqmp_dpsub_remove(struct platform_device *pdev)
clk_disable_unprepare(dpsub->apb_clk);
of_reserved_mem_device_release(&pdev->dev);
- drm_dev_put(drm);
-
return 0;
}
--
2.28.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 00/11] amd/display: Add GFX9+ modifier support.
On Fri, Sep 04, 2020 at 06:06:58PM +0200, Bas Nieuwenhuizen wrote: > This adds modifier support to radeonsi. > It has been tested on > > - VEGA10, RAVEN, NAVI14 > - weston, sway, X with xf86-video-amdgpu (i.e. legacy path still works) > > and includes some basic testing of the layout code. > > The main goal is to keep it somewhat simple and regression free, so > on the display side this series only exposes what the current GPU > can render to. While we could expose more I think that is more > suitable for follow-up work as the benefit would be minimal and > there are some more design discussion there to discuss that are > orthogonal from the initial implementation. > > Similarly this series only exposes 32-bpp displayable DCC in the cases > that radeonsi would use it and any extra capabilities here should be > future work. > > I believe these are by far the most complicated modifiers we've seen > up till now, mostly related to > > - GPU identification for cases where it matters wrt tiling. > - Every generation having tiling layout changes > - Compression settings. > > I believe the complexity is necessary as every layout should be different > and all layouts should be the best in some situation (though not all > combinations of GPU parameters will actually have an existing GPU). > > That said, on the render side the number of modifiers actually listed for > a given GPU is ~10, and in the current implementation that is the same > for the display side. (we could expose more actually differing layouts > on the display side for cross-GPU compatibility, but I consider that > out of scope for this initial work). > > This series can be found on > https://github.com/BNieuwenhuizen/linux/tree/modifiers > > An userspace implementation in radeonsi can be found on > https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6176 > > v2: > > Per suggestion from Daniel Vetter I added logic to get the tiling_flags at > addfb2 time and convert them into modifiers for GFX9+. Furthermore, the DCC > constant econding modifers only get exposed on RAVEN2 and newer. I read through the patches, lgtm. -Daniel > > Bas Nieuwenhuizen (11): > drm/amd/display: Do not silently accept DCC for multiplane formats. > drm/amd: Init modifier field of helper fb. > drm/amd/display: Honor the offset for plane 0. > drm/fourcc: Add AMD DRM modifiers. > drm/amd/display: Store tiling_flags in the framebuffer. > drm/amd/display: Convert tiling_flags to modifiers. > drm/amd/display: Refactor surface tiling setup. > drm/amd/display: Set DC options from modifiers. > drm/amd/display: Add formats for DCC with 2/3 planes. > drm/amd/display: Expose modifiers. > drm/amd/display: Clean up GFX9 tiling_flags path. > > drivers/gpu/drm/amd/amdgpu/amdgpu_display.c | 169 +++- > drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c| 2 +- > drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h | 3 + > .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 754 ++ > .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h | 2 - > include/uapi/drm/drm_fourcc.h | 115 +++ > 6 files changed, 880 insertions(+), 165 deletions(-) > > -- > 2.28.0 > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/doc: Document that modifiers are always required for fb
On Wed, Sep 02, 2020 at 02:59:49PM +, Simon Ser wrote: > On Wednesday, September 2, 2020 4:29 PM, Daniel Vetter > wrote: > > > On Wed, Sep 2, 2020 at 2:49 PM Simon Ser cont...@emersion.fr wrote: > > > > > On Wednesday, September 2, 2020 2:44 PM, Daniel Vetter > > > daniel.vet...@ffwll.ch wrote: > > > > > > > > I suppose something similar happens in user-space: gbm_bo_create > > > > > without modifiers needs to properly set the implicit modifier, ie. > > > > > gbm_bo_get_modifier needs to return the effective modifier. Is this > > > > > something already documented? > > > > > > > > I don't think that happens, but it has come up in discussions. It's > > > > kinda different scenario though: getfb2 is for cross-compositor stuff, > > > > enabling smooth transitions at boot-up and when switching. So you have > > > > a legit reason for mixing modifier-aware userspace with > > > > non-modifier-aware userspace. And the modifier-aware userspace would > > > > like that everything works with modifiers consistently, including > > > > getfb2. But gbm is just within a single process, and that should > > > > either run all with modifiers, or not at all, since these worlds just > > > > dont mix well. Hence I'm not seeing much use for that, -modesetting > > > > being a confused mess nonwithstanding :-) > > > > > > Well… There's also the case where some legacy Wayland client talks to a > > > modifier-aware compositor. gbm_bo_import would be called without a > > > modifier, but the compositor expects gbm_bo_get_modifier to work. > > > Also, wlroots will call gbm_bo_create without a modifier to only let > > > the driver pick "safe" modifiers in case passing the full list of > > > modifiers results in a black screen. Later on wlroots will call > > > gbm_bo_get_modifier to figure out what modifier the driver picked. > > > > gbm_bo_import is a different thing from gbm_bo_create. Former I agree > > should figure out the right modifiers (and I think it does that, at > > least on intel mesa). For gbm_bo_create I'm not sure we should/need to > > require that. > > I guess the compositor will just forward the value returned by > gbm_bo_get_modifier in any case, so returning INVALID would be fine > too (to mean "implicit modifier"). > > In both the create and import cases, other metadata like pitches and > offsets should be correctly set I think? Well if you have a modifier format underneath, the non-modifiered offsets and pitches might be pure fiction. Also, they might not be sufficient, if the modifier adds more planes. So I'm not sure how we can let the "implicit modifier" go through once a stack is converted to support modifiers. In a way modifiers are one-way compatible only: implicit modifiers -> explicit modifiers should be well-defined, the other way just looses information and doesn't work. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/doc: Document that modifiers are always required for fb
On Monday, September 7, 2020 10:31 AM, Daniel Vetter wrote: > On Wed, Sep 02, 2020 at 02:59:49PM +, Simon Ser wrote: > > > On Wednesday, September 2, 2020 4:29 PM, Daniel Vetter > > daniel.vet...@ffwll.ch wrote: > > > > > On Wed, Sep 2, 2020 at 2:49 PM Simon Ser cont...@emersion.fr wrote: > > > > > > > On Wednesday, September 2, 2020 2:44 PM, Daniel Vetter > > > > daniel.vet...@ffwll.ch wrote: > > > > > > > > > > I suppose something similar happens in user-space: gbm_bo_create > > > > > > without modifiers needs to properly set the implicit modifier, ie. > > > > > > gbm_bo_get_modifier needs to return the effective modifier. Is this > > > > > > something already documented? > > > > > > > > > > I don't think that happens, but it has come up in discussions. It's > > > > > kinda different scenario though: getfb2 is for cross-compositor stuff, > > > > > enabling smooth transitions at boot-up and when switching. So you have > > > > > a legit reason for mixing modifier-aware userspace with > > > > > non-modifier-aware userspace. And the modifier-aware userspace would > > > > > like that everything works with modifiers consistently, including > > > > > getfb2. But gbm is just within a single process, and that should > > > > > either run all with modifiers, or not at all, since these worlds just > > > > > dont mix well. Hence I'm not seeing much use for that, -modesetting > > > > > being a confused mess nonwithstanding :-) > > > > > > > > Well… There's also the case where some legacy Wayland client talks to a > > > > modifier-aware compositor. gbm_bo_import would be called without a > > > > modifier, but the compositor expects gbm_bo_get_modifier to work. > > > > Also, wlroots will call gbm_bo_create without a modifier to only let > > > > the driver pick "safe" modifiers in case passing the full list of > > > > modifiers results in a black screen. Later on wlroots will call > > > > gbm_bo_get_modifier to figure out what modifier the driver picked. > > > > > > gbm_bo_import is a different thing from gbm_bo_create. Former I agree > > > should figure out the right modifiers (and I think it does that, at > > > least on intel mesa). For gbm_bo_create I'm not sure we should/need to > > > require that. > > > > I guess the compositor will just forward the value returned by > > gbm_bo_get_modifier in any case, so returning INVALID would be fine > > too (to mean "implicit modifier"). > > In both the create and import cases, other metadata like pitches and > > offsets should be correctly set I think? > > Well if you have a modifier format underneath, the non-modifiered offsets > and pitches might be pure fiction. Also, they might not be sufficient, if > the modifier adds more planes. In this case (gbm_bo_create without modifiers), we're discussing whether we require gbm_bo_get_modifier to return a valid modifier, or if INVALID is fine. > So I'm not sure how we can let the "implicit modifier" go through once a > stack is converted to support modifiers. In a way modifiers are one-way > compatible only: implicit modifiers -> explicit modifiers should be > well-defined, the other way just looses information and doesn't work. That makes sense to me, and still works fine with the two use-cases outlined above. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 0/2] drm: fix virtio-gpu + sev
On Mon, Sep 07, 2020 at 08:33:41AM +0200, Gerd Hoffmann wrote: > virtio-gpu must make sure scatter list segments are not too big. > > Gerd Hoffmann (2): > drm: allow limiting the scatter list size. > drm/virtio: set max_segment So this all feels a bit irky and mid-layer, and why can't the various helpers not just use dma_max_mapping_size(drm_device->dev) directly. And then I read that dma api use in virtio subsystem is a huge mess of hacks, and that it doesn't set up these quirks through the dma api abstraction but throught it's own abstraction on top. So we don't really have any other option I think. I think would be good to add a TODO item to the virtio_max_dma_size call like: TODO: once virtio uses the dma api correctly, remove the explicit max_segment handling na duse dma_max_mapping_size directly everywhere. Or maybe also put that into the @max_segment kerneldoc in the drm_device struct. With that: Reviewed-by: Daniel Vetter on the series. -Daniel > > include/drm/drm_device.h| 8 > include/drm/drm_prime.h | 3 ++- > drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c | 3 ++- > drivers/gpu/drm/drm_gem_shmem_helper.c | 3 ++- > drivers/gpu/drm/drm_prime.c | 10 +++--- > drivers/gpu/drm/etnaviv/etnaviv_gem.c | 3 ++- > drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c | 3 ++- > drivers/gpu/drm/msm/msm_gem.c | 3 ++- > drivers/gpu/drm/msm/msm_gem_prime.c | 3 ++- > drivers/gpu/drm/nouveau/nouveau_prime.c | 3 ++- > drivers/gpu/drm/radeon/radeon_prime.c | 3 ++- > drivers/gpu/drm/rockchip/rockchip_drm_gem.c | 6 -- > drivers/gpu/drm/tegra/gem.c | 3 ++- > drivers/gpu/drm/vgem/vgem_drv.c | 3 ++- > drivers/gpu/drm/virtio/virtgpu_kms.c| 1 + > drivers/gpu/drm/xen/xen_drm_front_gem.c | 3 ++- > 16 files changed, 44 insertions(+), 17 deletions(-) > > -- > 2.27.0 > > > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/doc: Document that modifiers are always required for fb
On Mon, Sep 07, 2020 at 08:37:31AM +, Simon Ser wrote: > On Monday, September 7, 2020 10:31 AM, Daniel Vetter wrote: > > > On Wed, Sep 02, 2020 at 02:59:49PM +, Simon Ser wrote: > > > > > On Wednesday, September 2, 2020 4:29 PM, Daniel Vetter > > > daniel.vet...@ffwll.ch wrote: > > > > > > > On Wed, Sep 2, 2020 at 2:49 PM Simon Ser cont...@emersion.fr wrote: > > > > > > > > > On Wednesday, September 2, 2020 2:44 PM, Daniel Vetter > > > > > daniel.vet...@ffwll.ch wrote: > > > > > > > > > > > > I suppose something similar happens in user-space: gbm_bo_create > > > > > > > without modifiers needs to properly set the implicit modifier, ie. > > > > > > > gbm_bo_get_modifier needs to return the effective modifier. Is > > > > > > > this > > > > > > > something already documented? > > > > > > > > > > > > I don't think that happens, but it has come up in discussions. It's > > > > > > kinda different scenario though: getfb2 is for cross-compositor > > > > > > stuff, > > > > > > enabling smooth transitions at boot-up and when switching. So you > > > > > > have > > > > > > a legit reason for mixing modifier-aware userspace with > > > > > > non-modifier-aware userspace. And the modifier-aware userspace would > > > > > > like that everything works with modifiers consistently, including > > > > > > getfb2. But gbm is just within a single process, and that should > > > > > > either run all with modifiers, or not at all, since these worlds > > > > > > just > > > > > > dont mix well. Hence I'm not seeing much use for that, -modesetting > > > > > > being a confused mess nonwithstanding :-) > > > > > > > > > > Well… There's also the case where some legacy Wayland client talks to > > > > > a > > > > > modifier-aware compositor. gbm_bo_import would be called without a > > > > > modifier, but the compositor expects gbm_bo_get_modifier to work. > > > > > Also, wlroots will call gbm_bo_create without a modifier to only let > > > > > the driver pick "safe" modifiers in case passing the full list of > > > > > modifiers results in a black screen. Later on wlroots will call > > > > > gbm_bo_get_modifier to figure out what modifier the driver picked. > > > > > > > > gbm_bo_import is a different thing from gbm_bo_create. Former I agree > > > > should figure out the right modifiers (and I think it does that, at > > > > least on intel mesa). For gbm_bo_create I'm not sure we should/need to > > > > require that. > > > > > > I guess the compositor will just forward the value returned by > > > gbm_bo_get_modifier in any case, so returning INVALID would be fine > > > too (to mean "implicit modifier"). > > > In both the create and import cases, other metadata like pitches and > > > offsets should be correctly set I think? > > > > Well if you have a modifier format underneath, the non-modifiered offsets > > and pitches might be pure fiction. Also, they might not be sufficient, if > > the modifier adds more planes. > > In this case (gbm_bo_create without modifiers), we're discussing > whether we require gbm_bo_get_modifier to return a valid modifier, or > if INVALID is fine. Hm then I missed the use-case for a gbm_bo_create without modifiers, where afterwards userspace wants the modifiers. That sounds like a bug (and yes -modesetting is buggy that way). -Daniel > > So I'm not sure how we can let the "implicit modifier" go through once a > > stack is converted to support modifiers. In a way modifiers are one-way > > compatible only: implicit modifiers -> explicit modifiers should be > > well-defined, the other way just looses information and doesn't work. > > That makes sense to me, and still works fine with the two use-cases > outlined above. -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 6/6] drm/meson: add support for MIPI-DSI transceiver
On Mon, Sep 07, 2020 at 10:18:25AM +0200, Neil Armstrong wrote: > The Amlogic AXg SoCs embeds a Synopsys DW-MIPI-DSI transceiver (ver 1.21a), > with a custom > glue managing the IP resets, clock and data input similar to the DW-HDMI Glue > on other > Amlogic SoCs. > > This adds support for the Glue managing the transceiver, mimicing the init > flow provided > by Amlogic to setup the ENCl encoder, the glue, the transceiver, the digital > D-PHY and the > Analog PHY in the proper way. > > The DW-MIPI-DSI transceiver + D-PHY are directly clocked by the VCLK2 clock, > which pixel clock > is derived and feeds the ENCL encoder and the VIU pixel reader. > > An optional "MEAS" clock can be enabled to measure the delay between each > vsync feeding the > DW-MIPI-DSI transceiver. > > Signed-off-by: Neil Armstrong More dw-hdmi drivers which aren't bridges but components, and the thing is still midlayer-y as heck :-/ Can we try to fix this? There's a ton of this going on, and the more we add the old fashioned way the harder this gets to fix up for real. -Daniel > --- > drivers/gpu/drm/meson/Kconfig | 7 + > drivers/gpu/drm/meson/Makefile| 1 + > drivers/gpu/drm/meson/meson_dw_mipi_dsi.c | 562 ++ > 3 files changed, 570 insertions(+) > create mode 100644 drivers/gpu/drm/meson/meson_dw_mipi_dsi.c > > diff --git a/drivers/gpu/drm/meson/Kconfig b/drivers/gpu/drm/meson/Kconfig > index 9f9281dd49f8..385f6f23839b 100644 > --- a/drivers/gpu/drm/meson/Kconfig > +++ b/drivers/gpu/drm/meson/Kconfig > @@ -16,3 +16,10 @@ config DRM_MESON_DW_HDMI > default y if DRM_MESON > select DRM_DW_HDMI > imply DRM_DW_HDMI_I2S_AUDIO > + > +config DRM_MESON_DW_MIPI_DSI > + tristate "MIPI DSI Synopsys Controller support for Amlogic Meson > Display" > + depends on DRM_MESON > + default y if DRM_MESON > + select DRM_DW_MIPI_DSI > + select GENERIC_PHY_MIPI_DPHY > diff --git a/drivers/gpu/drm/meson/Makefile b/drivers/gpu/drm/meson/Makefile > index 28a519cdf66b..2cc870e91182 100644 > --- a/drivers/gpu/drm/meson/Makefile > +++ b/drivers/gpu/drm/meson/Makefile > @@ -5,3 +5,4 @@ meson-drm-y += meson_rdma.o meson_osd_afbcd.o > > obj-$(CONFIG_DRM_MESON) += meson-drm.o > obj-$(CONFIG_DRM_MESON_DW_HDMI) += meson_dw_hdmi.o > +obj-$(CONFIG_DRM_MESON_DW_MIPI_DSI) += meson_dw_mipi_dsi.o > diff --git a/drivers/gpu/drm/meson/meson_dw_mipi_dsi.c > b/drivers/gpu/drm/meson/meson_dw_mipi_dsi.c > new file mode 100644 > index ..bbe1294fce7c > --- /dev/null > +++ b/drivers/gpu/drm/meson/meson_dw_mipi_dsi.c > @@ -0,0 +1,562 @@ > +// SPDX-License-Identifier: GPL-2.0-or-later > +/* > + * Copyright (C) 2016 BayLibre, SAS > + * Author: Neil Armstrong > + * Copyright (C) 2015 Amlogic, Inc. All rights reserved. > + */ > + > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > + > +#include > + > +#include > +#include > + > +#include > +#include > +#include > +#include > + > +#include "meson_drv.h" > +#include "meson_dw_mipi_dsi.h" > +#include "meson_registers.h" > +#include "meson_venc.h" > + > +#define DRIVER_NAME "meson-dw-mipi-dsi" > +#define DRIVER_DESC "Amlogic Meson MIPI-DSI DRM driver" > + > +/* MIPI DSI/VENC Color Format Definitions */ > +#define MIPI_DSI_VENC_COLOR_30B 0x0 > +#define MIPI_DSI_VENC_COLOR_24B 0x1 > +#define MIPI_DSI_VENC_COLOR_18B 0x2 > +#define MIPI_DSI_VENC_COLOR_16B 0x3 > + > +#define COLOR_16BIT_CFG_1 0x0 > +#define COLOR_16BIT_CFG_2 0x1 > +#define COLOR_16BIT_CFG_3 0x2 > +#define COLOR_18BIT_CFG_1 0x3 > +#define COLOR_18BIT_CFG_2 0x4 > +#define COLOR_24BIT 0x5 > +#define COLOR_20BIT_LOOSE 0x6 > +#define COLOR_24_BIT_YCBCR0x7 > +#define COLOR_16BIT_YCBCR 0x8 > +#define COLOR_30BIT 0x9 > +#define COLOR_36BIT 0xa > +#define COLOR_12BIT 0xb > +#define COLOR_RGB_111 0xc > +#define COLOR_RGB_332 0xd > +#define COLOR_RGB_444 0xe > + > +/* MIPI DSI Relative REGISTERs Definitions */ > +/* For MIPI_DSI_TOP_CNTL */ > +#define BIT_DPI_COLOR_MODE20 > +#define BIT_IN_COLOR_MODE 16 > +#define BIT_CHROMA_SUBSAMPLE 14 > +#define BIT_COMP2_SEL 12 > +#define BIT_COMP1_SEL 10 > +#define BIT_COMP0_SEL 8 > +#define BIT_DE_POL 6 > +#define BIT_HSYNC_POL 5 > +#define BIT_VSYNC_POL 4 > +#define BIT_DPICOLORM 3 > +#define BIT_DPISHUTDN 2 > +#define BIT_EDPITE_INTR_PULSE 1 > +#define BIT_ERR_INTR_PULSE 0 > + > +/* HHI Registers */ > +#define HHI_VIID_CLK_DIV 0x128 /* 0x4a offset in data sheet */ > +#define VCLK2_DIV_MASK 0xff > +#define VCLK2_DIV_EN BIT(16) > +#define VCLK2_DIV_RESET BIT(17) > +#define CTS_ENCL_SEL_MASK(0xf << 12) > +#define CTS_ENCL_SEL_SHIF
Re: [PATCH 6/6] drm/meson: add support for MIPI-DSI transceiver
On Mon, Sep 07, 2020 at 10:43:51AM +0200, Daniel Vetter wrote: > On Mon, Sep 07, 2020 at 10:18:25AM +0200, Neil Armstrong wrote: > > The Amlogic AXg SoCs embeds a Synopsys DW-MIPI-DSI transceiver (ver 1.21a), > > with a custom > > glue managing the IP resets, clock and data input similar to the DW-HDMI > > Glue on other > > Amlogic SoCs. > > > > This adds support for the Glue managing the transceiver, mimicing the init > > flow provided > > by Amlogic to setup the ENCl encoder, the glue, the transceiver, the > > digital D-PHY and the > > Analog PHY in the proper way. > > > > The DW-MIPI-DSI transceiver + D-PHY are directly clocked by the VCLK2 > > clock, which pixel clock > > is derived and feeds the ENCL encoder and the VIU pixel reader. > > > > An optional "MEAS" clock can be enabled to measure the delay between each > > vsync feeding the > > DW-MIPI-DSI transceiver. > > > > Signed-off-by: Neil Armstrong > > More dw-hdmi drivers which aren't bridges but components, and the thing is > still midlayer-y as heck :-/ *dw-dsi, but really they both work the same way and should both be fixed ... > > Can we try to fix this? There's a ton of this going on, and the more we > add the old fashioned way the harder this gets to fix up for real. > -Daniel > > > --- > > drivers/gpu/drm/meson/Kconfig | 7 + > > drivers/gpu/drm/meson/Makefile| 1 + > > drivers/gpu/drm/meson/meson_dw_mipi_dsi.c | 562 ++ > > 3 files changed, 570 insertions(+) > > create mode 100644 drivers/gpu/drm/meson/meson_dw_mipi_dsi.c > > > > diff --git a/drivers/gpu/drm/meson/Kconfig b/drivers/gpu/drm/meson/Kconfig > > index 9f9281dd49f8..385f6f23839b 100644 > > --- a/drivers/gpu/drm/meson/Kconfig > > +++ b/drivers/gpu/drm/meson/Kconfig > > @@ -16,3 +16,10 @@ config DRM_MESON_DW_HDMI > > default y if DRM_MESON > > select DRM_DW_HDMI > > imply DRM_DW_HDMI_I2S_AUDIO > > + > > +config DRM_MESON_DW_MIPI_DSI > > + tristate "MIPI DSI Synopsys Controller support for Amlogic Meson > > Display" > > + depends on DRM_MESON > > + default y if DRM_MESON > > + select DRM_DW_MIPI_DSI > > + select GENERIC_PHY_MIPI_DPHY > > diff --git a/drivers/gpu/drm/meson/Makefile b/drivers/gpu/drm/meson/Makefile > > index 28a519cdf66b..2cc870e91182 100644 > > --- a/drivers/gpu/drm/meson/Makefile > > +++ b/drivers/gpu/drm/meson/Makefile > > @@ -5,3 +5,4 @@ meson-drm-y += meson_rdma.o meson_osd_afbcd.o > > > > obj-$(CONFIG_DRM_MESON) += meson-drm.o > > obj-$(CONFIG_DRM_MESON_DW_HDMI) += meson_dw_hdmi.o > > +obj-$(CONFIG_DRM_MESON_DW_MIPI_DSI) += meson_dw_mipi_dsi.o > > diff --git a/drivers/gpu/drm/meson/meson_dw_mipi_dsi.c > > b/drivers/gpu/drm/meson/meson_dw_mipi_dsi.c > > new file mode 100644 > > index ..bbe1294fce7c > > --- /dev/null > > +++ b/drivers/gpu/drm/meson/meson_dw_mipi_dsi.c > > @@ -0,0 +1,562 @@ > > +// SPDX-License-Identifier: GPL-2.0-or-later > > +/* > > + * Copyright (C) 2016 BayLibre, SAS > > + * Author: Neil Armstrong > > + * Copyright (C) 2015 Amlogic, Inc. All rights reserved. > > + */ > > + > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > + > > +#include > > + > > +#include > > +#include > > + > > +#include > > +#include > > +#include > > +#include > > + > > +#include "meson_drv.h" > > +#include "meson_dw_mipi_dsi.h" > > +#include "meson_registers.h" > > +#include "meson_venc.h" > > + > > +#define DRIVER_NAME "meson-dw-mipi-dsi" > > +#define DRIVER_DESC "Amlogic Meson MIPI-DSI DRM driver" > > + > > +/* MIPI DSI/VENC Color Format Definitions */ > > +#define MIPI_DSI_VENC_COLOR_30B 0x0 > > +#define MIPI_DSI_VENC_COLOR_24B 0x1 > > +#define MIPI_DSI_VENC_COLOR_18B 0x2 > > +#define MIPI_DSI_VENC_COLOR_16B 0x3 > > + > > +#define COLOR_16BIT_CFG_1 0x0 > > +#define COLOR_16BIT_CFG_2 0x1 > > +#define COLOR_16BIT_CFG_3 0x2 > > +#define COLOR_18BIT_CFG_1 0x3 > > +#define COLOR_18BIT_CFG_2 0x4 > > +#define COLOR_24BIT 0x5 > > +#define COLOR_20BIT_LOOSE 0x6 > > +#define COLOR_24_BIT_YCBCR0x7 > > +#define COLOR_16BIT_YCBCR 0x8 > > +#define COLOR_30BIT 0x9 > > +#define COLOR_36BIT 0xa > > +#define COLOR_12BIT 0xb > > +#define COLOR_RGB_111 0xc > > +#define COLOR_RGB_332 0xd > > +#define COLOR_RGB_444 0xe > > + > > +/* MIPI DSI Relative REGISTERs Definitions */ > > +/* For MIPI_DSI_TOP_CNTL */ > > +#define BIT_DPI_COLOR_MODE20 > > +#define BIT_IN_COLOR_MODE 16 > > +#define BIT_CHROMA_SUBSAMPLE 14 > > +#define BIT_COMP2_SEL 12 > > +#define BIT_COMP1_SEL 10 > > +#define BIT_COMP0_SEL 8 > > +#define BIT_DE_POL 6 > > +#define BIT_HSYNC_POL 5 > > +#define BIT_VSYNC_POL 4 > > +#define BIT_DPICOLORM 3 > > +#define BIT_DPISH
Re: [PATCH v2 04/11] drm/fourcc: Add AMD DRM modifiers.
Hi Bas, 2 small typos you may want to fix: On 04/09/2020 18:07, Bas Nieuwenhuizen wrote: > This adds modifiers for GFX9+ AMD GPUs. > > As the modifiers need a lot of parameters I split things out in > getters and setters. > - Advantage: simplifies the code a lot > - Disadvantage: Makes it harder to check that you're setting all > the required fields. > > The tiling modes seem to change every generatio, but the structure "generatio" -> "generation" > of what each tiling mode is good for stays really similar. As such > the core of the modifier is > - the tiling mode > - a version. Not explicitly a GPU generation, but splitting out >a new set of tiling equations. [...] > + * with DCC & DCC_RETILE: > + * - main surface in plane 0 > + * - displayable DCC surface in plane 1 (not RB-aligned & not pipe-aligned) > + * - pipe-aligned DCC surface in plane 2 (RB-aligned & pipe-aligned) > + * > + * For multi-plane formats the above surfaces get merged into one plane for > + * each for format plane, based on the required alignment only. "for each for format plane" => "for each format plane"? Pierre-Eric ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 00/11] amd/display: Add GFX9+ modifier support.
Den fre 4 sep. 2020 kl 18:07 skrev Bas Nieuwenhuizen < b...@basnieuwenhuizen.nl>: > This adds modifier support to radeonsi. > Wouldn't it be more correct to say that this adds modifier support to amdgpu (and enables it to work with radeonsi OpenGL) or something like that? //E > It has been tested on > > - VEGA10, RAVEN, NAVI14 > - weston, sway, X with xf86-video-amdgpu (i.e. legacy path still works) > > and includes some basic testing of the layout code. > > The main goal is to keep it somewhat simple and regression free, so > on the display side this series only exposes what the current GPU > can render to. While we could expose more I think that is more > suitable for follow-up work as the benefit would be minimal and > there are some more design discussion there to discuss that are > orthogonal from the initial implementation. > > Similarly this series only exposes 32-bpp displayable DCC in the cases > that radeonsi would use it and any extra capabilities here should be > future work. > > I believe these are by far the most complicated modifiers we've seen > up till now, mostly related to > > - GPU identification for cases where it matters wrt tiling. > - Every generation having tiling layout changes > - Compression settings. > > I believe the complexity is necessary as every layout should be different > and all layouts should be the best in some situation (though not all > combinations of GPU parameters will actually have an existing GPU). > > That said, on the render side the number of modifiers actually listed for > a given GPU is ~10, and in the current implementation that is the same > for the display side. (we could expose more actually differing layouts > on the display side for cross-GPU compatibility, but I consider that > out of scope for this initial work). > > This series can be found on > https://github.com/BNieuwenhuizen/linux/tree/modifiers > > An userspace implementation in radeonsi can be found on > https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6176 > > v2: > > Per suggestion from Daniel Vetter I added logic to get the tiling_flags at > addfb2 time and convert them into modifiers for GFX9+. Furthermore, the > DCC > constant econding modifers only get exposed on RAVEN2 and newer. > > Bas Nieuwenhuizen (11): > drm/amd/display: Do not silently accept DCC for multiplane formats. > drm/amd: Init modifier field of helper fb. > drm/amd/display: Honor the offset for plane 0. > drm/fourcc: Add AMD DRM modifiers. > drm/amd/display: Store tiling_flags in the framebuffer. > drm/amd/display: Convert tiling_flags to modifiers. > drm/amd/display: Refactor surface tiling setup. > drm/amd/display: Set DC options from modifiers. > drm/amd/display: Add formats for DCC with 2/3 planes. > drm/amd/display: Expose modifiers. > drm/amd/display: Clean up GFX9 tiling_flags path. > > drivers/gpu/drm/amd/amdgpu/amdgpu_display.c | 169 +++- > drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c| 2 +- > drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h | 3 + > .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 754 ++ > .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h | 2 - > include/uapi/drm/drm_fourcc.h | 115 +++ > 6 files changed, 880 insertions(+), 165 deletions(-) > > -- > 2.28.0 > > ___ > amd-gfx mailing list > amd-...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/amd-gfx > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 6/6] drm/meson: add support for MIPI-DSI transceiver
On 07/09/2020 10:44, Daniel Vetter wrote: > On Mon, Sep 07, 2020 at 10:43:51AM +0200, Daniel Vetter wrote: >> On Mon, Sep 07, 2020 at 10:18:25AM +0200, Neil Armstrong wrote: >>> The Amlogic AXg SoCs embeds a Synopsys DW-MIPI-DSI transceiver (ver 1.21a), >>> with a custom >>> glue managing the IP resets, clock and data input similar to the DW-HDMI >>> Glue on other >>> Amlogic SoCs. >>> >>> This adds support for the Glue managing the transceiver, mimicing the init >>> flow provided >>> by Amlogic to setup the ENCl encoder, the glue, the transceiver, the >>> digital D-PHY and the >>> Analog PHY in the proper way. >>> >>> The DW-MIPI-DSI transceiver + D-PHY are directly clocked by the VCLK2 >>> clock, which pixel clock >>> is derived and feeds the ENCL encoder and the VIU pixel reader. >>> >>> An optional "MEAS" clock can be enabled to measure the delay between each >>> vsync feeding the >>> DW-MIPI-DSI transceiver. >>> >>> Signed-off-by: Neil Armstrong >> >> More dw-hdmi drivers which aren't bridges but components, and the thing is >> still midlayer-y as heck :-/ > > *dw-dsi, but really they both work the same way and should both be fixed > ... They are bridges but since they have platform-dependent code due to theirs's generic IP nature, they need to be intanciated by components to sync with the platform code. Neil > >> >> Can we try to fix this? There's a ton of this going on, and the more we >> add the old fashioned way the harder this gets to fix up for real. >> -Daniel >> >>> --- >>> drivers/gpu/drm/meson/Kconfig | 7 + >>> drivers/gpu/drm/meson/Makefile| 1 + >>> drivers/gpu/drm/meson/meson_dw_mipi_dsi.c | 562 ++ >>> 3 files changed, 570 insertions(+) >>> create mode 100644 drivers/gpu/drm/meson/meson_dw_mipi_dsi.c >>> >>> diff --git a/drivers/gpu/drm/meson/Kconfig b/drivers/gpu/drm/meson/Kconfig >>> index 9f9281dd49f8..385f6f23839b 100644 >>> --- a/drivers/gpu/drm/meson/Kconfig >>> +++ b/drivers/gpu/drm/meson/Kconfig >>> @@ -16,3 +16,10 @@ config DRM_MESON_DW_HDMI >>> default y if DRM_MESON >>> select DRM_DW_HDMI >>> imply DRM_DW_HDMI_I2S_AUDIO >>> + >>> +config DRM_MESON_DW_MIPI_DSI >>> + tristate "MIPI DSI Synopsys Controller support for Amlogic Meson >>> Display" >>> + depends on DRM_MESON >>> + default y if DRM_MESON >>> + select DRM_DW_MIPI_DSI >>> + select GENERIC_PHY_MIPI_DPHY >>> diff --git a/drivers/gpu/drm/meson/Makefile b/drivers/gpu/drm/meson/Makefile >>> index 28a519cdf66b..2cc870e91182 100644 >>> --- a/drivers/gpu/drm/meson/Makefile >>> +++ b/drivers/gpu/drm/meson/Makefile >>> @@ -5,3 +5,4 @@ meson-drm-y += meson_rdma.o meson_osd_afbcd.o >>> >>> obj-$(CONFIG_DRM_MESON) += meson-drm.o >>> obj-$(CONFIG_DRM_MESON_DW_HDMI) += meson_dw_hdmi.o >>> +obj-$(CONFIG_DRM_MESON_DW_MIPI_DSI) += meson_dw_mipi_dsi.o >>> diff --git a/drivers/gpu/drm/meson/meson_dw_mipi_dsi.c >>> b/drivers/gpu/drm/meson/meson_dw_mipi_dsi.c >>> new file mode 100644 >>> index ..bbe1294fce7c >>> --- /dev/null >>> +++ b/drivers/gpu/drm/meson/meson_dw_mipi_dsi.c >>> @@ -0,0 +1,562 @@ >>> +// SPDX-License-Identifier: GPL-2.0-or-later >>> +/* >>> + * Copyright (C) 2016 BayLibre, SAS >>> + * Author: Neil Armstrong >>> + * Copyright (C) 2015 Amlogic, Inc. All rights reserved. >>> + */ >>> + >>> +#include >>> +#include >>> +#include >>> +#include >>> +#include >>> +#include >>> +#include >>> +#include >>> + >>> +#include >>> + >>> +#include >>> +#include >>> + >>> +#include >>> +#include >>> +#include >>> +#include >>> + >>> +#include "meson_drv.h" >>> +#include "meson_dw_mipi_dsi.h" >>> +#include "meson_registers.h" >>> +#include "meson_venc.h" >>> + >>> +#define DRIVER_NAME "meson-dw-mipi-dsi" >>> +#define DRIVER_DESC "Amlogic Meson MIPI-DSI DRM driver" >>> + >>> +/* MIPI DSI/VENC Color Format Definitions */ >>> +#define MIPI_DSI_VENC_COLOR_30B 0x0 >>> +#define MIPI_DSI_VENC_COLOR_24B 0x1 >>> +#define MIPI_DSI_VENC_COLOR_18B 0x2 >>> +#define MIPI_DSI_VENC_COLOR_16B 0x3 >>> + >>> +#define COLOR_16BIT_CFG_1 0x0 >>> +#define COLOR_16BIT_CFG_2 0x1 >>> +#define COLOR_16BIT_CFG_3 0x2 >>> +#define COLOR_18BIT_CFG_1 0x3 >>> +#define COLOR_18BIT_CFG_2 0x4 >>> +#define COLOR_24BIT 0x5 >>> +#define COLOR_20BIT_LOOSE 0x6 >>> +#define COLOR_24_BIT_YCBCR0x7 >>> +#define COLOR_16BIT_YCBCR 0x8 >>> +#define COLOR_30BIT 0x9 >>> +#define COLOR_36BIT 0xa >>> +#define COLOR_12BIT 0xb >>> +#define COLOR_RGB_111 0xc >>> +#define COLOR_RGB_332 0xd >>> +#define COLOR_RGB_444 0xe >>> + >>> +/* MIPI DSI Relative REGISTERs Definitions */ >>> +/* For MIPI_DSI_TOP_CNTL */ >>> +#define BIT_DPI_COLOR_MODE20 >>> +#define BIT_IN_COLOR_MODE 16 >>> +#define BIT_CHROMA_SUBSAMPLE 14 >>> +#define BIT_COMP2_SEL 12 >>> +#define BIT_COMP1_SEL 10
Re: [PATCH] drm/doc: Document that modifiers are always required for fb
On Mon, 7 Sep 2020 10:41:37 +0200 Daniel Vetter wrote: > On Mon, Sep 07, 2020 at 08:37:31AM +, Simon Ser wrote: > > On Monday, September 7, 2020 10:31 AM, Daniel Vetter > > wrote: > > > > > On Wed, Sep 02, 2020 at 02:59:49PM +, Simon Ser wrote: > > > > > > > On Wednesday, September 2, 2020 4:29 PM, Daniel Vetter > > > > daniel.vet...@ffwll.ch wrote: > > > > > > > > > On Wed, Sep 2, 2020 at 2:49 PM Simon Ser cont...@emersion.fr wrote: > > > > > > > > > > > On Wednesday, September 2, 2020 2:44 PM, Daniel Vetter > > > > > > daniel.vet...@ffwll.ch wrote: > > > > > > > > > > > > > > I suppose something similar happens in user-space: gbm_bo_create > > > > > > > > without modifiers needs to properly set the implicit modifier, > > > > > > > > ie. > > > > > > > > gbm_bo_get_modifier needs to return the effective modifier. Is > > > > > > > > this > > > > > > > > something already documented? > > > > > > > > > > > > > > I don't think that happens, but it has come up in discussions. > > > > > > > It's > > > > > > > kinda different scenario though: getfb2 is for cross-compositor > > > > > > > stuff, > > > > > > > enabling smooth transitions at boot-up and when switching. So you > > > > > > > have > > > > > > > a legit reason for mixing modifier-aware userspace with > > > > > > > non-modifier-aware userspace. And the modifier-aware userspace > > > > > > > would > > > > > > > like that everything works with modifiers consistently, including > > > > > > > getfb2. But gbm is just within a single process, and that should > > > > > > > either run all with modifiers, or not at all, since these worlds > > > > > > > just > > > > > > > dont mix well. Hence I'm not seeing much use for that, > > > > > > > -modesetting > > > > > > > being a confused mess nonwithstanding :-) > > > > > > > > > > > > Well… There's also the case where some legacy Wayland client talks > > > > > > to a > > > > > > modifier-aware compositor. gbm_bo_import would be called without a > > > > > > modifier, but the compositor expects gbm_bo_get_modifier to work. > > > > > > Also, wlroots will call gbm_bo_create without a modifier to only let > > > > > > the driver pick "safe" modifiers in case passing the full list of > > > > > > modifiers results in a black screen. Later on wlroots will call > > > > > > gbm_bo_get_modifier to figure out what modifier the driver picked. > > > > > > > > > > gbm_bo_import is a different thing from gbm_bo_create. Former I agree > > > > > should figure out the right modifiers (and I think it does that, at > > > > > least on intel mesa). For gbm_bo_create I'm not sure we should/need to > > > > > require that. > > > > > > > > I guess the compositor will just forward the value returned by > > > > gbm_bo_get_modifier in any case, so returning INVALID would be fine > > > > too (to mean "implicit modifier"). > > > > In both the create and import cases, other metadata like pitches and > > > > offsets should be correctly set I think? > > > > > > Well if you have a modifier format underneath, the non-modifiered offsets > > > and pitches might be pure fiction. Also, they might not be sufficient, if > > > the modifier adds more planes. > > > > In this case (gbm_bo_create without modifiers), we're discussing > > whether we require gbm_bo_get_modifier to return a valid modifier, or > > if INVALID is fine. > > Hm then I missed the use-case for a gbm_bo_create without modifiers, where > afterwards userspace wants the modifiers. That sounds like a bug (and yes > -modesetting is buggy that way). I'm guessing that use case might be related to https://gitlab.freedesktop.org/wayland/weston/-/issues/429 The weston issue is about gbm_surface_create/gbm_surface_create_with_modifiers, but that's not too different from gbm_bo_create/gbm_bo_create_with_modifiers? Weston happens to have this code: https://gitlab.freedesktop.org/wayland/weston/-/blob/9.0.0/libweston/backend-drm/drm-gbm.c#L209-230 and then it unconditionally calls gbm_bo_get_modifier(). However, DRM_FORMAT_MOD_INVALID is handled specially: https://gitlab.freedesktop.org/wayland/weston/-/blob/9.0.0/libweston/backend-drm/fb.c#L80-97 Thanks, pq pgp7pTwV31R0t.pgp Description: OpenPGP digital signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/bridge: dw-mipi-dsi: fix dw_mipi_dsi_debugfs_show/write warnings
This fixes the following warnings while building in W=1 :
dw-mipi-dsi.c:1002:5: warning: no previous prototype for
'dw_mipi_dsi_debugfs_write' [-Wmissing-prototypes]
dw-mipi-dsi.c:1027:5: warning: no previous prototype for
'dw_mipi_dsi_debugfs_show' [-Wmissing-prototypes]
Fixes: e2435d69204c ("drm/bridge: dw-mipi-dsi.c: Add VPG runtime config through
debugfs")
Reported-by: kernel test robot
Cc: Angelo Ribeiro
Cc: Maxime Ripard
Cc: Maarten Lankhorst
Cc: Thomas Zimmermann
Signed-off-by: Neil Armstrong
---
drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
index 0b3825a4fbdb..52f5c5a2ed64 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
@@ -999,7 +999,7 @@ static const struct drm_bridge_funcs
dw_mipi_dsi_bridge_funcs = {
#ifdef CONFIG_DEBUG_FS
-int dw_mipi_dsi_debugfs_write(void *data, u64 val)
+static int dw_mipi_dsi_debugfs_write(void *data, u64 val)
{
struct debugfs_entries *vpg = data;
struct dw_mipi_dsi *dsi;
@@ -1024,7 +1024,7 @@ int dw_mipi_dsi_debugfs_write(void *data, u64 val)
return 0;
}
-int dw_mipi_dsi_debugfs_show(void *data, u64 *val)
+static int dw_mipi_dsi_debugfs_show(void *data, u64 *val)
{
struct debugfs_entries *vpg = data;
--
2.22.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v1 0/2] video: fbdev: radeonfb: PCI PM framework upgrade and fix-ups.
On 2020-09-07 9:55 a.m., Daniel Vetter wrote:
On Thu, Aug 06, 2020 at 12:52:54PM +0530, Vaibhav Gupta wrote:
Linux Kernel Mentee: Remove Legacy Power Management.
The original goal of the patch series is to upgrade the power management
framework of radeonfb fbdev driver. This has been done by upgrading .suspend()
and .resume() callbacks.
The upgrade makes sure that the involvement of PCI Core does not change the
order of operations executed in a driver. Thus, does not change its behavior.
During this process, it was found that "#if defined(CONFIG_PM)" at line 1434 is
redundant. This was introduced in the commit
42ddb453a0cd ("radeon: Conditionally compile PM code").
I do wonder whether it wouldn't be better to just outright delete these,
we have the drm radeon driver for pretty much all the same hardware ...
In contrast to radeonfb, the radeon driver doesn't support
suspend-to-RAM on Apple PowerPC notebooks.
--
Earthling Michel Dänzer | https://redhat.com
Libre software enthusiast | Mesa and X developer
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/2] drm: panel: add support for TDO tl070wsh30 panel
Hi, Please ignore this serie, the vendors patch is missing and the panel driver still has the vrefresh... Will repost. Neil On 04/09/2020 18:15, Neil Armstrong wrote: > This adds support bindings and support for the TDO TL070WSH30 TFT-LCD panel > module shipped with the Amlogic S400 Development Kit. > The panel has a 1024×600 resolution and uses 24 bit RGB per pixel. > It provides a MIPI DSI interface to the host, a built-in LED backlight > and touch controller. > > Neil Armstrong (2): > dt-bindings: display: panel: add TDO tl070wsh30 DSI panel bindings > drm: panel: add TDO tl070wsh30 panel driver > > .../display/panel/tdo,tl070wsh30.yaml | 58 > drivers/gpu/drm/panel/Kconfig | 11 + > drivers/gpu/drm/panel/Makefile| 1 + > drivers/gpu/drm/panel/panel-tdo-tl070wsh30.c | 263 ++ > 4 files changed, 333 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/display/panel/tdo,tl070wsh30.yaml > create mode 100644 drivers/gpu/drm/panel/panel-tdo-tl070wsh30.c > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 204987] fault in amdgpu_dm_atomic_commit_tail on Vega64 with compton and redshift
https://bugzilla.kernel.org/show_bug.cgi?id=204987 Bhasker C V (bhas...@unixindia.com) changed: What|Removed |Added CC||bhas...@unixindia.com --- Comment #3 from Bhasker C V (bhas...@unixindia.com) --- I get this error after hibernation and resume. This does not happen during immediate resume but if left overnight and resume in the morning, I see the amdgpu_dm_atomic_commit_tail. I am failing to load kexec kernel when on AMD ryzen. Hence I have a shapshot of the error message. The system freezes and there is nothing that can be done other than to cold reboot. Attaching a photo of the crash -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 204987] fault in amdgpu_dm_atomic_commit_tail on Vega64 with compton and redshift
https://bugzilla.kernel.org/show_bug.cgi?id=204987 --- Comment #4 from Bhasker C V (bhas...@unixindia.com) --- Created attachment 292395 --> https://bugzilla.kernel.org/attachment.cgi?id=292395&action=edit Kernel crash AMD GPU at amdgpu_dm_atomic_commit_tail -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/2] drm: panel: add support for TDO tl070wsh30 panel
On Mon, Sep 07, 2020 at 12:33:41PM +0200, Neil Armstrong wrote: > Hi, > > Please ignore this serie, the vendors patch is missing and the panel driver > still has the vrefresh... > > Will repost. Please fix so DRM_DEV_* is replaced by dev_* logging. We no longer use the DRM_ based logging for panels. Drop drm_print.h from includes and fix build. I did not read the code just noticed this detail. Sam ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/2] drm: panel: add support for TDO tl070wsh30 panel
Hi Sam, On 07/09/2020 12:54, Sam Ravnborg wrote: > On Mon, Sep 07, 2020 at 12:33:41PM +0200, Neil Armstrong wrote: >> Hi, >> >> Please ignore this serie, the vendors patch is missing and the panel driver >> still has the vrefresh... >> >> Will repost. > > Please fix so DRM_DEV_* is replaced by dev_* logging. > We no longer use the DRM_ based logging for panels. > > Drop drm_print.h from includes and fix build. Done, thanks for noticing. Neil > > I did not read the code just noticed this detail. > > Sam > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH]] drm/dp check aux_dev before use in drm_dp_aux_dev_get_by_minor()
On Fri, Sep 04, 2020 at 12:21:26AM -0700, Zwane Mwaikambo wrote:
> I observed this when unplugging a DP monitor whilst a computer is asleep
> and then waking it up. This left DP chardev nodes still being present on
> the filesystem and accessing these device nodes caused an oops because
> drm_dp_aux_dev_get_by_minor() assumes a device exists if it is opened.
> This can also be reproduced by creating a device node with mknod(1) and
> issuing an open(2)
>
> [166164.933198] BUG: kernel NULL pointer dereference, address:
> 0018
> [166164.933202] #PF: supervisor read access in kernel mode
> [166164.933204] #PF: error_code(0x) - not-present page
> [166164.933205] PGD 0 P4D 0
> [166164.933208] Oops: [#1] PREEMPT SMP NOPTI
> [166164.933211] CPU: 4 PID: 99071 Comm: fwupd Tainted: GW
> 5.8.0-rc6+ #1
> [166164.933213] Hardware name: LENOVO 20RD002VUS/20RD002VUS, BIOS R16ET25W
> (1.11 ) 04/21/2020
> [166164.933232] RIP: 0010:drm_dp_aux_dev_get_by_minor+0x29/0x70
> [drm_kms_helper]
> [166164.933234] Code: 00 0f 1f 44 00 00 55 48 89 e5 41 54 41 89 fc 48 c7
> c7 60 01 a4 c0 e8 26 ab 30 d7 44 89 e6 48 c7 c7 80 01 a4 c0 e8 47 94 d6 d6
> <8b> 50 18 49 89 c4 48 8d 78 18 85 d2 74 33 8d 4a 01 89 d0 f0 0f b1
> [166164.933236] RSP: 0018:b7d7c41cbbf0 EFLAGS: 00010246
> [166164.933237] RAX: RBX: 8a90001fe900 RCX:
>
> [166164.933238] RDX: RSI: 0003 RDI:
> c0a40180
> [166164.933239] RBP: b7d7c41cbbf8 R08: R09:
> 8a93e157d6d0
> [166164.933240] R10: R11: c0a40188 R12:
> 0003
> [166164.933241] R13: 8a9402200e80 R14: 8a90001fe900 R15:
>
> [166164.933244] FS: 7f7fb041eb00() GS:8a941150()
> knlGS:
> [166164.933245] CS: 0010 DS: ES: CR0: 80050033
> [166164.933246] CR2: 0018 CR3: 352c2003 CR4:
> 003606e0
> [166164.933247] Call Trace:
> [166164.933264] auxdev_open+0x1b/0x40 [drm_kms_helper]
> [166164.933278] chrdev_open+0xa7/0x1c0
> [166164.933282] ? cdev_put.part.0+0x20/0x20
> [166164.933287] do_dentry_open+0x161/0x3c0
> [166164.933291] vfs_open+0x2d/0x30
> [166164.933297] path_openat+0xb27/0x10e0
> [166164.933306] ? atime_needs_update+0x73/0xd0
> [166164.933309] do_filp_open+0x91/0x100
> [166164.933313] ? __alloc_fd+0xb2/0x150
> [166164.933316] do_sys_openat2+0x210/0x2d0
> [166164.933318] do_sys_open+0x46/0x80
> [166164.933320] __x64_sys_openat+0x20/0x30
> [166164.933328] do_syscall_64+0x52/0xc0
> [166164.96] entry_SYSCALL_64_after_hwframe+0x44/0xa9
>
>
> (gdb) disassemble drm_dp_aux_dev_get_by_minor+0x29
> Dump of assembler code for function drm_dp_aux_dev_get_by_minor:
>0x00017b10 <+0>: callq 0x17b15
>0x00017b15 <+5>: push %rbp
>0x00017b16 <+6>: mov%rsp,%rbp
>0x00017b19 <+9>: push %r12
>0x00017b1b <+11>:mov%edi,%r12d
>0x00017b1e <+14>:mov$0x0,%rdi
>0x00017b25 <+21>:callq 0x17b2a
>
>0x00017b2a <+26>:mov%r12d,%esi
>0x00017b2d <+29>:mov$0x0,%rdi
>0x00017b34 <+36>:callq 0x17b39
>
>0x00017b39 <+41>:mov0x18(%rax),%edx <=
>0x00017b3c <+44>:mov%rax,%r12
>0x00017b3f <+47>:lea0x18(%rax),%rdi
>0x00017b43 <+51>:test %edx,%edx
>0x00017b45 <+53>:je 0x17b7a
>
>0x00017b47 <+55>:lea0x1(%rdx),%ecx
>0x00017b4a <+58>:mov%edx,%eax
>0x00017b4c <+60>:lock cmpxchg %ecx,(%rdi)
>0x00017b50 <+64>:jne0x17b76
>
>0x00017b52 <+66>:test %edx,%edx
>0x00017b54 <+68>:js 0x17b6d
>
>0x00017b56 <+70>:test %ecx,%ecx
>0x00017b58 <+72>:js 0x17b6d
>
>0x00017b5a <+74>:mov$0x0,%rdi
>0x00017b61 <+81>:callq 0x17b66
>
>0x00017b66 <+86>:mov%r12,%rax
>0x00017b69 <+89>:pop%r12
>0x00017b6b <+91>:pop%rbp
>0x00017b6c <+92>:retq
>0x00017b6d <+93>:xor%esi,%esi
>0x00017b6f <+95>:callq 0x17b74
>
>0x00017b74 <+100>: jmp0x17b5a
>
>0x00017b76 <+102>: mov%eax,%edx
>0x00017b78 <+104>: jmp0x17b43
>
>0x00017b7a <+106>: xor%r12d,%r12d
>0x00017b7d <+109>: jmp0x17b5a
>
> End of assembler dump.
>
> (gdb) list *drm_dp_aux_dev_get_by_minor+0x29
> 0x17b39 is in drm_dp_aux_dev_get_by_minor
> (drivers/gpu/drm/drm_dp_aux_dev.c:65).
> 60 static struct drm_dp_aux_dev *drm_dp_aux_dev_get_by_minor(unsigned
> index)
> 61 {
> 62 struct drm_dp_aux_dev *aux_dev = NULL;
> 63
[PATCH 0/3] drm: panel: add support for TDO tl070wsh30 panel
This adds support bindings and support for the TDO TL070WSH30 TFT-LCD panel module shipped with the Amlogic S400 Development Kit. The panel has a 1024×600 resolution and uses 24 bit RGB per pixel. It provides a MIPI DSI interface to the host, a built-in LED backlight and touch controller. Changes since v1 at [1]: - added missing vendor-prefixes patch - removed vrefresh - fixed warning on add_panel return - removed DRM logging [1] https://patchwork.freedesktop.org/series/81376/#rev1 Neil Armstrong (3): dt-bindings: vendor-prefixes: Add Shanghai Top Display Optolelectronics vendor prefix dt-bindings: display: panel: add TDO tl070wsh30 DSI panel bindings drm: panel: add TDO tl070wsh30 panel driver .../display/panel/tdo,tl070wsh30.yaml | 58 .../devicetree/bindings/vendor-prefixes.yaml | 2 + drivers/gpu/drm/panel/Kconfig | 11 + drivers/gpu/drm/panel/Makefile| 1 + drivers/gpu/drm/panel/panel-tdo-tl070wsh30.c | 256 ++ 5 files changed, 328 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/panel/tdo,tl070wsh30.yaml create mode 100644 drivers/gpu/drm/panel/panel-tdo-tl070wsh30.c -- 2.22.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 1/3] dt-bindings: vendor-prefixes: Add Shanghai Top Display Optolelectronics vendor prefix
Shanghai Top Display Optolelectronics Co., Ltd is a display manufacturer from Shanghai. Web site of the company: http://www.shtdo.com/ Signed-off-by: Neil Armstrong --- Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml index a1e4356cf522..4e9dfb352c68 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml @@ -1078,6 +1078,8 @@ patternProperties: description: TPK U.S.A. LLC "^tplink,.*": description: TP-LINK Technologies Co., Ltd. + "^tdo,.*": +description: Shangai Top Display Optoelectronics Co., Ltd "^tpo,.*": description: TPO "^tq,.*": -- 2.22.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 2/3] dt-bindings: display: panel: add TDO tl070wsh30 DSI panel bindings
This add the bindings for the 1024*600 tl070wsh30 DSI panel.
Signed-off-by: Neil Armstrong
---
.../display/panel/tdo,tl070wsh30.yaml | 58 +++
1 file changed, 58 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/panel/tdo,tl070wsh30.yaml
diff --git
a/Documentation/devicetree/bindings/display/panel/tdo,tl070wsh30.yaml
b/Documentation/devicetree/bindings/display/panel/tdo,tl070wsh30.yaml
new file mode 100644
index ..20f4fdedfcb0
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/tdo,tl070wsh30.yaml
@@ -0,0 +1,58 @@
+# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause)
+# Copyright 2020 BayLibre, SAS
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/panel/tdo,tl070wsh30.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: TDO TL070WSH30 DSI panel
+
+maintainers:
+ - Neil Armstrong
+
+allOf:
+ - $ref: panel-common.yaml#
+
+properties:
+
+ compatible:
+enum:
+ - tdo,tl070wsh30
+
+ reg:
+maxItems: 1
+description: DSI virtual channel
+
+ backlight: true
+ reset-gpios: true
+ port: true
+ power-supply: true
+
+additionalProperties: false
+
+required:
+ - compatible
+ - power-supply
+ - reset-gpios
+ - port
+ - reg
+
+examples:
+ - |
+dsi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ panel@0 {
+compatible = "tdo,tl070wsh30";
+reg = <0>;
+power-supply = <&vcc_lcd_reg>;
+backlight = <&panel_backlight>;
+reset-gpios = <&gpio_reset>;
+
+port {
+ panel: endpoint {
+remote-endpoint = <&mipi_dsi_out>;
+ };
+};
+ };
+};
--
2.22.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 3/3] drm: panel: add TDO tl070wsh30 panel driver
This adds support for the TDO TL070WSH30 TFT-LCD panel module.
The panel has a 1024×600 resolution and uses 24 bit RGB per pixel.
It provides a MIPI DSI interface to the host, a built-in LED backlight
and touch controller.
Signed-off-by: Neil Armstrong
---
drivers/gpu/drm/panel/Kconfig| 11 +
drivers/gpu/drm/panel/Makefile | 1 +
drivers/gpu/drm/panel/panel-tdo-tl070wsh30.c | 256 +++
3 files changed, 268 insertions(+)
create mode 100644 drivers/gpu/drm/panel/panel-tdo-tl070wsh30.c
diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index 8d97d07c5871..2d488a875b99 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -433,6 +433,17 @@ config DRM_PANEL_SONY_ACX565AKM
Say Y here if you want to enable support for the Sony ACX565AKM
800x600 3.5" panel (found on the Nokia N900).
+config DRM_PANEL_TDO_TL070WSH30
+ tristate "TDO TL070WSH30 DSI panel"
+ depends on OF
+ depends on DRM_MIPI_DSI
+ depends on BACKLIGHT_CLASS_DEVICE
+ help
+ Say Y here if you want to enable support for TDO TL070WSH30 TFT-LCD
+ panel module. The panel has a 1024×600 resolution and uses
+ 24 bit RGB per pixel. It provides a MIPI DSI interface to
+ the host, a built-in LED backlight and touch controller.
+
config DRM_PANEL_TPO_TD028TTEC1
tristate "Toppoly (TPO) TD028TTEC1 panel driver"
depends on OF && SPI
diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
index 15a4e7752951..35ee06a1b5c2 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -45,6 +45,7 @@ obj-$(CONFIG_DRM_PANEL_SITRONIX_ST7703) +=
panel-sitronix-st7703.o
obj-$(CONFIG_DRM_PANEL_SITRONIX_ST7789V) += panel-sitronix-st7789v.o
obj-$(CONFIG_DRM_PANEL_SONY_ACX424AKP) += panel-sony-acx424akp.o
obj-$(CONFIG_DRM_PANEL_SONY_ACX565AKM) += panel-sony-acx565akm.o
+obj-$(CONFIG_DRM_PANEL_TDO_TL070WSH30) += panel-tdo-tl070wsh30.o
obj-$(CONFIG_DRM_PANEL_TPO_TD028TTEC1) += panel-tpo-td028ttec1.o
obj-$(CONFIG_DRM_PANEL_TPO_TD043MTEA1) += panel-tpo-td043mtea1.o
obj-$(CONFIG_DRM_PANEL_TPO_TPG110) += panel-tpo-tpg110.o
diff --git a/drivers/gpu/drm/panel/panel-tdo-tl070wsh30.c
b/drivers/gpu/drm/panel/panel-tdo-tl070wsh30.c
new file mode 100644
index ..c7a6c2c42c52
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-tdo-tl070wsh30.c
@@ -0,0 +1,256 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2020 BayLibre, SAS
+ * Author: Neil Armstrong
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+#include
+#include
+#include
+#include
+#include
+
+struct tdo_tl070wsh30_panel {
+ struct drm_panel base;
+ struct mipi_dsi_device *link;
+
+ struct regulator *supply;
+ struct gpio_desc *reset_gpio;
+
+ bool prepared;
+};
+
+static inline
+struct tdo_tl070wsh30_panel *to_tdo_tl070wsh30_panel(struct drm_panel *panel)
+{
+ return container_of(panel, struct tdo_tl070wsh30_panel, base);
+}
+
+static int tdo_tl070wsh30_panel_unprepare(struct drm_panel *panel)
+{
+ struct tdo_tl070wsh30_panel *tdo_tl070wsh30 =
to_tdo_tl070wsh30_panel(panel);
+ int err;
+
+ if (!tdo_tl070wsh30->prepared)
+ return 0;
+
+ err = mipi_dsi_dcs_set_display_off(tdo_tl070wsh30->link);
+ if (err < 0)
+ dev_err(panel->dev, "failed to set display off: %d\n", err);
+
+ usleep_range(1, 11000);
+
+ err = mipi_dsi_dcs_enter_sleep_mode(tdo_tl070wsh30->link);
+ if (err < 0) {
+ dev_err(panel->dev, "failed to enter sleep mode: %d\n", err);
+ return err;
+ }
+
+ usleep_range(1, 11000);
+
+ tdo_tl070wsh30->prepared = false;
+
+ return 0;
+}
+
+static int tdo_tl070wsh30_panel_prepare(struct drm_panel *panel)
+{
+ struct tdo_tl070wsh30_panel *tdo_tl070wsh30 =
to_tdo_tl070wsh30_panel(panel);
+ int err;
+
+ if (tdo_tl070wsh30->prepared)
+ return 0;
+
+ err = mipi_dsi_dcs_exit_sleep_mode(tdo_tl070wsh30->link);
+ if (err < 0) {
+ dev_err(panel->dev, "failed to exit sleep mode: %d\n", err);
+ return err;
+ }
+
+ msleep(200);
+
+ err = mipi_dsi_dcs_set_display_on(tdo_tl070wsh30->link);
+ if (err < 0) {
+ dev_err(panel->dev, "failed to set display on: %d\n", err);
+ return err;
+ }
+
+ msleep(20);
+
+ tdo_tl070wsh30->prepared = true;
+
+ return 0;
+}
+
+static const struct drm_display_mode default_mode = {
+ .clock = 47250,
+ .hdisplay = 1024,
+ .hsync_start = 1024 + 46,
+ .hsync_end = 1024 + 46 + 80,
+ .htotal = 1024 + 46 + 80 + 100,
+ .vdisplay = 600,
+ .vsync_start = 600 + 5,
+ .vsync_end = 600 + 5 + 5,
+ .vtotal = 600 + 5 + 5 + 20,
+ .flags = DRM_MODE_FLAG_PHSY
Re: [PATCH v2 00/11] amd/display: Add GFX9+ modifier support.
On Mon, Sep 7, 2020 at 10:51 AM Ernst Sjöstrand wrote: > > > > Den fre 4 sep. 2020 kl 18:07 skrev Bas Nieuwenhuizen > : >> >> This adds modifier support to radeonsi. > > > Wouldn't it be more correct to say that this adds modifier support to amdgpu > (and enables it to work with radeonsi OpenGL) > or something like that? Yep, this was copy pasted from the userspace MR ... > > //E > >> >> It has been tested on >> >> - VEGA10, RAVEN, NAVI14 >> - weston, sway, X with xf86-video-amdgpu (i.e. legacy path still works) >> >> and includes some basic testing of the layout code. >> >> The main goal is to keep it somewhat simple and regression free, so >> on the display side this series only exposes what the current GPU >> can render to. While we could expose more I think that is more >> suitable for follow-up work as the benefit would be minimal and >> there are some more design discussion there to discuss that are >> orthogonal from the initial implementation. >> >> Similarly this series only exposes 32-bpp displayable DCC in the cases >> that radeonsi would use it and any extra capabilities here should be >> future work. >> >> I believe these are by far the most complicated modifiers we've seen >> up till now, mostly related to >> >> - GPU identification for cases where it matters wrt tiling. >> - Every generation having tiling layout changes >> - Compression settings. >> >> I believe the complexity is necessary as every layout should be different >> and all layouts should be the best in some situation (though not all >> combinations of GPU parameters will actually have an existing GPU). >> >> That said, on the render side the number of modifiers actually listed for >> a given GPU is ~10, and in the current implementation that is the same >> for the display side. (we could expose more actually differing layouts >> on the display side for cross-GPU compatibility, but I consider that >> out of scope for this initial work). >> >> This series can be found on >> https://github.com/BNieuwenhuizen/linux/tree/modifiers >> >> An userspace implementation in radeonsi can be found on >> https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6176 >> >> v2: >> >> Per suggestion from Daniel Vetter I added logic to get the tiling_flags at >> addfb2 time and convert them into modifiers for GFX9+. Furthermore, the DCC >> constant econding modifers only get exposed on RAVEN2 and newer. >> >> Bas Nieuwenhuizen (11): >> drm/amd/display: Do not silently accept DCC for multiplane formats. >> drm/amd: Init modifier field of helper fb. >> drm/amd/display: Honor the offset for plane 0. >> drm/fourcc: Add AMD DRM modifiers. >> drm/amd/display: Store tiling_flags in the framebuffer. >> drm/amd/display: Convert tiling_flags to modifiers. >> drm/amd/display: Refactor surface tiling setup. >> drm/amd/display: Set DC options from modifiers. >> drm/amd/display: Add formats for DCC with 2/3 planes. >> drm/amd/display: Expose modifiers. >> drm/amd/display: Clean up GFX9 tiling_flags path. >> >> drivers/gpu/drm/amd/amdgpu/amdgpu_display.c | 169 +++- >> drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c| 2 +- >> drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h | 3 + >> .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 754 ++ >> .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h | 2 - >> include/uapi/drm/drm_fourcc.h | 115 +++ >> 6 files changed, 880 insertions(+), 165 deletions(-) >> >> -- >> 2.28.0 >> >> ___ >> amd-gfx mailing list >> amd-...@lists.freedesktop.org >> https://lists.freedesktop.org/mailman/listinfo/amd-gfx ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 04/11] drm/fourcc: Add AMD DRM modifiers.
Thanks, fixed both locally. On Mon, Sep 7, 2020 at 10:44 AM Pierre-Eric Pelloux-Prayer wrote: > > Hi Bas, > > 2 small typos you may want to fix: > > On 04/09/2020 18:07, Bas Nieuwenhuizen wrote: > > This adds modifiers for GFX9+ AMD GPUs. > > > > As the modifiers need a lot of parameters I split things out in > > getters and setters. > > - Advantage: simplifies the code a lot > > - Disadvantage: Makes it harder to check that you're setting all > > the required fields. > > > > The tiling modes seem to change every generatio, but the structure > > "generatio" -> "generation" > > > of what each tiling mode is good for stays really similar. As such > > the core of the modifier is > > - the tiling mode > > - a version. Not explicitly a GPU generation, but splitting out > >a new set of tiling equations. > > [...] > > + * with DCC & DCC_RETILE: > > + * - main surface in plane 0 > > + * - displayable DCC surface in plane 1 (not RB-aligned & not > > pipe-aligned) > > + * - pipe-aligned DCC surface in plane 2 (RB-aligned & pipe-aligned) > > + * > > + * For multi-plane formats the above surfaces get merged into one plane for > > + * each for format plane, based on the required alignment only. > > "for each for format plane" => "for each format plane"? > > > Pierre-Eric > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 1/1] drm: allow limiting the scatter list size.
Add drm_device argument to drm_prime_pages_to_sg(), so we can
call dma_max_mapping_size() to figure the segment size limit
and call into __sg_alloc_table_from_pages() with the correct
limit.
This fixes virtio-gpu with sev. Possibly it'll fix other bugs
too given that drm seems to totaly ignore segment size limits
so far ...
v2: place max_segment in drm driver not gem object.
v3: move max_segment next to the other gem fields.
v4: just use dma_max_mapping_size().
Signed-off-by: Gerd Hoffmann
---
include/drm/drm_prime.h | 3 ++-
drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c | 3 ++-
drivers/gpu/drm/drm_gem_shmem_helper.c | 2 +-
drivers/gpu/drm/drm_prime.c | 13 ++---
drivers/gpu/drm/etnaviv/etnaviv_gem.c | 3 ++-
drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c | 2 +-
drivers/gpu/drm/msm/msm_gem.c | 2 +-
drivers/gpu/drm/msm/msm_gem_prime.c | 2 +-
drivers/gpu/drm/nouveau/nouveau_prime.c | 2 +-
drivers/gpu/drm/radeon/radeon_prime.c | 2 +-
drivers/gpu/drm/rockchip/rockchip_drm_gem.c | 5 +++--
drivers/gpu/drm/tegra/gem.c | 2 +-
drivers/gpu/drm/vgem/vgem_drv.c | 2 +-
drivers/gpu/drm/xen/xen_drm_front_gem.c | 3 ++-
14 files changed, 29 insertions(+), 17 deletions(-)
diff --git a/include/drm/drm_prime.h b/include/drm/drm_prime.h
index 9af7422b44cf..bf141e74a1c2 100644
--- a/include/drm/drm_prime.h
+++ b/include/drm/drm_prime.h
@@ -88,7 +88,8 @@ void drm_gem_dmabuf_vunmap(struct dma_buf *dma_buf, void
*vaddr);
int drm_gem_prime_mmap(struct drm_gem_object *obj, struct vm_area_struct *vma);
int drm_gem_dmabuf_mmap(struct dma_buf *dma_buf, struct vm_area_struct *vma);
-struct sg_table *drm_prime_pages_to_sg(struct page **pages, unsigned int
nr_pages);
+struct sg_table *drm_prime_pages_to_sg(struct drm_device *dev,
+ struct page **pages, unsigned int
nr_pages);
struct dma_buf *drm_gem_prime_export(struct drm_gem_object *obj,
int flags);
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
index 519ce4427fce..d7050ab95946 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
@@ -302,7 +302,8 @@ static struct sg_table *amdgpu_dma_buf_map(struct
dma_buf_attachment *attach,
switch (bo->tbo.mem.mem_type) {
case TTM_PL_TT:
- sgt = drm_prime_pages_to_sg(bo->tbo.ttm->pages,
+ sgt = drm_prime_pages_to_sg(obj->dev,
+ bo->tbo.ttm->pages,
bo->tbo.num_pages);
if (IS_ERR(sgt))
return sgt;
diff --git a/drivers/gpu/drm/drm_gem_shmem_helper.c
b/drivers/gpu/drm/drm_gem_shmem_helper.c
index 4b7cfbac4daa..0a952f27c184 100644
--- a/drivers/gpu/drm/drm_gem_shmem_helper.c
+++ b/drivers/gpu/drm/drm_gem_shmem_helper.c
@@ -656,7 +656,7 @@ struct sg_table *drm_gem_shmem_get_sg_table(struct
drm_gem_object *obj)
WARN_ON(shmem->base.import_attach);
- return drm_prime_pages_to_sg(shmem->pages, obj->size >> PAGE_SHIFT);
+ return drm_prime_pages_to_sg(obj->dev, shmem->pages, obj->size >>
PAGE_SHIFT);
}
EXPORT_SYMBOL_GPL(drm_gem_shmem_get_sg_table);
diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
index 1693aa7c14b5..8a6a3c99b7d8 100644
--- a/drivers/gpu/drm/drm_prime.c
+++ b/drivers/gpu/drm/drm_prime.c
@@ -802,9 +802,11 @@ static const struct dma_buf_ops drm_gem_prime_dmabuf_ops =
{
*
* This is useful for implementing &drm_gem_object_funcs.get_sg_table.
*/
-struct sg_table *drm_prime_pages_to_sg(struct page **pages, unsigned int
nr_pages)
+struct sg_table *drm_prime_pages_to_sg(struct drm_device *dev,
+ struct page **pages, unsigned int
nr_pages)
{
struct sg_table *sg = NULL;
+ size_t max_segment = 0;
int ret;
sg = kmalloc(sizeof(struct sg_table), GFP_KERNEL);
@@ -813,8 +815,13 @@ struct sg_table *drm_prime_pages_to_sg(struct page
**pages, unsigned int nr_page
goto out;
}
- ret = sg_alloc_table_from_pages(sg, pages, nr_pages, 0,
- nr_pages << PAGE_SHIFT, GFP_KERNEL);
+ if (dev)
+ max_segment = dma_max_mapping_size(dev->dev);
+ if (max_segment == 0 || max_segment > SCATTERLIST_MAX_SEGMENT)
+ max_segment = SCATTERLIST_MAX_SEGMENT;
+ ret = __sg_alloc_table_from_pages(sg, pages, nr_pages, 0,
+ nr_pages << PAGE_SHIFT,
+ max_segment, GFP_KERNEL);
if (ret)
goto out;
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gem.c
b/drivers/gpu/drm/etnaviv/etnaviv_gem.c
index f06e19e7be04..ea19f1d27275 100644
--- a/drivers/gpu/drm/etnaviv/
[PATCH v4 0/1] drm: fix virtio-gpu + sev
virtio-gpu must make sure scatter list segments are not too big. Gerd Hoffmann (1): drm: allow limiting the scatter list size. include/drm/drm_prime.h | 3 ++- drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c | 3 ++- drivers/gpu/drm/drm_gem_shmem_helper.c | 2 +- drivers/gpu/drm/drm_prime.c | 13 ++--- drivers/gpu/drm/etnaviv/etnaviv_gem.c | 3 ++- drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c | 2 +- drivers/gpu/drm/msm/msm_gem.c | 2 +- drivers/gpu/drm/msm/msm_gem_prime.c | 2 +- drivers/gpu/drm/nouveau/nouveau_prime.c | 2 +- drivers/gpu/drm/radeon/radeon_prime.c | 2 +- drivers/gpu/drm/rockchip/rockchip_drm_gem.c | 5 +++-- drivers/gpu/drm/tegra/gem.c | 2 +- drivers/gpu/drm/vgem/vgem_drv.c | 2 +- drivers/gpu/drm/xen/xen_drm_front_gem.c | 3 ++- 14 files changed, 29 insertions(+), 17 deletions(-) -- 2.27.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 2/3] dt-bindings: display: panel: add TDO tl070wsh30 DSI panel bindings
Hi Neil.
On Mon, Sep 07, 2020 at 01:10:26PM +0200, Neil Armstrong wrote:
> This add the bindings for the 1024*600 tl070wsh30 DSI panel.
The binding looks like a panel-simple-dsi.yaml candidate.
Only differen is enable-gpios versus reset-gpios
Could you check if we can use panel-simple-dsi-yaml.
Sam
>
> Signed-off-by: Neil Armstrong
> ---
> .../display/panel/tdo,tl070wsh30.yaml | 58 +++
> 1 file changed, 58 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/display/panel/tdo,tl070wsh30.yaml
>
> diff --git
> a/Documentation/devicetree/bindings/display/panel/tdo,tl070wsh30.yaml
> b/Documentation/devicetree/bindings/display/panel/tdo,tl070wsh30.yaml
> new file mode 100644
> index ..20f4fdedfcb0
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/panel/tdo,tl070wsh30.yaml
> @@ -0,0 +1,58 @@
> +# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause)
> +# Copyright 2020 BayLibre, SAS
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/display/panel/tdo,tl070wsh30.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: TDO TL070WSH30 DSI panel
> +
> +maintainers:
> + - Neil Armstrong
> +
> +allOf:
> + - $ref: panel-common.yaml#
> +
> +properties:
> +
> + compatible:
> +enum:
> + - tdo,tl070wsh30
> +
> + reg:
> +maxItems: 1
> +description: DSI virtual channel
> +
> + backlight: true
> + reset-gpios: true
> + port: true
> + power-supply: true
> +
> +additionalProperties: false
> +
> +required:
> + - compatible
> + - power-supply
> + - reset-gpios
> + - port
> + - reg
> +
> +examples:
> + - |
> +dsi {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + panel@0 {
> +compatible = "tdo,tl070wsh30";
> +reg = <0>;
> +power-supply = <&vcc_lcd_reg>;
> +backlight = <&panel_backlight>;
> +reset-gpios = <&gpio_reset>;
> +
> +port {
> + panel: endpoint {
> +remote-endpoint = <&mipi_dsi_out>;
> + };
> +};
> + };
> +};
> --
> 2.22.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 00/80] drm/vc4: Support BCM2711 Display Pipeline
Hi Maxime, On 9/3/20 5:00 PM, Maxime Ripard wrote: > Hi everyone, > > Here's a (pretty long) series to introduce support in the VC4 DRM driver > for the display pipeline found in the BCM2711 (and thus the RaspberryPi 4). > > The main differences are that there's two HDMI controllers and that there's > more pixelvalve now. Those pixelvalve come with a mux in the HVS that still > have only 3 FIFOs. Both of those differences are breaking a bunch of > expectations in the driver, so we first need a good bunch of cleanup and > reworks to introduce support for the new controllers. > > Similarly, the HDMI controller has all its registers shuffled and split in > multiple controllers now, so we need a bunch of changes to support this as > well. > > Only the HDMI support is enabled for now (even though the DPI and DSI > outputs have been tested too). > > Let me know if you have any comments > Maxime > > Cc: bcm-kernel-feedback-l...@broadcom.com > Cc: devicet...@vger.kernel.org > Cc: Kamal Dasu > Cc: Philipp Zabel > Cc: Rob Herring > Cc: Stephen Boyd > > Changes from v4: >- Rebased on top of next-20200828 >- Collected the various tags >- Fixed some issues with 4k support and dual output (thanks Hoegeun!) Thanks for your v5 patchset. I tested all patches based on the next-20200812. Everything else is fine, but the dual hdmi modetest doesn't work well in my environment... In my environment, dsi is not connected, I have seen your answer[1]. Do you have any other settings? For example in config.txt. [1] https://lkml.org/lkml/2020/9/2/566 >- Fixed typos in commit logs (thanks Dave!) >- Split the csc setup hook into its own patch again >- Added the CEC clock to the DT binding >- Fixed the DT binding example >- Reduced the number of calls to of_device_is_compatible in vc4_kms_load >- Added back the check for the state commit in our commit hook Best regards, Hoegeun ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 77/80] dt-bindings: display: vc4: hdmi: Add BCM2711 HDMI controllers bindings
Hi Maxime,
On 9/3/20 5:01 PM, Maxime Ripard wrote:
> The HDMI controllers found in the BCM2711 SoC need some adjustments to the
> bindings, especially since the registers have been shuffled around in more
> register ranges.
>
> Reviewed-by: Rob Herring
> Tested-by: Chanwoo Choi
> Tested-by: Hoegeun Kwon
> Tested-by: Stefan Wahren
> Signed-off-by: Maxime Ripard
Thanks for your v5 patch
Reviewed-by: Hoegeun Kwon
Best regards,
Hoegeun
> ---
> Documentation/devicetree/bindings/display/brcm,bcm2711-hdmi.yaml | 117
> -
> 1 file changed, 117 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/display/brcm,bcm2711-hdmi.yaml
>
> diff --git a/Documentation/devicetree/bindings/display/brcm,bcm2711-hdmi.yaml
> b/Documentation/devicetree/bindings/display/brcm,bcm2711-hdmi.yaml
> new file mode 100644
> index ..03a76729d26c
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/brcm,bcm2711-hdmi.yaml
> @@ -0,0 +1,117 @@
> +# SPDX-License-Identifier: GPL-2.0
> +%YAML 1.2
> +---
> +$id:
> https://protect2.fireeye.com/v1/url?k=0b6f5f6c-56a4d852-0b6ed423-0cc47a31309a-d9c680091736128f&q=1&e=24b01bb3-08a1-4c21-9bf9-e1d1e9ffdc3e&u=http%3A%2F%2Fdevicetree.org%2Fschemas%2Fdisplay%2Fbrcm%2Cbcm2711-hdmi.yaml%23
> +$schema:
> https://protect2.fireeye.com/v1/url?k=a854ae90-f59f29ae-a85525df-0cc47a31309a-1160616098892a41&q=1&e=24b01bb3-08a1-4c21-9bf9-e1d1e9ffdc3e&u=http%3A%2F%2Fdevicetree.org%2Fmeta-schemas%2Fcore.yaml%23
> +
> +title: Broadcom BCM2711 HDMI Controller Device Tree Bindings
> +
> +maintainers:
> + - Eric Anholt
> +
> +properties:
> + compatible:
> +enum:
> + - brcm,bcm2711-hdmi0
> + - brcm,bcm2711-hdmi1
> +
> + reg:
> +items:
> + - description: HDMI controller register range
> + - description: DVP register range
> + - description: HDMI PHY register range
> + - description: Rate Manager register range
> + - description: Packet RAM register range
> + - description: Metadata RAM register range
> + - description: CSC register range
> + - description: CEC register range
> + - description: HD register range
> +
> + reg-names:
> +items:
> + - const: hdmi
> + - const: dvp
> + - const: phy
> + - const: rm
> + - const: packet
> + - const: metadata
> + - const: csc
> + - const: cec
> + - const: hd
> +
> + clocks:
> +items:
> + - description: The HDMI state machine clock
> + - description: The Pixel BVB clock
> + - description: The HDMI Audio parent clock
> + - description: The HDMI CEC parent clock
> +
> + clock-names:
> +items:
> + - const: hdmi
> + - const: bvb
> + - const: audio
> + - const: cec
> +
> + ddc:
> +allOf:
> + - $ref: /schemas/types.yaml#/definitions/phandle
> +description: >
> + Phandle of the I2C controller used for DDC EDID probing
> +
> + hpd-gpios:
> +description: >
> + The GPIO pin for the HDMI hotplug detect (if it doesn't appear
> + as an interrupt/status bit in the HDMI controller itself)
> +
> + dmas:
> +maxItems: 1
> +description: >
> + Should contain one entry pointing to the DMA channel used to
> + transfer audio data.
> +
> + dma-names:
> +const: audio-rx
> +
> + resets:
> +maxItems: 1
> +
> +required:
> + - compatible
> + - reg
> + - reg-names
> + - clocks
> + - resets
> + - ddc
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> +hdmi0: hdmi@7ef00700 {
> +compatible = "brcm,bcm2711-hdmi0";
> +reg = <0x7ef00700 0x300>,
> + <0x7ef00300 0x200>,
> + <0x7ef00f00 0x80>,
> + <0x7ef00f80 0x80>,
> + <0x7ef01b00 0x200>,
> + <0x7ef01f00 0x400>,
> + <0x7ef00200 0x80>,
> + <0x7ef04300 0x100>,
> + <0x7ef2 0x100>;
> +reg-names = "hdmi",
> +"dvp",
> +"phy",
> +"rm",
> +"packet",
> +"metadata",
> +"csc",
> +"cec",
> +"hd";
> +clocks = <&firmware_clocks 13>, <&firmware_clocks 14>, <&dvp 1>,
> <&clk_27MHz>;
> +clock-names = "hdmi", "bvb", "audio", "cec";
> +resets = <&dvp 0>;
> +ddc = <&ddc0>;
> +};
> +
> +...
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/3] drm/atomic-helper: Remove the timestamping constant update from drm_atomic_helper_update_legacy_modeset_state()
From: Ville Syrjälä
The timestamping constants have nothing to do with any legacy state
so should not be updated from
drm_atomic_helper_update_legacy_modeset_state().
Let's make everyone call drm_atomic_helper_calc_timestamping_constants()
directly instead of relying on
drm_atomic_helper_update_legacy_modeset_state() to call it.
@@
expression S;
@@
- drm_atomic_helper_calc_timestamping_constants(S);
@@
expression D, S;
@@
drm_atomic_helper_update_legacy_modeset_state(D, S);
+ drm_atomic_helper_calc_timestamping_constants(S);
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 1 +
drivers/gpu/drm/drm_atomic_helper.c | 7 ++-
drivers/gpu/drm/i915/display/intel_display.c | 1 +
drivers/gpu/drm/nouveau/dispnv50/disp.c | 1 +
4 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 490684787cff..0511097343da 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -7397,6 +7397,7 @@ static void amdgpu_dm_atomic_commit_tail(struct
drm_atomic_state *state)
int crtc_disable_count = 0;
drm_atomic_helper_update_legacy_modeset_state(dev, state);
+ drm_atomic_helper_calc_timestamping_constants(state);
dm_state = dm_atomic_get_new_state(state);
if (dm_state && dm_state->context) {
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index 673e3fc282d9..45ee613c8efd 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -1115,9 +1115,7 @@ disable_outputs(struct drm_device *dev, struct
drm_atomic_state *old_state)
* @old_state: atomic state object with old state structures
*
* This function updates all the various legacy modeset state pointers in
- * connectors, encoders and CRTCs. It also updates the timestamping constants
- * used for precise vblank timestamps by calling
- * drm_calc_timestamping_constants().
+ * connectors, encoders and CRTCs.
*
* Drivers can use this for building their own atomic commit if they don't have
* a pure helper-based modeset implementation.
@@ -1187,8 +1185,6 @@ drm_atomic_helper_update_legacy_modeset_state(struct
drm_device *dev,
crtc->y = new_plane_state->src_y >> 16;
}
}
-
- drm_atomic_helper_calc_timestamping_constants(old_state);
}
EXPORT_SYMBOL(drm_atomic_helper_update_legacy_modeset_state);
@@ -1296,6 +1292,7 @@ void drm_atomic_helper_commit_modeset_disables(struct
drm_device *dev,
disable_outputs(dev, old_state);
drm_atomic_helper_update_legacy_modeset_state(dev, old_state);
+ drm_atomic_helper_calc_timestamping_constants(old_state);
crtc_set_mode(dev, old_state);
}
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index ec148a8da2c2..035840ce3825 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -15578,6 +15578,7 @@ static void intel_atomic_commit_tail(struct
intel_atomic_state *state)
if (state->modeset) {
drm_atomic_helper_update_legacy_modeset_state(dev,
&state->base);
+ drm_atomic_helper_calc_timestamping_constants(&state->base);
intel_set_cdclk_pre_plane_update(state);
diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c
b/drivers/gpu/drm/nouveau/dispnv50/disp.c
index 7799530e07c1..b6d1b926bc5e 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/disp.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c
@@ -2069,6 +2069,7 @@ nv50_disp_atomic_commit_tail(struct drm_atomic_state
*state)
drm_atomic_helper_wait_for_fences(dev, state, false);
drm_atomic_helper_wait_for_dependencies(state);
drm_atomic_helper_update_legacy_modeset_state(dev, state);
+ drm_atomic_helper_calc_timestamping_constants(state);
if (atom->lock_core)
mutex_lock(&disp->mutex);
--
2.26.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/3] drm/atomic-helper: Extract drm_atomic_helper_calc_timestamping_constants()
From: Ville Syrjälä
Put the vblank timestamping constants update loop into its own
function. It has no business living inside
drm_atomic_helper_update_legacy_modeset_state() so we'll be wanting
to move it out entirely. As a first step we'll still call it
from drm_atomic_helper_update_legacy_modeset_state().
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_atomic_helper.c | 22 +-
include/drm/drm_atomic_helper.h | 3 +++
2 files changed, 24 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index 9e1ad493e689..673e3fc282d9 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -1186,13 +1186,33 @@ drm_atomic_helper_update_legacy_modeset_state(struct
drm_device *dev,
crtc->x = new_plane_state->src_x >> 16;
crtc->y = new_plane_state->src_y >> 16;
}
+ }
+ drm_atomic_helper_calc_timestamping_constants(old_state);
+}
+EXPORT_SYMBOL(drm_atomic_helper_update_legacy_modeset_state);
+
+/**
+ * drm_atomic_helper_calc_timestamping_constants - update vblank timestamping
constants
+ * @state: atomic state object
+ *
+ * Updates the timestamping constants used for precise vblank timestamps
+ * by calling drm_calc_timestamping_constants() for all enabled crtcs in
@state.
+ */
+void drm_atomic_helper_calc_timestamping_constants(struct drm_atomic_state
*state)
+{
+ struct drm_crtc_state *new_crtc_state;
+ struct drm_crtc *crtc;
+ int i;
+
+ /* set legacy state in the crtc structure */
+ for_each_new_crtc_in_state(state, crtc, new_crtc_state, i) {
if (new_crtc_state->enable)
drm_calc_timestamping_constants(crtc,
&new_crtc_state->adjusted_mode);
}
}
-EXPORT_SYMBOL(drm_atomic_helper_update_legacy_modeset_state);
+EXPORT_SYMBOL(drm_atomic_helper_calc_timestamping_constants);
static void
crtc_set_mode(struct drm_device *dev, struct drm_atomic_state *old_state)
diff --git a/include/drm/drm_atomic_helper.h b/include/drm/drm_atomic_helper.h
index b268180c97eb..85df04c8e62f 100644
--- a/include/drm/drm_atomic_helper.h
+++ b/include/drm/drm_atomic_helper.h
@@ -74,6 +74,9 @@ void
drm_atomic_helper_update_legacy_modeset_state(struct drm_device *dev,
struct drm_atomic_state
*old_state);
+void
+drm_atomic_helper_calc_timestamping_constants(struct drm_atomic_state *state);
+
void drm_atomic_helper_commit_modeset_disables(struct drm_device *dev,
struct drm_atomic_state *state);
void drm_atomic_helper_commit_modeset_enables(struct drm_device *dev,
--
2.26.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/3] drm/i915: Drop the drm_atomic_helper_calc_timestamping_constants() call
From: Ville Syrjälä
We update the timestamping constants per-crtc explicitly in
intel_crtc_update_active_timings(). Furtermore the helper will
use uapi.adjusted_mode whereas we want hw.adjusted_mode. Thus
let's drop the helper call an rely on what we already have in
intel_crtc_update_active_timings(). We can now also drop the
hw.adjusted_mode -> uapi.adjusted_mode copy hack that was added
to keep the helper from deriving the timestamping constants from
the wrong thing.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_display.c | 7 ---
1 file changed, 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 035840ce3825..a846f414c759 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -13472,12 +13472,6 @@ intel_modeset_pipe_config(struct intel_crtc_state
*pipe_config)
"hw max bpp: %i, pipe bpp: %i, dithering: %i\n",
base_bpp, pipe_config->pipe_bpp, pipe_config->dither);
- /*
-* Make drm_calc_timestamping_constants in
-* drm_atomic_helper_update_legacy_modeset_state() happy
-*/
- pipe_config->uapi.adjusted_mode = pipe_config->hw.adjusted_mode;
-
return 0;
}
@@ -15578,7 +15572,6 @@ static void intel_atomic_commit_tail(struct
intel_atomic_state *state)
if (state->modeset) {
drm_atomic_helper_update_legacy_modeset_state(dev,
&state->base);
- drm_atomic_helper_calc_timestamping_constants(&state->base);
intel_set_cdclk_pre_plane_update(state);
--
2.26.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 80/80] ARM: dts: bcm2711: Enable the display pipeline
Hi Maxime,
On 9/3/20 5:01 PM, Maxime Ripard wrote:
> Now that all the drivers have been adjusted for it, let's bring in the
> necessary device tree changes.
>
> The VEC and PV3 are left out for now, since it will require a more specific
> clock setup.
>
> Reviewed-by: Dave Stevenson
> Tested-by: Chanwoo Choi
> Tested-by: Hoegeun Kwon
> Tested-by: Stefan Wahren
> Signed-off-by: Maxime Ripard
Thanks for your v5 patch
Reviewed-by: Hoegeun Kwon
Best regards,
Hoegeun
> ---
> arch/arm/boot/dts/bcm2711-rpi-4-b.dts | 48 +++-
> arch/arm/boot/dts/bcm2711.dtsi| 122 ++-
> 2 files changed, 169 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/boot/dts/bcm2711-rpi-4-b.dts
> b/arch/arm/boot/dts/bcm2711-rpi-4-b.dts
> index e94244a215af..09a1182c2936 100644
> --- a/arch/arm/boot/dts/bcm2711-rpi-4-b.dts
> +++ b/arch/arm/boot/dts/bcm2711-rpi-4-b.dts
> @@ -70,6 +70,14 @@
> };
> };
>
> +&ddc0 {
> + status = "okay";
> +};
> +
> +&ddc1 {
> + status = "okay";
> +};
> +
> &firmware {
> firmware_clocks: clocks {
> compatible = "raspberrypi,firmware-clocks";
> @@ -170,6 +178,38 @@
> "RGMII_TXD3";
> };
>
> +&hdmi0 {
> + clocks = <&firmware_clocks 13>, <&firmware_clocks 14>, <&dvp 0>,
> <&clk_27MHz>;
> + clock-names = "hdmi", "bvb", "audio", "cec";
> + status = "okay";
> +};
> +
> +&hdmi1 {
> + clocks = <&firmware_clocks 13>, <&firmware_clocks 14>, <&dvp 1>,
> <&clk_27MHz>;
> + clock-names = "hdmi", "bvb", "audio", "cec";
> + status = "okay";
> +};
> +
> +&hvs {
> + clocks = <&firmware_clocks 4>;
> +};
> +
> +&pixelvalve0 {
> + status = "okay";
> +};
> +
> +&pixelvalve1 {
> + status = "okay";
> +};
> +
> +&pixelvalve2 {
> + status = "okay";
> +};
> +
> +&pixelvalve4 {
> + status = "okay";
> +};
> +
> &pwm1 {
> pinctrl-names = "default";
> pinctrl-0 = <&pwm1_0_gpio40 &pwm1_1_gpio41>;
> @@ -253,3 +293,11 @@
> &vchiq {
> interrupts = ;
> };
> +
> +&vc4 {
> + status = "okay";
> +};
> +
> +&vec {
> + status = "disabled";
> +};
> diff --git a/arch/arm/boot/dts/bcm2711.dtsi b/arch/arm/boot/dts/bcm2711.dtsi
> index 00bcaed1be32..4847dd305317 100644
> --- a/arch/arm/boot/dts/bcm2711.dtsi
> +++ b/arch/arm/boot/dts/bcm2711.dtsi
> @@ -12,6 +12,18 @@
>
> interrupt-parent = <&gicv2>;
>
> + vc4: gpu {
> + compatible = "brcm,bcm2711-vc5";
> + status = "disabled";
> + };
> +
> + clk_27MHz: clk-27M {
> + #clock-cells = <0>;
> + compatible = "fixed-clock";
> + clock-frequency = <2700>;
> + clock-output-names = "27MHz-clock";
> + };
> +
> clk_108MHz: clk-108M {
> #clock-cells = <0>;
> compatible = "fixed-clock";
> @@ -238,6 +250,27 @@
> status = "disabled";
> };
>
> + pixelvalve0: pixelvalve@7e206000 {
> + compatible = "brcm,bcm2711-pixelvalve0";
> + reg = <0x7e206000 0x100>;
> + interrupts = ;
> + status = "disabled";
> + };
> +
> + pixelvalve1: pixelvalve@7e207000 {
> + compatible = "brcm,bcm2711-pixelvalve1";
> + reg = <0x7e207000 0x100>;
> + interrupts = ;
> + status = "disabled";
> + };
> +
> + pixelvalve2: pixelvalve@7e20a000 {
> + compatible = "brcm,bcm2711-pixelvalve2";
> + reg = <0x7e20a000 0x100>;
> + interrupts = ;
> + status = "disabled";
> + };
> +
> pwm1: pwm@7e20c800 {
> compatible = "brcm,bcm2835-pwm";
> reg = <0x7e20c800 0x28>;
> @@ -248,10 +281,25 @@
> status = "disabled";
> };
>
> - hvs@7e40 {
> + pixelvalve4: pixelvalve@7e216000 {
> + compatible = "brcm,bcm2711-pixelvalve4";
> + reg = <0x7e216000 0x100>;
> + interrupts = ;
> + status = "disabled";
> + };
> +
> + hvs: hvs@7e40 {
> + compatible = "brcm,bcm2711-hvs";
> interrupts = ;
> };
>
> + pixelvalve3: pixelvalve@7ec12000 {
> + compatible = "brcm,bcm2711-pixelvalve3";
> + reg = <0x7ec12000 0x100>;
> + interrupts = ;
> + status = "disabled";
> + };
> +
> dvp: clock@7ef0 {
> compatible = "brcm,brcm2711-dvp";
> reg = <0x7ef0 0x10>;
> @@ -259,6 +307,78 @@
> #clock-cells = <1>;
> #reset-cells = <1>;
>
[PATCH] drm/ttm: merge offset and base in ttm_bus_placement
This is used by TTM to communicate the physical address
which should be used with ioremap(), ioremap_wc(). We don't
need to separate the base and offset in any way here.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c| 7 ---
drivers/gpu/drm/drm_gem_ttm_helper.c | 5 +
drivers/gpu/drm/drm_gem_vram_helper.c | 3 +--
drivers/gpu/drm/nouveau/nouveau_bo.c | 9 -
drivers/gpu/drm/nouveau/nouveau_fbcon.c| 3 +--
drivers/gpu/drm/qxl/qxl_ttm.c | 7 +++
drivers/gpu/drm/radeon/radeon_ttm.c| 14 ++
drivers/gpu/drm/ttm/ttm_bo.c | 3 ---
drivers/gpu/drm/ttm/ttm_bo_util.c | 17 ++---
drivers/gpu/drm/ttm/ttm_bo_vm.c| 3 +--
drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c | 4 ++--
include/drm/ttm/ttm_resource.h | 6 ++
12 files changed, 31 insertions(+), 50 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
index 46d620817482..b39d2a834340 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
@@ -773,7 +773,7 @@ static int amdgpu_ttm_io_mem_reserve(struct ttm_bo_device
*bdev, struct ttm_reso
mem->bus.addr = (u8 *)adev->mman.aper_base_kaddr +
mem->bus.offset;
- mem->bus.base = adev->gmc.aper_base;
+ mem->bus.offset += adev->gmc.aper_base;
mem->bus.is_iomem = true;
break;
default:
@@ -785,12 +785,13 @@ static int amdgpu_ttm_io_mem_reserve(struct ttm_bo_device
*bdev, struct ttm_reso
static unsigned long amdgpu_ttm_io_mem_pfn(struct ttm_buffer_object *bo,
unsigned long page_offset)
{
+ struct amdgpu_device *adev = amdgpu_ttm_adev(bo->bdev);
uint64_t offset = (page_offset << PAGE_SHIFT);
struct drm_mm_node *mm;
mm = amdgpu_find_mm_node(&bo->mem, &offset);
- return (bo->mem.bus.base >> PAGE_SHIFT) + mm->start +
- (offset >> PAGE_SHIFT);
+ offset += adev->gmc.aper_base;
+ return mm->start + (offset >> PAGE_SHIFT);
}
/**
diff --git a/drivers/gpu/drm/drm_gem_ttm_helper.c
b/drivers/gpu/drm/drm_gem_ttm_helper.c
index 892b2288a104..0e4fb9ba43ad 100644
--- a/drivers/gpu/drm/drm_gem_ttm_helper.c
+++ b/drivers/gpu/drm/drm_gem_ttm_helper.c
@@ -43,12 +43,9 @@ void drm_gem_ttm_print_info(struct drm_printer *p, unsigned
int indent,
drm_print_bits(p, bo->mem.placement, plname, ARRAY_SIZE(plname));
drm_printf(p, "\n");
- if (bo->mem.bus.is_iomem) {
- drm_printf_indent(p, indent, "bus.base=%lx\n",
- (unsigned long)bo->mem.bus.base);
+ if (bo->mem.bus.is_iomem)
drm_printf_indent(p, indent, "bus.offset=%lx\n",
(unsigned long)bo->mem.bus.offset);
- }
}
EXPORT_SYMBOL(drm_gem_ttm_print_info);
diff --git a/drivers/gpu/drm/drm_gem_vram_helper.c
b/drivers/gpu/drm/drm_gem_vram_helper.c
index 545a877406f4..255560591916 100644
--- a/drivers/gpu/drm/drm_gem_vram_helper.c
+++ b/drivers/gpu/drm/drm_gem_vram_helper.c
@@ -1042,8 +1042,7 @@ static int bo_driver_io_mem_reserve(struct ttm_bo_device
*bdev,
case TTM_PL_SYSTEM: /* nothing to do */
break;
case TTM_PL_VRAM:
- mem->bus.offset = mem->start << PAGE_SHIFT;
- mem->bus.base = vmm->vram_base;
+ mem->bus.offset = (mem->start << PAGE_SHIFT) + vmm->vram_base;
mem->bus.is_iomem = true;
break;
default:
diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c
b/drivers/gpu/drm/nouveau/nouveau_bo.c
index f74988771ed8..4c2cc862eb19 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
@@ -1081,8 +1081,8 @@ nouveau_ttm_io_mem_reserve(struct ttm_bo_device *bdev,
struct ttm_resource *reg)
case TTM_PL_TT:
#if IS_ENABLED(CONFIG_AGP)
if (drm->agp.bridge) {
- reg->bus.offset = reg->start << PAGE_SHIFT;
- reg->bus.base = drm->agp.base;
+ reg->bus.offset = (reg->start << PAGE_SHIFT) +
+ drm->agp.base;
reg->bus.is_iomem = !drm->agp.cma;
}
#endif
@@ -1094,8 +1094,8 @@ nouveau_ttm_io_mem_reserve(struct ttm_bo_device *bdev,
struct ttm_resource *reg)
}
fallthrough;/* tiled memory */
case TTM_PL_VRAM:
- reg->bus.offset = reg->start << PAGE_SHIFT;
- reg->bus.base = device->func->resource_addr(device, 1);
+ reg->bus.offset = (reg->start << PAGE_SHIFT) +
+ device->func->resource_addr(device, 1);
reg->bus.is_iomem = true;
if (drm->
Re: [PATCH v1 0/2] video: fbdev: radeonfb: PCI PM framework upgrade and fix-ups.
On Mon, 2020-09-07 at 09:55 +0200, Daniel Vetter wrote:
> On Thu, Aug 06, 2020 at 12:52:54PM +0530, Vaibhav Gupta wrote:
> > Linux Kernel Mentee: Remove Legacy Power Management.
> >
> > The original goal of the patch series is to upgrade the power
> > management
> > framework of radeonfb fbdev driver. This has been done by upgrading
> > .suspend()
> > and .resume() callbacks.
> >
> > The upgrade makes sure that the involvement of PCI Core does not
> > change the
> > order of operations executed in a driver. Thus, does not change its
> > behavior.
> >
> > During this process, it was found that "#if defined(CONFIG_PM)" at
> > line 1434 is
> > redundant. This was introduced in the commit
> > 42ddb453a0cd ("radeon: Conditionally compile PM code").
>
> I do wonder whether it wouldn't be better to just outright delete
> these,
> we have the drm radeon driver for pretty much all the same hardware
> ...
The only thing is, afaik, the DRM drivers never got the D2/D3 code that
I wrote for radeonfb to get old powerbooks to suspend/resume.
Cheers,
Ben.
> -Daniel
>
> >
> >
> >
> > Before 42ddb453a0cd:
> > $ git show 65122f7e80b5:drivers/video/aty/radeon_pm.c | grep -n
> > "#ifdef\|#if\|#else\|#endif\|#elif\|#ifndef"
> >
> > Based on output in terminal:
> >
> > 547:#ifdef CONFIG_PM
> >|-- 959:#ifdef CONFIG_PPC_PMAC
> >|-- 972:#endif
> >|-- 1291:#ifdef CONFIG_PPC_OF
> >|-- 1301:#endif /* CONFIG_PPC_OF */
> >|-- 1943:#ifdef CONFIG_PPC_OF
> >|-- 2206:#if 0 /* Not ready yet */
> >|-- 2508:#endif /* 0 */
> >|-- 2510:#endif /* CONFIG_PPC_OF */
> >|-- 2648:#ifdef CONFIG_PPC_PMAC
> >|-- 2654:#endif /* CONFIG_PPC_PMAC */
> >|-- 2768:#ifdef CONFIG_PPC_PMAC
> >|-- 2774:#endif /* CONFIG_PPC_PMAC */
> >|-- 2791:#ifdef CONFIG_PPC_OF__disabled
> >|-- 2801:#endif /* CONFIG_PPC_OF */
> > 2803:#endif /* CONFIG_PM */
> >
> >
> >
> > After 42ddb453a0cd:
> > $ git show 42ddb453a0cd:drivers/video/aty/radeon_pm.c | grep -n
> > "#ifdef\|#if\|#else\|#endif\|#elif\|#ifndef"
> >
> > Based on output in terminal:
> >
> > 547:#ifdef CONFIG_PM
> >|-- 959:#ifdef CONFIG_PPC_PMAC
> >|-- 972:#endif
> >|-- 1291:#ifdef CONFIG_PPC_OF
> >|-- 1301:#endif /* CONFIG_PPC_OF */
> >|-- 1430:#if defined(CONFIG_PM)
> >|-- 1431:#if defined(CONFIG_X86) ||
> > defined(CONFIG_PPC_PMAC)
> >|-- 1944:#endif
> >|-- 1946:#ifdef CONFIG_PPC_OF
> >|-- 1947:#ifdef CONFIG_PPC_PMAC
> >|-- 2208:#endif
> >|-- 2209:#endif
> >|-- 2211:#if 0 /* Not ready yet */
> >|-- 2513:#endif /* 0 */
> >|-- 2515:#endif /* CONFIG_PPC_OF */
> >|-- 2653:#ifdef CONFIG_PPC_PMAC
> >|-- 2659:#endif /* CONFIG_PPC_PMAC */
> >|-- 2773:#ifdef CONFIG_PPC_PMAC
> >|-- 2779:#endif /* CONFIG_PPC_PMAC */
> >|-- 2796:#ifdef CONFIG_PPC_OF__disabled
> >|-- 2806:#endif /* CONFIG_PPC_OF */
> > 2808:#endif /* CONFIG_PM */
> >
> >
> >
> > This also affected the CONFIG_PPC_OF container (line 1943 at commit
> > 65122f7e80b5)
> >
> > The patch-series fixes it along with PM upgrade.
> >
> > All patches are compile-tested only.
> >
> > Test tools:
> > - Compiler: gcc (GCC) 10.1.0
> > - allmodconfig build: make -j$(nproc) W=1 all
> >
> > Vaibhav Gupta (2):
> > video: fbdev: aty: radeon_pm: remove redundant CONFIG_PM
> > container
> > fbdev: radeonfb:use generic power management
> >
> > drivers/video/fbdev/aty/radeon_base.c | 10 ---
> > drivers/video/fbdev/aty/radeon_pm.c | 38 ---
> >
> > drivers/video/fbdev/aty/radeonfb.h| 3 +--
> > 3 files changed, 35 insertions(+), 16 deletions(-)
> >
> > --
> > 2.27.0
> >
> > ___
> > dri-devel mailing list
> > dri-devel@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/ttm: merge offset and base in ttm_bus_placement
Acked-by: Nirmoy Das
On 9/7/20 2:05 PM, Christian König wrote:
This is used by TTM to communicate the physical address
which should be used with ioremap(), ioremap_wc(). We don't
need to separate the base and offset in any way here.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c| 7 ---
drivers/gpu/drm/drm_gem_ttm_helper.c | 5 +
drivers/gpu/drm/drm_gem_vram_helper.c | 3 +--
drivers/gpu/drm/nouveau/nouveau_bo.c | 9 -
drivers/gpu/drm/nouveau/nouveau_fbcon.c| 3 +--
drivers/gpu/drm/qxl/qxl_ttm.c | 7 +++
drivers/gpu/drm/radeon/radeon_ttm.c| 14 ++
drivers/gpu/drm/ttm/ttm_bo.c | 3 ---
drivers/gpu/drm/ttm/ttm_bo_util.c | 17 ++---
drivers/gpu/drm/ttm/ttm_bo_vm.c| 3 +--
drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c | 4 ++--
include/drm/ttm/ttm_resource.h | 6 ++
12 files changed, 31 insertions(+), 50 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
index 46d620817482..b39d2a834340 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
@@ -773,7 +773,7 @@ static int amdgpu_ttm_io_mem_reserve(struct ttm_bo_device
*bdev, struct ttm_reso
mem->bus.addr = (u8 *)adev->mman.aper_base_kaddr +
mem->bus.offset;
- mem->bus.base = adev->gmc.aper_base;
+ mem->bus.offset += adev->gmc.aper_base;
mem->bus.is_iomem = true;
break;
default:
@@ -785,12 +785,13 @@ static int amdgpu_ttm_io_mem_reserve(struct ttm_bo_device
*bdev, struct ttm_reso
static unsigned long amdgpu_ttm_io_mem_pfn(struct ttm_buffer_object *bo,
unsigned long page_offset)
{
+ struct amdgpu_device *adev = amdgpu_ttm_adev(bo->bdev);
uint64_t offset = (page_offset << PAGE_SHIFT);
struct drm_mm_node *mm;
mm = amdgpu_find_mm_node(&bo->mem, &offset);
- return (bo->mem.bus.base >> PAGE_SHIFT) + mm->start +
- (offset >> PAGE_SHIFT);
+ offset += adev->gmc.aper_base;
+ return mm->start + (offset >> PAGE_SHIFT);
}
/**
diff --git a/drivers/gpu/drm/drm_gem_ttm_helper.c
b/drivers/gpu/drm/drm_gem_ttm_helper.c
index 892b2288a104..0e4fb9ba43ad 100644
--- a/drivers/gpu/drm/drm_gem_ttm_helper.c
+++ b/drivers/gpu/drm/drm_gem_ttm_helper.c
@@ -43,12 +43,9 @@ void drm_gem_ttm_print_info(struct drm_printer *p, unsigned
int indent,
drm_print_bits(p, bo->mem.placement, plname, ARRAY_SIZE(plname));
drm_printf(p, "\n");
- if (bo->mem.bus.is_iomem) {
- drm_printf_indent(p, indent, "bus.base=%lx\n",
- (unsigned long)bo->mem.bus.base);
+ if (bo->mem.bus.is_iomem)
drm_printf_indent(p, indent, "bus.offset=%lx\n",
(unsigned long)bo->mem.bus.offset);
- }
}
EXPORT_SYMBOL(drm_gem_ttm_print_info);
diff --git a/drivers/gpu/drm/drm_gem_vram_helper.c b/drivers/gpu/drm/drm_gem_vram_helper.c
index 545a877406f4..255560591916 100644
--- a/drivers/gpu/drm/drm_gem_vram_helper.c
+++ b/drivers/gpu/drm/drm_gem_vram_helper.c
@@ -1042,8 +1042,7 @@ static int bo_driver_io_mem_reserve(struct ttm_bo_device
*bdev,
case TTM_PL_SYSTEM: /* nothing to do */
break;
case TTM_PL_VRAM:
- mem->bus.offset = mem->start << PAGE_SHIFT;
- mem->bus.base = vmm->vram_base;
+ mem->bus.offset = (mem->start << PAGE_SHIFT) + vmm->vram_base;
mem->bus.is_iomem = true;
break;
default:
diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c
b/drivers/gpu/drm/nouveau/nouveau_bo.c
index f74988771ed8..4c2cc862eb19 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
@@ -1081,8 +1081,8 @@ nouveau_ttm_io_mem_reserve(struct ttm_bo_device *bdev,
struct ttm_resource *reg)
case TTM_PL_TT:
#if IS_ENABLED(CONFIG_AGP)
if (drm->agp.bridge) {
- reg->bus.offset = reg->start << PAGE_SHIFT;
- reg->bus.base = drm->agp.base;
+ reg->bus.offset = (reg->start << PAGE_SHIFT) +
+ drm->agp.base;
reg->bus.is_iomem = !drm->agp.cma;
}
#endif
@@ -1094,8 +1094,8 @@ nouveau_ttm_io_mem_reserve(struct ttm_bo_device *bdev,
struct ttm_resource *reg)
}
fallthrough;/* tiled memory */
case TTM_PL_VRAM:
- reg->bus.offset = reg->start << PAGE_SHIFT;
- reg->bus.base = device->func->resource_addr(device, 1);
+ reg->bus.offset = (reg->start << PAGE_SHIFT) +
+ device->func->resource_addr(devic
[PULL] drm-intel-gt-next
Hi Dave & Daniel, Exactly same content as previous PR: https://lists.freedesktop.org/archives/intel-gfx/2020-September/247626.html Just rebased adding the missing S-o-b:s and updated "Fixes:" tags accordingly as requested. Regards, Joonas *** drm-intel-gt-next-2020-09-07: (Same content as drm-intel-gt-next-2020-09-04-3, S-o-b's added) UAPI Changes: (- Potential implicit changes from WW locking refactoring) Cross-subsystem Changes: (- WW locking changes should align the i915 locking more with others) Driver Changes: - MAJOR: Apply WW locking across the driver (Maarten) - Reverts for 5 commits to make applying WW locking faster (Maarten) - Disable preparser around invalidations on Tigerlake for non-RCS engines (Chris) - Add missing dma_fence_put() for error case of syncobj timeline (Chris) - Parse command buffer earlier in eb_relocate(slow) to facilitate backoff (Maarten) - Pin engine before pinning all objects (Maarten) - Rework intel_context pinning to do everything outside of pin_mutex (Maarten) - Avoid tracking GEM context until registered (Cc: stable, Chris) - Provide a fastpath for waiting on vma bindings (Chris) - Fixes to preempt-to-busy mechanism (Chris) - Distinguish the virtual breadcrumbs from the irq breadcrumbs (Chris) - Switch to object allocations for page directories (Chris) - Hold context/request reference while breadcrumbs are active (Chris) - Make sure execbuffer always passes ww state to i915_vma_pin (Maarten) - Code refactoring to facilitate use of WW locking (Maarten) - Locking refactoring to use more granular locking (Maarten, Chris) - Support for multiple pinned timelines per engine (Chris) - Move complication of I915_GEM_THROTTLE to the ioctl from general code (Chris) - Make active tracking/vma page-directory stash work preallocated (Chris) - Avoid flushing submission tasklet too often (Chris) - Reduce context termination list iteration guard to RCU (Chris) - Reductions to locking contention (Chris) - Fixes for issues found by CI (Chris) The following changes since commit 3393649977f9a8847c659e282ea290d4b703295c: Merge tag 'drm-intel-next-2020-08-24-1' of git://anongit.freedesktop.org/drm/drm-intel into drm-next (2020-08-28 14:09:31 +1000) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-gt-next-2020-09-07 for you to fetch changes up to e0ee152fce25dc9269c7ea5280c98aa4b3682759: drm/i915: Unlock the shared hwsp_gtt object after pinning (2020-09-07 15:08:11 +0300) (Same content as drm-intel-gt-next-2020-09-04-3, S-o-b's added) UAPI Changes: (- Potential implicit changes from WW locking refactoring) Cross-subsystem Changes: (- WW locking changes should align the i915 locking more with others) Driver Changes: - MAJOR: Apply WW locking across the driver (Maarten) - Reverts for 5 commits to make applying WW locking faster (Maarten) - Disable preparser around invalidations on Tigerlake for non-RCS engines (Chris) - Add missing dma_fence_put() for error case of syncobj timeline (Chris) - Parse command buffer earlier in eb_relocate(slow) to facilitate backoff (Maarten) - Pin engine before pinning all objects (Maarten) - Rework intel_context pinning to do everything outside of pin_mutex (Maarten) - Avoid tracking GEM context until registered (Cc: stable, Chris) - Provide a fastpath for waiting on vma bindings (Chris) - Fixes to preempt-to-busy mechanism (Chris) - Distinguish the virtual breadcrumbs from the irq breadcrumbs (Chris) - Switch to object allocations for page directories (Chris) - Hold context/request reference while breadcrumbs are active (Chris) - Make sure execbuffer always passes ww state to i915_vma_pin (Maarten) - Code refactoring to facilitate use of WW locking (Maarten) - Locking refactoring to use more granular locking (Maarten, Chris) - Support for multiple pinned timelines per engine (Chris) - Move complication of I915_GEM_THROTTLE to the ioctl from general code (Chris) - Make active tracking/vma page-directory stash work preallocated (Chris) - Avoid flushing submission tasklet too often (Chris) - Reduce context termination list iteration guard to RCU (Chris) - Reductions to locking contention (Chris) - Fixes for issues found by CI (Chris) Chris Wilson (33): drm/i915: Reduce i915_request.lock contention for i915_request_wait drm/i915/selftests: Mock the status_page.vma for the kernel_context drm/i915: Soften the tasklet flush frequency before waits drm/i915/gem: Remove disordered per-file request list for throttling drm/i915/gt: Disable preparser around xcs invalidations on tgl drm/i915/gt: Delay taking the spinlock for grabbing from the buffer pool drm/i915/selftests: Flush the active barriers before asserting drm/i915/gt: Fix termination condition for freeing all buffer objects drm/i915/gem: Delay t
Re: [PATCH v10 30/30] videobuf2: use sgtable-based scatterlist wrappers
Hi Marek,
On Fri, Sep 4, 2020 at 3:35 PM Marek Szyprowski
wrote:
>
> Use recently introduced common wrappers operating directly on the struct
> sg_table objects and scatterlist page iterators to make the code a bit
> more compact, robust, easier to follow and copy/paste safe.
>
> No functional change, because the code already properly did all the
> scatterlist related calls.
>
> Signed-off-by: Marek Szyprowski
> Reviewed-by: Robin Murphy
> ---
> .../common/videobuf2/videobuf2-dma-contig.c | 34 ---
> .../media/common/videobuf2/videobuf2-dma-sg.c | 32 +++--
> .../common/videobuf2/videobuf2-vmalloc.c | 12 +++
> 3 files changed, 31 insertions(+), 47 deletions(-)
>
Thanks for the patch! Please see my comments inline.
> diff --git a/drivers/media/common/videobuf2/videobuf2-dma-contig.c
> b/drivers/media/common/videobuf2/videobuf2-dma-contig.c
> index ec3446cc45b8..1b242d844dde 100644
> --- a/drivers/media/common/videobuf2/videobuf2-dma-contig.c
> +++ b/drivers/media/common/videobuf2/videobuf2-dma-contig.c
> @@ -58,10 +58,10 @@ static unsigned long vb2_dc_get_contiguous_size(struct
> sg_table *sgt)
> unsigned int i;
> unsigned long size = 0;
>
> - for_each_sg(sgt->sgl, s, sgt->nents, i) {
> + for_each_sgtable_dma_sg(sgt, s, i) {
> if (sg_dma_address(s) != expected)
> break;
> - expected = sg_dma_address(s) + sg_dma_len(s);
> + expected += sg_dma_len(s);
> size += sg_dma_len(s);
> }
> return size;
> @@ -103,8 +103,7 @@ static void vb2_dc_prepare(void *buf_priv)
> if (!sgt)
> return;
>
> - dma_sync_sg_for_device(buf->dev, sgt->sgl, sgt->orig_nents,
> - buf->dma_dir);
> + dma_sync_sgtable_for_device(buf->dev, sgt, buf->dma_dir);
> }
>
> static void vb2_dc_finish(void *buf_priv)
> @@ -115,7 +114,7 @@ static void vb2_dc_finish(void *buf_priv)
> if (!sgt)
> return;
>
> - dma_sync_sg_for_cpu(buf->dev, sgt->sgl, sgt->orig_nents,
> buf->dma_dir);
> + dma_sync_sgtable_for_cpu(buf->dev, sgt, buf->dma_dir);
> }
>
> /*/
> @@ -275,8 +274,8 @@ static void vb2_dc_dmabuf_ops_detach(struct dma_buf *dbuf,
> * memory locations do not require any explicit cache
> * maintenance prior or after being used by the device.
> */
> - dma_unmap_sg_attrs(db_attach->dev, sgt->sgl, sgt->orig_nents,
> - attach->dma_dir, DMA_ATTR_SKIP_CPU_SYNC);
> + dma_unmap_sgtable(db_attach->dev, sgt, attach->dma_dir,
> + DMA_ATTR_SKIP_CPU_SYNC);
> sg_free_table(sgt);
> kfree(attach);
> db_attach->priv = NULL;
> @@ -301,8 +300,8 @@ static struct sg_table *vb2_dc_dmabuf_ops_map(
>
> /* release any previous cache */
> if (attach->dma_dir != DMA_NONE) {
> - dma_unmap_sg_attrs(db_attach->dev, sgt->sgl, sgt->orig_nents,
> - attach->dma_dir, DMA_ATTR_SKIP_CPU_SYNC);
> + dma_unmap_sgtable(db_attach->dev, sgt, attach->dma_dir,
> + DMA_ATTR_SKIP_CPU_SYNC);
> attach->dma_dir = DMA_NONE;
> }
>
> @@ -310,9 +309,8 @@ static struct sg_table *vb2_dc_dmabuf_ops_map(
> * mapping to the client with new direction, no cache sync
> * required see comment in vb2_dc_dmabuf_ops_detach()
> */
> - sgt->nents = dma_map_sg_attrs(db_attach->dev, sgt->sgl,
> sgt->orig_nents,
> - dma_dir, DMA_ATTR_SKIP_CPU_SYNC);
> - if (!sgt->nents) {
> + if (dma_map_sgtable(db_attach->dev, sgt, dma_dir,
> + DMA_ATTR_SKIP_CPU_SYNC)) {
> pr_err("failed to map scatterlist\n");
> mutex_unlock(lock);
> return ERR_PTR(-EIO);
As opposed to dma_map_sg_attrs(), dma_map_sgtable() now returns an
error code on its own. Is it expected to ignore it and return -EIO?
> @@ -455,8 +453,8 @@ static void vb2_dc_put_userptr(void *buf_priv)
> * No need to sync to CPU, it's already synced to the CPU
> * since the finish() memop will have been called before this.
> */
> - dma_unmap_sg_attrs(buf->dev, sgt->sgl, sgt->orig_nents,
> - buf->dma_dir, DMA_ATTR_SKIP_CPU_SYNC);
> + dma_unmap_sgtable(buf->dev, sgt, buf->dma_dir,
> + DMA_ATTR_SKIP_CPU_SYNC);
> pages = frame_vector_pages(buf->vec);
> /* sgt should exist only if vector contains pages... */
> BUG_ON(IS_ERR(pages));
> @@ -553,9 +551,8 @@ static void *vb2_dc_get_userptr(struct device *dev,
> unsigned long vaddr,
>
Re: [PATCH v2 2/3] dt-bindings: display: panel: add TDO tl070wsh30 DSI panel bindings
Hi,
On 07/09/2020 13:45, Sam Ravnborg wrote:
> Hi Neil.
>
> On Mon, Sep 07, 2020 at 01:10:26PM +0200, Neil Armstrong wrote:
>> This add the bindings for the 1024*600 tl070wsh30 DSI panel.
>
> The binding looks like a panel-simple-dsi.yaml candidate.
> Only differen is enable-gpios versus reset-gpios
This is the only difference, the panel only has a reset signal and no
enable signal.
But I can add a reset-gpios to panel-simple-dsi.yaml, would it be ok ?
Neil
>
> Could you check if we can use panel-simple-dsi-yaml.
>
> Sam
>
>>
>> Signed-off-by: Neil Armstrong
>> ---
>> .../display/panel/tdo,tl070wsh30.yaml | 58 +++
>> 1 file changed, 58 insertions(+)
>> create mode 100644
>> Documentation/devicetree/bindings/display/panel/tdo,tl070wsh30.yaml
>>
>> diff --git
>> a/Documentation/devicetree/bindings/display/panel/tdo,tl070wsh30.yaml
>> b/Documentation/devicetree/bindings/display/panel/tdo,tl070wsh30.yaml
>> new file mode 100644
>> index ..20f4fdedfcb0
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/display/panel/tdo,tl070wsh30.yaml
>> @@ -0,0 +1,58 @@
>> +# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause)
>> +# Copyright 2020 BayLibre, SAS
>> +%YAML 1.2
>> +---
>> +$id: http://devicetree.org/schemas/display/panel/tdo,tl070wsh30.yaml#
>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>> +
>> +title: TDO TL070WSH30 DSI panel
>> +
>> +maintainers:
>> + - Neil Armstrong
>> +
>> +allOf:
>> + - $ref: panel-common.yaml#
>> +
>> +properties:
>> +
>> + compatible:
>> +enum:
>> + - tdo,tl070wsh30
>> +
>> + reg:
>> +maxItems: 1
>> +description: DSI virtual channel
>> +
>> + backlight: true
>> + reset-gpios: true
>> + port: true
>> + power-supply: true
>> +
>> +additionalProperties: false
>> +
>> +required:
>> + - compatible
>> + - power-supply
>> + - reset-gpios
>> + - port
>> + - reg
>> +
>> +examples:
>> + - |
>> +dsi {
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + panel@0 {
>> +compatible = "tdo,tl070wsh30";
>> +reg = <0>;
>> +power-supply = <&vcc_lcd_reg>;
>> +backlight = <&panel_backlight>;
>> +reset-gpios = <&gpio_reset>;
>> +
>> +port {
>> + panel: endpoint {
>> +remote-endpoint = <&mipi_dsi_out>;
>> + };
>> +};
>> + };
>> +};
>> --
>> 2.22.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/2] drm/qxl: don't touch mem.bus.offset
This is internal to TTM and should not be used by drivers directly.
Drop the call to qxl_ttm_io_mem_reserve() and use mem->start instead.
Signed-off-by: Christian König
---
drivers/gpu/drm/qxl/qxl_object.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/qxl/qxl_object.c b/drivers/gpu/drm/qxl/qxl_object.c
index f838b6d689aa..b2a1fa61920b 100644
--- a/drivers/gpu/drm/qxl/qxl_object.c
+++ b/drivers/gpu/drm/qxl/qxl_object.c
@@ -167,6 +167,7 @@ int qxl_bo_kmap(struct qxl_bo *bo, void **ptr)
void *qxl_bo_kmap_atomic_page(struct qxl_device *qdev,
struct qxl_bo *bo, int page_offset)
{
+ unsigned long offset;
void *rptr;
int ret;
struct io_mapping *map;
@@ -178,9 +179,8 @@ void *qxl_bo_kmap_atomic_page(struct qxl_device *qdev,
else
goto fallback;
- ret = qxl_ttm_io_mem_reserve(bo->tbo.bdev, &bo->tbo.mem);
-
- return io_mapping_map_atomic_wc(map, bo->tbo.mem.bus.offset +
page_offset);
+ offset = bo->tbo.mem.start << PAGE_SHIFT;
+ return io_mapping_map_atomic_wc(map, offset + page_offset);
fallback:
if (bo->kptr) {
rptr = bo->kptr + (page_offset * PAGE_SIZE);
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/2] drm/ttm: merge offset and base in ttm_bus_placement
This is used by TTM to communicate the physical address
which should be used with ioremap(), ioremap_wc(). We don't
need to separate the base and offset in any way here.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c| 7 ---
drivers/gpu/drm/drm_gem_ttm_helper.c | 5 +
drivers/gpu/drm/drm_gem_vram_helper.c | 3 +--
drivers/gpu/drm/nouveau/nouveau_bo.c | 9 -
drivers/gpu/drm/nouveau/nouveau_fbcon.c| 3 +--
drivers/gpu/drm/qxl/qxl_ttm.c | 7 +++
drivers/gpu/drm/radeon/radeon_ttm.c| 14 ++
drivers/gpu/drm/ttm/ttm_bo.c | 3 ---
drivers/gpu/drm/ttm/ttm_bo_util.c | 17 ++---
drivers/gpu/drm/ttm/ttm_bo_vm.c| 3 +--
drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c | 4 ++--
include/drm/ttm/ttm_resource.h | 6 ++
12 files changed, 31 insertions(+), 50 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
index 46d620817482..b39d2a834340 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
@@ -773,7 +773,7 @@ static int amdgpu_ttm_io_mem_reserve(struct ttm_bo_device
*bdev, struct ttm_reso
mem->bus.addr = (u8 *)adev->mman.aper_base_kaddr +
mem->bus.offset;
- mem->bus.base = adev->gmc.aper_base;
+ mem->bus.offset += adev->gmc.aper_base;
mem->bus.is_iomem = true;
break;
default:
@@ -785,12 +785,13 @@ static int amdgpu_ttm_io_mem_reserve(struct ttm_bo_device
*bdev, struct ttm_reso
static unsigned long amdgpu_ttm_io_mem_pfn(struct ttm_buffer_object *bo,
unsigned long page_offset)
{
+ struct amdgpu_device *adev = amdgpu_ttm_adev(bo->bdev);
uint64_t offset = (page_offset << PAGE_SHIFT);
struct drm_mm_node *mm;
mm = amdgpu_find_mm_node(&bo->mem, &offset);
- return (bo->mem.bus.base >> PAGE_SHIFT) + mm->start +
- (offset >> PAGE_SHIFT);
+ offset += adev->gmc.aper_base;
+ return mm->start + (offset >> PAGE_SHIFT);
}
/**
diff --git a/drivers/gpu/drm/drm_gem_ttm_helper.c
b/drivers/gpu/drm/drm_gem_ttm_helper.c
index 892b2288a104..0e4fb9ba43ad 100644
--- a/drivers/gpu/drm/drm_gem_ttm_helper.c
+++ b/drivers/gpu/drm/drm_gem_ttm_helper.c
@@ -43,12 +43,9 @@ void drm_gem_ttm_print_info(struct drm_printer *p, unsigned
int indent,
drm_print_bits(p, bo->mem.placement, plname, ARRAY_SIZE(plname));
drm_printf(p, "\n");
- if (bo->mem.bus.is_iomem) {
- drm_printf_indent(p, indent, "bus.base=%lx\n",
- (unsigned long)bo->mem.bus.base);
+ if (bo->mem.bus.is_iomem)
drm_printf_indent(p, indent, "bus.offset=%lx\n",
(unsigned long)bo->mem.bus.offset);
- }
}
EXPORT_SYMBOL(drm_gem_ttm_print_info);
diff --git a/drivers/gpu/drm/drm_gem_vram_helper.c
b/drivers/gpu/drm/drm_gem_vram_helper.c
index 545a877406f4..255560591916 100644
--- a/drivers/gpu/drm/drm_gem_vram_helper.c
+++ b/drivers/gpu/drm/drm_gem_vram_helper.c
@@ -1042,8 +1042,7 @@ static int bo_driver_io_mem_reserve(struct ttm_bo_device
*bdev,
case TTM_PL_SYSTEM: /* nothing to do */
break;
case TTM_PL_VRAM:
- mem->bus.offset = mem->start << PAGE_SHIFT;
- mem->bus.base = vmm->vram_base;
+ mem->bus.offset = (mem->start << PAGE_SHIFT) + vmm->vram_base;
mem->bus.is_iomem = true;
break;
default:
diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c
b/drivers/gpu/drm/nouveau/nouveau_bo.c
index f74988771ed8..4c2cc862eb19 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
@@ -1081,8 +1081,8 @@ nouveau_ttm_io_mem_reserve(struct ttm_bo_device *bdev,
struct ttm_resource *reg)
case TTM_PL_TT:
#if IS_ENABLED(CONFIG_AGP)
if (drm->agp.bridge) {
- reg->bus.offset = reg->start << PAGE_SHIFT;
- reg->bus.base = drm->agp.base;
+ reg->bus.offset = (reg->start << PAGE_SHIFT) +
+ drm->agp.base;
reg->bus.is_iomem = !drm->agp.cma;
}
#endif
@@ -1094,8 +1094,8 @@ nouveau_ttm_io_mem_reserve(struct ttm_bo_device *bdev,
struct ttm_resource *reg)
}
fallthrough;/* tiled memory */
case TTM_PL_VRAM:
- reg->bus.offset = reg->start << PAGE_SHIFT;
- reg->bus.base = device->func->resource_addr(device, 1);
+ reg->bus.offset = (reg->start << PAGE_SHIFT) +
+ device->func->resource_addr(device, 1);
reg->bus.is_iomem = true;
if (drm->
Re: [PATCH] drm/doc: Document that modifiers are always required for fb
On Mon, Sep 7, 2020 at 11:07 AM Pekka Paalanen wrote: > > On Mon, 7 Sep 2020 10:41:37 +0200 > Daniel Vetter wrote: > > > On Mon, Sep 07, 2020 at 08:37:31AM +, Simon Ser wrote: > > > On Monday, September 7, 2020 10:31 AM, Daniel Vetter > > > wrote: > > > > > > > On Wed, Sep 02, 2020 at 02:59:49PM +, Simon Ser wrote: > > > > > > > > > On Wednesday, September 2, 2020 4:29 PM, Daniel Vetter > > > > > daniel.vet...@ffwll.ch wrote: > > > > > > > > > > > On Wed, Sep 2, 2020 at 2:49 PM Simon Ser cont...@emersion.fr wrote: > > > > > > > > > > > > > On Wednesday, September 2, 2020 2:44 PM, Daniel Vetter > > > > > > > daniel.vet...@ffwll.ch wrote: > > > > > > > > > > > > > > > > I suppose something similar happens in user-space: > > > > > > > > > gbm_bo_create > > > > > > > > > without modifiers needs to properly set the implicit > > > > > > > > > modifier, ie. > > > > > > > > > gbm_bo_get_modifier needs to return the effective modifier. > > > > > > > > > Is this > > > > > > > > > something already documented? > > > > > > > > > > > > > > > > I don't think that happens, but it has come up in discussions. > > > > > > > > It's > > > > > > > > kinda different scenario though: getfb2 is for cross-compositor > > > > > > > > stuff, > > > > > > > > enabling smooth transitions at boot-up and when switching. So > > > > > > > > you have > > > > > > > > a legit reason for mixing modifier-aware userspace with > > > > > > > > non-modifier-aware userspace. And the modifier-aware userspace > > > > > > > > would > > > > > > > > like that everything works with modifiers consistently, > > > > > > > > including > > > > > > > > getfb2. But gbm is just within a single process, and that should > > > > > > > > either run all with modifiers, or not at all, since these > > > > > > > > worlds just > > > > > > > > dont mix well. Hence I'm not seeing much use for that, > > > > > > > > -modesetting > > > > > > > > being a confused mess nonwithstanding :-) > > > > > > > > > > > > > > Well… There's also the case where some legacy Wayland client > > > > > > > talks to a > > > > > > > modifier-aware compositor. gbm_bo_import would be called without a > > > > > > > modifier, but the compositor expects gbm_bo_get_modifier to work. > > > > > > > Also, wlroots will call gbm_bo_create without a modifier to only > > > > > > > let > > > > > > > the driver pick "safe" modifiers in case passing the full list of > > > > > > > modifiers results in a black screen. Later on wlroots will call > > > > > > > gbm_bo_get_modifier to figure out what modifier the driver picked. > > > > > > > > > > > > gbm_bo_import is a different thing from gbm_bo_create. Former I > > > > > > agree > > > > > > should figure out the right modifiers (and I think it does that, at > > > > > > least on intel mesa). For gbm_bo_create I'm not sure we should/need > > > > > > to > > > > > > require that. > > > > > > > > > > I guess the compositor will just forward the value returned by > > > > > gbm_bo_get_modifier in any case, so returning INVALID would be fine > > > > > too (to mean "implicit modifier"). > > > > > In both the create and import cases, other metadata like pitches and > > > > > offsets should be correctly set I think? > > > > > > > > Well if you have a modifier format underneath, the non-modifiered > > > > offsets > > > > and pitches might be pure fiction. Also, they might not be sufficient, > > > > if > > > > the modifier adds more planes. > > > > > > In this case (gbm_bo_create without modifiers), we're discussing > > > whether we require gbm_bo_get_modifier to return a valid modifier, or > > > if INVALID is fine. > > > > Hm then I missed the use-case for a gbm_bo_create without modifiers, where > > afterwards userspace wants the modifiers. That sounds like a bug (and yes > > -modesetting is buggy that way). > > I'm guessing that use case might be related to > https://gitlab.freedesktop.org/wayland/weston/-/issues/429 > > The weston issue is about > gbm_surface_create/gbm_surface_create_with_modifiers, but that's not > too different from gbm_bo_create/gbm_bo_create_with_modifiers? > > Weston happens to have this code: > https://gitlab.freedesktop.org/wayland/weston/-/blob/9.0.0/libweston/backend-drm/drm-gbm.c#L209-230 > and then it unconditionally calls gbm_bo_get_modifier(). However, > DRM_FORMAT_MOD_INVALID is handled specially: > https://gitlab.freedesktop.org/wayland/weston/-/blob/9.0.0/libweston/backend-drm/fb.c#L80-97 Hm yeah that feels a bit like an interim hack instead of more modifiers fallback logic. I guess shouldn't be too tricky for mesa to support that, since internally modifier aware drivers work only with modifiers anyway (or at least should, that's what we're requiring on the kms side with this patch at least). Up to mesa people I'd say. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://
Re: [PATCH v4 1/1] drm: allow limiting the scatter list size.
On Mon, Sep 7, 2020 at 1:24 PM Gerd Hoffmann wrote:
>
> Add drm_device argument to drm_prime_pages_to_sg(), so we can
> call dma_max_mapping_size() to figure the segment size limit
> and call into __sg_alloc_table_from_pages() with the correct
> limit.
>
> This fixes virtio-gpu with sev. Possibly it'll fix other bugs
> too given that drm seems to totaly ignore segment size limits
> so far ...
>
> v2: place max_segment in drm driver not gem object.
> v3: move max_segment next to the other gem fields.
> v4: just use dma_max_mapping_size().
>
> Signed-off-by: Gerd Hoffmann
Uh, are you sure this works in all cases for virtio? The comments I've
found suggest very much not ... Or is that all very old stuff only
that no one cares about anymore?
-Daniel
> ---
> include/drm/drm_prime.h | 3 ++-
> drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c | 3 ++-
> drivers/gpu/drm/drm_gem_shmem_helper.c | 2 +-
> drivers/gpu/drm/drm_prime.c | 13 ++---
> drivers/gpu/drm/etnaviv/etnaviv_gem.c | 3 ++-
> drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c | 2 +-
> drivers/gpu/drm/msm/msm_gem.c | 2 +-
> drivers/gpu/drm/msm/msm_gem_prime.c | 2 +-
> drivers/gpu/drm/nouveau/nouveau_prime.c | 2 +-
> drivers/gpu/drm/radeon/radeon_prime.c | 2 +-
> drivers/gpu/drm/rockchip/rockchip_drm_gem.c | 5 +++--
> drivers/gpu/drm/tegra/gem.c | 2 +-
> drivers/gpu/drm/vgem/vgem_drv.c | 2 +-
> drivers/gpu/drm/xen/xen_drm_front_gem.c | 3 ++-
> 14 files changed, 29 insertions(+), 17 deletions(-)
>
> diff --git a/include/drm/drm_prime.h b/include/drm/drm_prime.h
> index 9af7422b44cf..bf141e74a1c2 100644
> --- a/include/drm/drm_prime.h
> +++ b/include/drm/drm_prime.h
> @@ -88,7 +88,8 @@ void drm_gem_dmabuf_vunmap(struct dma_buf *dma_buf, void
> *vaddr);
> int drm_gem_prime_mmap(struct drm_gem_object *obj, struct vm_area_struct
> *vma);
> int drm_gem_dmabuf_mmap(struct dma_buf *dma_buf, struct vm_area_struct *vma);
>
> -struct sg_table *drm_prime_pages_to_sg(struct page **pages, unsigned int
> nr_pages);
> +struct sg_table *drm_prime_pages_to_sg(struct drm_device *dev,
> + struct page **pages, unsigned int
> nr_pages);
> struct dma_buf *drm_gem_prime_export(struct drm_gem_object *obj,
> int flags);
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
> index 519ce4427fce..d7050ab95946 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
> @@ -302,7 +302,8 @@ static struct sg_table *amdgpu_dma_buf_map(struct
> dma_buf_attachment *attach,
>
> switch (bo->tbo.mem.mem_type) {
> case TTM_PL_TT:
> - sgt = drm_prime_pages_to_sg(bo->tbo.ttm->pages,
> + sgt = drm_prime_pages_to_sg(obj->dev,
> + bo->tbo.ttm->pages,
> bo->tbo.num_pages);
> if (IS_ERR(sgt))
> return sgt;
> diff --git a/drivers/gpu/drm/drm_gem_shmem_helper.c
> b/drivers/gpu/drm/drm_gem_shmem_helper.c
> index 4b7cfbac4daa..0a952f27c184 100644
> --- a/drivers/gpu/drm/drm_gem_shmem_helper.c
> +++ b/drivers/gpu/drm/drm_gem_shmem_helper.c
> @@ -656,7 +656,7 @@ struct sg_table *drm_gem_shmem_get_sg_table(struct
> drm_gem_object *obj)
>
> WARN_ON(shmem->base.import_attach);
>
> - return drm_prime_pages_to_sg(shmem->pages, obj->size >> PAGE_SHIFT);
> + return drm_prime_pages_to_sg(obj->dev, shmem->pages, obj->size >>
> PAGE_SHIFT);
> }
> EXPORT_SYMBOL_GPL(drm_gem_shmem_get_sg_table);
>
> diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
> index 1693aa7c14b5..8a6a3c99b7d8 100644
> --- a/drivers/gpu/drm/drm_prime.c
> +++ b/drivers/gpu/drm/drm_prime.c
> @@ -802,9 +802,11 @@ static const struct dma_buf_ops drm_gem_prime_dmabuf_ops
> = {
> *
> * This is useful for implementing &drm_gem_object_funcs.get_sg_table.
> */
> -struct sg_table *drm_prime_pages_to_sg(struct page **pages, unsigned int
> nr_pages)
> +struct sg_table *drm_prime_pages_to_sg(struct drm_device *dev,
> + struct page **pages, unsigned int
> nr_pages)
> {
> struct sg_table *sg = NULL;
> + size_t max_segment = 0;
> int ret;
>
> sg = kmalloc(sizeof(struct sg_table), GFP_KERNEL);
> @@ -813,8 +815,13 @@ struct sg_table *drm_prime_pages_to_sg(struct page
> **pages, unsigned int nr_page
> goto out;
> }
>
> - ret = sg_alloc_table_from_pages(sg, pages, nr_pages, 0,
> - nr_pages << PAGE_SHIFT, GFP_KERNEL);
> + if (dev)
> + max_segment = dma_max_mapping_size(dev->dev);
> + if (max_segment == 0 || max_segment > SCATTERLIST_MAX_SEGMENT)
> + max_s
Re: [PATCH v10 30/30] videobuf2: use sgtable-based scatterlist wrappers
Hi Tomasz,
On 07.09.2020 15:07, Tomasz Figa wrote:
> On Fri, Sep 4, 2020 at 3:35 PM Marek Szyprowski
> wrote:
>> Use recently introduced common wrappers operating directly on the struct
>> sg_table objects and scatterlist page iterators to make the code a bit
>> more compact, robust, easier to follow and copy/paste safe.
>>
>> No functional change, because the code already properly did all the
>> scatterlist related calls.
>>
>> Signed-off-by: Marek Szyprowski
>> Reviewed-by: Robin Murphy
>> ---
>> .../common/videobuf2/videobuf2-dma-contig.c | 34 ---
>> .../media/common/videobuf2/videobuf2-dma-sg.c | 32 +++--
>> .../common/videobuf2/videobuf2-vmalloc.c | 12 +++
>> 3 files changed, 31 insertions(+), 47 deletions(-)
>>
> Thanks for the patch! Please see my comments inline.
>
>> diff --git a/drivers/media/common/videobuf2/videobuf2-dma-contig.c
>> b/drivers/media/common/videobuf2/videobuf2-dma-contig.c
>> index ec3446cc45b8..1b242d844dde 100644
>> --- a/drivers/media/common/videobuf2/videobuf2-dma-contig.c
>> +++ b/drivers/media/common/videobuf2/videobuf2-dma-contig.c
>> @@ -58,10 +58,10 @@ static unsigned long vb2_dc_get_contiguous_size(struct
>> sg_table *sgt)
>> unsigned int i;
>> unsigned long size = 0;
>>
>> - for_each_sg(sgt->sgl, s, sgt->nents, i) {
>> + for_each_sgtable_dma_sg(sgt, s, i) {
>> if (sg_dma_address(s) != expected)
>> break;
>> - expected = sg_dma_address(s) + sg_dma_len(s);
>> + expected += sg_dma_len(s);
>> size += sg_dma_len(s);
>> }
>> return size;
>> @@ -103,8 +103,7 @@ static void vb2_dc_prepare(void *buf_priv)
>> if (!sgt)
>> return;
>>
>> - dma_sync_sg_for_device(buf->dev, sgt->sgl, sgt->orig_nents,
>> - buf->dma_dir);
>> + dma_sync_sgtable_for_device(buf->dev, sgt, buf->dma_dir);
>> }
>>
>> static void vb2_dc_finish(void *buf_priv)
>> @@ -115,7 +114,7 @@ static void vb2_dc_finish(void *buf_priv)
>> if (!sgt)
>> return;
>>
>> - dma_sync_sg_for_cpu(buf->dev, sgt->sgl, sgt->orig_nents,
>> buf->dma_dir);
>> + dma_sync_sgtable_for_cpu(buf->dev, sgt, buf->dma_dir);
>> }
>>
>> /*/
>> @@ -275,8 +274,8 @@ static void vb2_dc_dmabuf_ops_detach(struct dma_buf
>> *dbuf,
>> * memory locations do not require any explicit cache
>> * maintenance prior or after being used by the device.
>> */
>> - dma_unmap_sg_attrs(db_attach->dev, sgt->sgl, sgt->orig_nents,
>> - attach->dma_dir, DMA_ATTR_SKIP_CPU_SYNC);
>> + dma_unmap_sgtable(db_attach->dev, sgt, attach->dma_dir,
>> + DMA_ATTR_SKIP_CPU_SYNC);
>> sg_free_table(sgt);
>> kfree(attach);
>> db_attach->priv = NULL;
>> @@ -301,8 +300,8 @@ static struct sg_table *vb2_dc_dmabuf_ops_map(
>>
>> /* release any previous cache */
>> if (attach->dma_dir != DMA_NONE) {
>> - dma_unmap_sg_attrs(db_attach->dev, sgt->sgl, sgt->orig_nents,
>> - attach->dma_dir, DMA_ATTR_SKIP_CPU_SYNC);
>> + dma_unmap_sgtable(db_attach->dev, sgt, attach->dma_dir,
>> + DMA_ATTR_SKIP_CPU_SYNC);
>> attach->dma_dir = DMA_NONE;
>> }
>>
>> @@ -310,9 +309,8 @@ static struct sg_table *vb2_dc_dmabuf_ops_map(
>> * mapping to the client with new direction, no cache sync
>> * required see comment in vb2_dc_dmabuf_ops_detach()
>> */
>> - sgt->nents = dma_map_sg_attrs(db_attach->dev, sgt->sgl,
>> sgt->orig_nents,
>> - dma_dir, DMA_ATTR_SKIP_CPU_SYNC);
>> - if (!sgt->nents) {
>> + if (dma_map_sgtable(db_attach->dev, sgt, dma_dir,
>> + DMA_ATTR_SKIP_CPU_SYNC)) {
>> pr_err("failed to map scatterlist\n");
>> mutex_unlock(lock);
>> return ERR_PTR(-EIO);
> As opposed to dma_map_sg_attrs(), dma_map_sgtable() now returns an
> error code on its own. Is it expected to ignore it and return -EIO?
Those errors are more or less propagated to userspace and -EIO has been
already widely documented in V4L2 documentation as the error code for
the most of the V4L2 ioctls. I don't want to change it. A possible
-EINVAL returned from dma_map_sgtable() was just one of the 'generic'
error codes, not very descriptive in that case. Probably the main
problem here is that dma_map_sg() and friend doesn't return any error
codes...
> ...
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://li
[PATCH V3] i2c: i2c-qcom-geni: Add shutdown callback for i2c
If the hardware is still accessing memory after SMMU translation
is disabled (as part of smmu shutdown callback), then the
IOVAs (I/O virtual address) which it was using will go on the bus
as the physical addresses which will result in unknown crashes
like NoC/interconnect errors.
So, implement shutdown callback to i2c driver to stop on-going transfer
and unmap DMA mappings during system "reboot" or "shutdown".
Store DMA mapping data in geni_i2c_dev struct to enhance DMA mapping
data scope. For example during shutdown callback to unmap DMA mapping,
this stored DMA mapping data can be used to call geni_se_tx_dma_unprep
and geni_se_rx_dma_unprep functions.
Fixes: 37692de5d523 ("i2c: i2c-qcom-geni: Add bus driver for the Qualcomm GENI
I2C controller")
Signed-off-by: Roja Rani Yarubandi
---
Changes in V2:
- As per Stephen's comments added seperate function for stop transfer,
fixed minor nitpicks.
- As per Stephen's comments, changed commit text.
Changes in V3:
- As per Stephen's comments, squashed patch 1 into patch 2, added Fixes tag.
- As per Akash's comments, included FIFO case in stop_xfer, fixed minor
nitpicks.
drivers/i2c/busses/i2c-qcom-geni.c | 70 +++---
include/linux/qcom-geni-se.h | 5 +++
2 files changed, 69 insertions(+), 6 deletions(-)
diff --git a/drivers/i2c/busses/i2c-qcom-geni.c
b/drivers/i2c/busses/i2c-qcom-geni.c
index dead5db3315a..b3609760909f 100644
--- a/drivers/i2c/busses/i2c-qcom-geni.c
+++ b/drivers/i2c/busses/i2c-qcom-geni.c
@@ -86,6 +86,9 @@ struct geni_i2c_dev {
u32 clk_freq_out;
const struct geni_i2c_clk_fld *clk_fld;
int suspended;
+ dma_addr_t tx_dma;
+ dma_addr_t rx_dma;
+ size_t xfer_len;
};
struct geni_i2c_err_log {
@@ -352,12 +355,12 @@ static void geni_i2c_tx_fsm_rst(struct geni_i2c_dev *gi2c)
static int geni_i2c_rx_one_msg(struct geni_i2c_dev *gi2c, struct i2c_msg *msg,
u32 m_param)
{
- dma_addr_t rx_dma;
unsigned long time_left;
void *dma_buf = NULL;
struct geni_se *se = &gi2c->se;
size_t len = msg->len;
+ gi2c->xfer_len = len;
if (!of_machine_is_compatible("lenovo,yoga-c630"))
dma_buf = i2c_get_dma_safe_msg_buf(msg, 32);
@@ -368,7 +371,7 @@ static int geni_i2c_rx_one_msg(struct geni_i2c_dev *gi2c,
struct i2c_msg *msg,
writel_relaxed(len, se->base + SE_I2C_RX_TRANS_LEN);
- if (dma_buf && geni_se_rx_dma_prep(se, dma_buf, len, &rx_dma)) {
+ if (dma_buf && geni_se_rx_dma_prep(se, dma_buf, len, &gi2c->rx_dma)) {
geni_se_select_mode(se, GENI_SE_FIFO);
i2c_put_dma_safe_msg_buf(dma_buf, msg, false);
dma_buf = NULL;
@@ -384,7 +387,8 @@ static int geni_i2c_rx_one_msg(struct geni_i2c_dev *gi2c,
struct i2c_msg *msg,
if (dma_buf) {
if (gi2c->err)
geni_i2c_rx_fsm_rst(gi2c);
- geni_se_rx_dma_unprep(se, rx_dma, len);
+ geni_se_rx_dma_unprep(se, gi2c->rx_dma, len);
+ gi2c->rx_dma = (dma_addr_t)NULL;
i2c_put_dma_safe_msg_buf(dma_buf, msg, !gi2c->err);
}
@@ -394,12 +398,12 @@ static int geni_i2c_rx_one_msg(struct geni_i2c_dev *gi2c,
struct i2c_msg *msg,
static int geni_i2c_tx_one_msg(struct geni_i2c_dev *gi2c, struct i2c_msg *msg,
u32 m_param)
{
- dma_addr_t tx_dma;
unsigned long time_left;
void *dma_buf = NULL;
struct geni_se *se = &gi2c->se;
size_t len = msg->len;
+ gi2c->xfer_len = len;
if (!of_machine_is_compatible("lenovo,yoga-c630"))
dma_buf = i2c_get_dma_safe_msg_buf(msg, 32);
@@ -410,7 +414,7 @@ static int geni_i2c_tx_one_msg(struct geni_i2c_dev *gi2c,
struct i2c_msg *msg,
writel_relaxed(len, se->base + SE_I2C_TX_TRANS_LEN);
- if (dma_buf && geni_se_tx_dma_prep(se, dma_buf, len, &tx_dma)) {
+ if (dma_buf && geni_se_tx_dma_prep(se, dma_buf, len, &gi2c->tx_dma)) {
geni_se_select_mode(se, GENI_SE_FIFO);
i2c_put_dma_safe_msg_buf(dma_buf, msg, false);
dma_buf = NULL;
@@ -429,7 +433,8 @@ static int geni_i2c_tx_one_msg(struct geni_i2c_dev *gi2c,
struct i2c_msg *msg,
if (dma_buf) {
if (gi2c->err)
geni_i2c_tx_fsm_rst(gi2c);
- geni_se_tx_dma_unprep(se, tx_dma, len);
+ geni_se_tx_dma_unprep(se, gi2c->tx_dma, len);
+ gi2c->tx_dma = (dma_addr_t)NULL;
i2c_put_dma_safe_msg_buf(dma_buf, msg, !gi2c->err);
}
@@ -479,6 +484,51 @@ static int geni_i2c_xfer(struct i2c_adapter *adap,
return ret;
}
+static void geni_i2c_stop_xfer(struct geni_i2c_dev *gi2c)
+{
+ int ret;
+ u32 dma;
+ u32 val;
+ u32 geni_status;
+ struct geni_se *se = &gi2c->se;
+
+ ret = pm_runtime_get_sync(gi2c->se.d
Re: [PATCH 5/9] arm64: dts: renesas: r8a77961: Add VSP device nodes
On 07.09.2020 11:08, Sergei Shtylyov wrote: From: Kuninori Morimoto This patch adds VSP device nodes for R-Car M3-W+ (r8a77961) SoC. This patch is test on R-Car M3-W+ Salvator-XS board. Was tested? The same comment to the patches 6 & 7. Signed-off-by: Kuninori Morimoto [...] MBR, Sergei ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH V2 2/2] i2c: i2c-qcom-geni: Add shutdown callback for i2c
On 2020-08-26 17:26, Akash Asthana wrote:
Hi Roja,
On 8/20/2020 4:05 PM, Roja Rani Yarubandi wrote:
If the hardware is still accessing memory after SMMU translation
is disabled (as part of smmu shutdown callback), then the
IOVAs (I/O virtual address) which it was using will go on the bus
as the physical addresses which will result in unknown crashes
like NoC/interconnect errors.
So, implement shutdown callback to i2c driver to unmap DMA mappings
during system "reboot" or "shutdown".
Signed-off-by: Roja Rani Yarubandi
---
Changes in V2:
- As per Stephen's comments added seperate function for stop
transfer,
fixed minor nitpicks.
drivers/i2c/busses/i2c-qcom-geni.c | 43
++
include/linux/qcom-geni-se.h | 5
2 files changed, 48 insertions(+)
diff --git a/drivers/i2c/busses/i2c-qcom-geni.c
b/drivers/i2c/busses/i2c-qcom-geni.c
index 1fda5c7c2cfc..d07f2f33bb75 100644
--- a/drivers/i2c/busses/i2c-qcom-geni.c
+++ b/drivers/i2c/busses/i2c-qcom-geni.c
@@ -486,6 +486,28 @@ static int geni_i2c_xfer(struct i2c_adapter
*adap,
return ret;
}
+static void geni_i2c_stop_xfer(struct geni_i2c_dev *gi2c)
+{
+ u32 val;
+ struct geni_se *se = &gi2c->se;
+
+ val = readl_relaxed(gi2c->se.base + SE_DMA_DEBUG_REG0);
+ if (val & DMA_TX_ACTIVE) {
+ geni_i2c_abort_xfer(gi2c);
+ gi2c->cur_wr = 0;
+ if (gi2c->err)
+ geni_i2c_tx_fsm_rst(gi2c);
+ geni_se_tx_dma_unprep(se, gi2c->tx_dma, gi2c->xfer_len);
+ }
should be 'else if', because TX and RX can't happen parallel.
+ if (val & DMA_RX_ACTIVE) {
+ geni_i2c_abort_xfer(gi2c);
+ gi2c->cur_rd = 0;
+ if (gi2c->err)
+ geni_i2c_rx_fsm_rst(gi2c);
+ geni_se_rx_dma_unprep(se, gi2c->rx_dma, gi2c->xfer_len);
+ }
+}
+
static u32 geni_i2c_func(struct i2c_adapter *adap)
{
return I2C_FUNC_I2C | (I2C_FUNC_SMBUS_EMUL &
~I2C_FUNC_SMBUS_QUICK);
@@ -617,6 +639,26 @@ static int geni_i2c_remove(struct platform_device
*pdev)
return 0;
}
+static void geni_i2c_shutdown(struct platform_device *pdev)
+{
+ int ret;
+ u32 dma;
+ struct geni_i2c_dev *gi2c = platform_get_drvdata(pdev);
+ struct geni_se *se = &gi2c->se;
+
+ ret = pm_runtime_get_sync(gi2c->se.dev);
+ if (ret < 0) {
+ dev_err(gi2c->se.dev, "Failed to resume device: %d\n", ret);
+ return;
+ }
+
+ dma = readl_relaxed(se->base + SE_GENI_DMA_MODE_EN);
Wrt to current issue context it may be suffice to stop just DMA mode
transfers but why not stop all mode of active transfer during shutdown
in a generic way.
Regards,
Akash
Okay, I will include FIFO transfer case also in stop_xfer
+ if (dma)
+ geni_i2c_stop_xfer(gi2c);
+
+ pm_runtime_put_sync_suspend(gi2c->se.dev);
+}
+
static int __maybe_unused geni_i2c_runtime_suspend(struct device
*dev)
{
int ret;
@@ -677,6 +719,7 @@ MODULE_DEVICE_TABLE(of, geni_i2c_dt_match);
static struct platform_driver geni_i2c_driver = {
.probe = geni_i2c_probe,
.remove = geni_i2c_remove,
+ .shutdown = geni_i2c_shutdown,
.driver = {
.name = "geni_i2c",
.pm = &geni_i2c_pm_ops,
diff --git a/include/linux/qcom-geni-se.h
b/include/linux/qcom-geni-se.h
index dd464943f717..c3c016496d98 100644
--- a/include/linux/qcom-geni-se.h
+++ b/include/linux/qcom-geni-se.h
@@ -77,6 +77,7 @@ struct geni_se {
#define SE_DMA_RX_FSM_RST 0xd58
#define SE_HW_PARAM_0 0xe24
#define SE_HW_PARAM_1 0xe28
+#define SE_DMA_DEBUG_REG0 0xe40
/* GENI_FORCE_DEFAULT_REG fields */
#define FORCE_DEFAULT BIT(0)
@@ -207,6 +208,10 @@ struct geni_se {
#define RX_GENI_CANCEL_IRQBIT(11)
#define RX_GENI_GP_IRQ_EXTGENMASK(13, 12)
+/* SE_DMA_DEBUG_REG0 Register fields */
+#define DMA_TX_ACTIVE BIT(0)
+#define DMA_RX_ACTIVE BIT(1)
+
/* SE_HW_PARAM_0 fields */
#define TX_FIFO_WIDTH_MSK GENMASK(29, 24)
#define TX_FIFO_WIDTH_SHFT24
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: 答复: [PATCH v2 6/6] drm/panel: Add Ilitek ILI9341 DBI panel driver
Le dim. 30 août 2020 à 22:28, Sam Ravnborg a écrit : Hi Laurent. > > Please read the cover letter, it explains why it's done this way. The > whole point of this patchset is to merge DSI and DBI frameworks in a > way that can be maintained. I think this proves the point that the proposed naming is confusing. At least a rename would be required. Do you have any inputs on the amount of rename we are looking into. Is this a simple s/struct mipi_dsi_device/struct mipi_dxi_device/ or something more? We should script the rename as it will tocuh a lot of files, and without a script we would chase this. But once it is scripted it would be trivial to perform. I did not look at this enough, but I had an idea that we would have do to a s/dsi/dxi/ in a lot of places. (dxi is my best proposal at the moment for something covering both dsi and dbi). dcs? Since DBI and DSI panels generally all use DCS commands. -Paul ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 4/9] arm64: dts: renesas: r8a77961: Add FCP device nodes
On 07.09.2020 5:58, Kuninori Morimoto wrote: From: Kuninori Morimoto This patch adds FCP device nodes for R-Car M3-W+ (r8a77961) SoC. This patch is test on R-Car M3-W+ Salvator-XS board. Was tested? Signed-off-by: Kuninori Morimoto [...] MBR, Sergei ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 8/9] arm64: dts: renesas: r8a77961-salvator-xs: add HDMI Display support
Hello! On 07.09.2020 5:59, Kuninori Morimoto wrote: From: Kuninori Morimoto This patch enables HDMI Display on R-Car M3-W+ Salvator-XS board. This patch is test on R-Car M3-W+ Salvator-XS board. Was tested, perhaps? Signed-off-by: Kuninori Morimoto [...] MBR, Sergei ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/3] drm/msm/dsi: support SM8150 and SM8250
On 04/09/2020 20:28, Jonathan Marek wrote: Add support for SM8150 and SM8250 DSI. Note I haven't tested SM8150 recently, but DSI is almost identical to SM8250. On SM8250: Tested-by: Dmitry Baryshkov Jonathan Marek (3): drm/msm/dsi: remove unused clk_pre/clk_post in msm_dsi_dphy_timing drm/msm/dsi: add DSI config for sm8150 and sm8250 drm/msm/dsi: add support for 7nm DSI PHY/PLL .../devicetree/bindings/display/msm/dsi.txt | 6 +- drivers/gpu/drm/msm/Kconfig | 7 + drivers/gpu/drm/msm/Makefile | 2 + drivers/gpu/drm/msm/dsi/dsi.h | 2 + drivers/gpu/drm/msm/dsi/dsi.xml.h | 423 drivers/gpu/drm/msm/dsi/dsi_cfg.c | 5 +- drivers/gpu/drm/msm/dsi/dsi_cfg.h | 2 + drivers/gpu/drm/msm/dsi/phy/dsi_phy.c | 102 ++ drivers/gpu/drm/msm/dsi/phy/dsi_phy.h | 6 +- drivers/gpu/drm/msm/dsi/phy/dsi_phy_7nm.c | 255 + drivers/gpu/drm/msm/dsi/pll/dsi_pll.c | 4 + drivers/gpu/drm/msm/dsi/pll/dsi_pll.h | 10 + drivers/gpu/drm/msm/dsi/pll/dsi_pll_7nm.c | 902 ++ 13 files changed, 1721 insertions(+), 5 deletions(-) create mode 100644 drivers/gpu/drm/msm/dsi/phy/dsi_phy_7nm.c create mode 100644 drivers/gpu/drm/msm/dsi/pll/dsi_pll_7nm.c -- With best wishes Dmitry ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v11 00/11] PCI: brcmstb: enable PCIe for STB chips
On Thu, Aug 27, 2020 at 09:29:59AM -0400, Jim Quinlan wrote: > On Thu, Aug 27, 2020 at 2:35 AM Christoph Hellwig wrote: > > > > On Tue, Aug 25, 2020 at 10:40:27AM -0700, Florian Fainelli wrote: > > > Hi, > > > > > > On 8/24/2020 12:30 PM, Jim Quinlan wrote: > > >> > > >> Patchset Summary: > > >>Enhance a PCIe host controller driver. Because of its unusual design > > >>we are foced to change dev->dma_pfn_offset into a more general role > > >>allowing multiple offsets. See the 'v1' notes below for more info. > > > > > > We are version 11 and counting, and it is not clear to me whether there is > > > any chance of getting these patches reviewed and hopefully merged for the > > > 5.10 merge window. > > > > > > There are a lot of different files being touched, so what would be the > > > ideal way of routing those changes towards inclusion? > > > > FYI, I offered to take the dma-mapping bits through the dma-mapping tree. > > I have a bit of a backlog, but plan to review and if Jim is ok with that > > apply the current version. > Sounds good to me. Hi Jim, is the dependency now solved ? Should we review/take this series as is for v5.10 through the PCI tree ? Thanks, Lorenzo ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] gpu/drm: cleanup coding style a bit
Remove first assignment to info which is meaningless.
Put the width and higth check first.
This change is to make the code a bit readable.
Signed-off-by: Bernard Zhao
---
drivers/gpu/drm/drm_framebuffer.c | 9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/drm_framebuffer.c
b/drivers/gpu/drm/drm_framebuffer.c
index df656366a530..2f5b0c2bb0fe 100644
--- a/drivers/gpu/drm/drm_framebuffer.c
+++ b/drivers/gpu/drm/drm_framebuffer.c
@@ -176,8 +176,7 @@ static int framebuffer_check(struct drm_device *dev,
int i;
/* check if the format is supported at all */
- info = __drm_format_info(r->pixel_format);
- if (!info) {
+ if (!__drm_format_info(r->pixel_format)) {
struct drm_format_name_buf format_name;
DRM_DEBUG_KMS("bad framebuffer format %s\n",
@@ -186,9 +185,6 @@ static int framebuffer_check(struct drm_device *dev,
return -EINVAL;
}
- /* now let the driver pick its own format info */
- info = drm_get_format_info(dev, r);
-
if (r->width == 0) {
DRM_DEBUG_KMS("bad framebuffer width %u\n", r->width);
return -EINVAL;
@@ -199,6 +195,9 @@ static int framebuffer_check(struct drm_device *dev,
return -EINVAL;
}
+ /* now let the driver pick its own format info */
+ info = drm_get_format_info(dev, r);
+
for (i = 0; i < info->num_planes; i++) {
unsigned int width = fb_plane_width(r->width, info, i);
unsigned int height = fb_plane_height(r->height, info, i);
--
2.28.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH V2 1/2] i2c: i2c-qcom-geni: Store DMA mapping data in geni_i2c_dev struct
On 2020-08-26 17:25, Akash Asthana wrote:
Hi Roja,
On 8/20/2020 4:05 PM, Roja Rani Yarubandi wrote:
Store DMA mapping data in geni_i2c_dev struct to enhance DMA mapping
data scope. For example during shutdown callback to unmap DMA mapping,
this stored DMA mapping data can be used to call geni_se_tx_dma_unprep
and geni_se_rx_dma_unprep functions.
Signed-off-by: Roja Rani Yarubandi
---
Changes in V2:
- As per Stephen's comments, changed commit text, fixed minor
nitpicks.
drivers/i2c/busses/i2c-qcom-geni.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/i2c/busses/i2c-qcom-geni.c
b/drivers/i2c/busses/i2c-qcom-geni.c
index 7f130829bf01..1fda5c7c2cfc 100644
--- a/drivers/i2c/busses/i2c-qcom-geni.c
+++ b/drivers/i2c/busses/i2c-qcom-geni.c
@@ -86,6 +86,9 @@ struct geni_i2c_dev {
u32 clk_freq_out;
const struct geni_i2c_clk_fld *clk_fld;
int suspended;
+ dma_addr_t tx_dma;
+ dma_addr_t rx_dma;
+ size_t xfer_len;
};
struct geni_i2c_err_log {
@@ -358,6 +361,7 @@ static int geni_i2c_rx_one_msg(struct geni_i2c_dev
*gi2c, struct i2c_msg *msg,
struct geni_se *se = &gi2c->se;
size_t len = msg->len;
+ gi2c->xfer_len = msg->len;
nit: gi2c->xfer = len, for tx_one_msg as well.
Regards,
Akash
Okay
if (!of_machine_is_compatible("lenovo,yoga-c630"))
dma_buf = i2c_get_dma_safe_msg_buf(msg, 32);
@@ -384,6 +388,7 @@ static int geni_i2c_rx_one_msg(struct
geni_i2c_dev *gi2c, struct i2c_msg *msg,
if (dma_buf) {
if (gi2c->err)
geni_i2c_rx_fsm_rst(gi2c);
+ gi2c->rx_dma = rx_dma;
geni_se_rx_dma_unprep(se, rx_dma, len);
i2c_put_dma_safe_msg_buf(dma_buf, msg, !gi2c->err);
}
@@ -400,6 +405,7 @@ static int geni_i2c_tx_one_msg(struct geni_i2c_dev
*gi2c, struct i2c_msg *msg,
struct geni_se *se = &gi2c->se;
size_t len = msg->len;
+ gi2c->xfer_len = msg->len;
if (!of_machine_is_compatible("lenovo,yoga-c630"))
dma_buf = i2c_get_dma_safe_msg_buf(msg, 32);
@@ -429,6 +435,7 @@ static int geni_i2c_tx_one_msg(struct
geni_i2c_dev *gi2c, struct i2c_msg *msg,
if (dma_buf) {
if (gi2c->err)
geni_i2c_tx_fsm_rst(gi2c);
+ gi2c->tx_dma = tx_dma;
geni_se_tx_dma_unprep(se, tx_dma, len);
i2c_put_dma_safe_msg_buf(dma_buf, msg, !gi2c->err);
}
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 5/9] arm64: dts: renesas: r8a77961: Add VSP device nodes
On 07.09.2020 5:59, Kuninori Morimoto wrote: From: Kuninori Morimoto This patch adds VSP device nodes for R-Car M3-W+ (r8a77961) SoC. This patch is test on R-Car M3-W+ Salvator-XS board. Was tested? Signed-off-by: Kuninori Morimoto [...] MBR, Sergei ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v1 0/2] video: fbdev: radeonfb: PCI PM framework upgrade and fix-ups.
On Mon, Sep 07, 2020 at 09:55:59AM +0200, Daniel Vetter wrote:
> On Thu, Aug 06, 2020 at 12:52:54PM +0530, Vaibhav Gupta wrote:
> > Linux Kernel Mentee: Remove Legacy Power Management.
> >
> > The original goal of the patch series is to upgrade the power management
> > framework of radeonfb fbdev driver. This has been done by upgrading
> > .suspend()
> > and .resume() callbacks.
> >
> > The upgrade makes sure that the involvement of PCI Core does not change the
> > order of operations executed in a driver. Thus, does not change its
> > behavior.
> >
> > During this process, it was found that "#if defined(CONFIG_PM)" at line
> > 1434 is
> > redundant. This was introduced in the commit
> > 42ddb453a0cd ("radeon: Conditionally compile PM code").
>
> I do wonder whether it wouldn't be better to just outright delete these,
> we have the drm radeon driver for pretty much all the same hardware ...
> -Daniel
>
Hello Daniel,
I don't have any problem in either way. My priority is to get rid of the
legacy .suspend and .resume pointers from "struct pci_driver" . Hence, modifying
every driver that is using them.
Vaibhav Gupta
> >
> >
> >
> > Before 42ddb453a0cd:
> > $ git show 65122f7e80b5:drivers/video/aty/radeon_pm.c | grep -n
> > "#ifdef\|#if\|#else\|#endif\|#elif\|#ifndef"
> >
> > Based on output in terminal:
> >
> > 547:#ifdef CONFIG_PM
> >|-- 959:#ifdef CONFIG_PPC_PMAC
> >|-- 972:#endif
> >|-- 1291:#ifdef CONFIG_PPC_OF
> >|-- 1301:#endif /* CONFIG_PPC_OF */
> >|-- 1943:#ifdef CONFIG_PPC_OF
> >|-- 2206:#if 0 /* Not ready yet */
> >|-- 2508:#endif /* 0 */
> >|-- 2510:#endif /* CONFIG_PPC_OF */
> >|-- 2648:#ifdef CONFIG_PPC_PMAC
> >|-- 2654:#endif /* CONFIG_PPC_PMAC */
> >|-- 2768:#ifdef CONFIG_PPC_PMAC
> >|-- 2774:#endif /* CONFIG_PPC_PMAC */
> >|-- 2791:#ifdef CONFIG_PPC_OF__disabled
> >|-- 2801:#endif /* CONFIG_PPC_OF */
> > 2803:#endif /* CONFIG_PM */
> >
> >
> >
> > After 42ddb453a0cd:
> > $ git show 42ddb453a0cd:drivers/video/aty/radeon_pm.c | grep -n
> > "#ifdef\|#if\|#else\|#endif\|#elif\|#ifndef"
> >
> > Based on output in terminal:
> >
> > 547:#ifdef CONFIG_PM
> >|-- 959:#ifdef CONFIG_PPC_PMAC
> >|-- 972:#endif
> >|-- 1291:#ifdef CONFIG_PPC_OF
> >|-- 1301:#endif /* CONFIG_PPC_OF */
> >|-- 1430:#if defined(CONFIG_PM)
> >|-- 1431:#if defined(CONFIG_X86) ||
> > defined(CONFIG_PPC_PMAC)
> >|-- 1944:#endif
> >|-- 1946:#ifdef CONFIG_PPC_OF
> >|-- 1947:#ifdef CONFIG_PPC_PMAC
> >|-- 2208:#endif
> >|-- 2209:#endif
> >|-- 2211:#if 0 /* Not ready yet */
> >|-- 2513:#endif /* 0 */
> >|-- 2515:#endif /* CONFIG_PPC_OF */
> >|-- 2653:#ifdef CONFIG_PPC_PMAC
> >|-- 2659:#endif /* CONFIG_PPC_PMAC */
> >|-- 2773:#ifdef CONFIG_PPC_PMAC
> >|-- 2779:#endif /* CONFIG_PPC_PMAC */
> >|-- 2796:#ifdef CONFIG_PPC_OF__disabled
> >|-- 2806:#endif /* CONFIG_PPC_OF */
> > 2808:#endif /* CONFIG_PM */
> >
> >
> >
> > This also affected the CONFIG_PPC_OF container (line 1943 at commit
> > 65122f7e80b5)
> >
> > The patch-series fixes it along with PM upgrade.
> >
> > All patches are compile-tested only.
> >
> > Test tools:
> > - Compiler: gcc (GCC) 10.1.0
> > - allmodconfig build: make -j$(nproc) W=1 all
> >
> > Vaibhav Gupta (2):
> > video: fbdev: aty: radeon_pm: remove redundant CONFIG_PM container
> > fbdev: radeonfb:use generic power management
> >
> > drivers/video/fbdev/aty/radeon_base.c | 10 ---
> > drivers/video/fbdev/aty/radeon_pm.c | 38 ---
> > drivers/video/fbdev/aty/radeonfb.h| 3 +--
> > 3 files changed, 35 insertions(+), 16 deletions(-)
> >
> > --
> > 2.27.0
> >
> > ___
> > dri-devel mailing list
> > dri-devel@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/9] dt-bindings: display: renesas: du: Document the r8a77961 bindings
Hi Morimoto-san,
On Mon, Sep 7, 2020 at 4:58 AM Kuninori Morimoto
wrote:
> From: Kuninori Morimoto
>
> Document the R-Car M3-W+ (R8A77961) SoC in the R-Car DU bindings.
>
> Signed-off-by: Kuninori Morimoto
Thanks for your patch!
> --- a/Documentation/devicetree/bindings/display/renesas,du.txt
> +++ b/Documentation/devicetree/bindings/display/renesas,du.txt
> @@ -18,6 +18,7 @@ Required Properties:
> - "renesas,du-r8a7794" for R8A7794 (R-Car E2) compatible DU
> - "renesas,du-r8a7795" for R8A7795 (R-Car H3) compatible DU
> - "renesas,du-r8a7796" for R8A7796 (R-Car M3-W) compatible DU
> +- "renesas,du-r8a77961" for R8A77961 (R-Car M3-W+) compatible DU
> - "renesas,du-r8a77965" for R8A77965 (R-Car M3-N) compatible DU
> - "renesas,du-r8a77970" for R8A77970 (R-Car V3M) compatible DU
> - "renesas,du-r8a77980" for R8A77980 (R-Car V3H) compatible DU
Looks good to me, but please also add an entry to the table below
describing the port mappings.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/9] dt-bindings: display: renesas: dw-hdmi: Add R8A77961 support
On Mon, Sep 7, 2020 at 4:58 AM Kuninori Morimoto
wrote:
> From: Kuninori Morimoto
>
> This patch adds R-Car M3-W+ (R8A77961) SoC bindings.
>
> Signed-off-by: Kuninori Morimoto
Reviewed-by: Geert Uytterhoeven
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 03/11] drm/amd/display: Honor the offset for plane 0.
Hi
[This is an automated email]
This commit has been processed because it contains a -stable tag.
The stable tag indicates that it's relevant for the following trees: all
The bot has tested the following trees: v5.8.7, v5.4.63, v4.19.143, v4.14.196,
v4.9.235, v4.4.235.
v5.8.7: Build OK!
v5.4.63: Build OK!
v4.19.143: Failed to apply! Possible dependencies:
180db303ff46 ("drm/amd/display: Add below the range support for FreeSync")
7df7e505e82a ("drm/amd/display: Set requested plane state DCC params for
GFX9")
8c3db1284a01 ("drm/amdgpu: fill in
amdgpu_dm_remove_sink_from_freesync_module")
98e6436d3af5 ("drm/amd/display: Refactor FreeSync module")
c1ee92f94ce3 ("drm/amd: Add abm level drm property")
d999853e60a0 ("drm/amd/display: Guard against null stream dereference in do
flip")
e5d0170e5644 ("drm/amd/display: Use non-deprecated vblank handler")
v4.14.196: Failed to apply! Possible dependencies:
1b0c0f9dc5ca ("drm/amdgpu: move userptr BOs to CPU domain during CS v2")
3fe89771cb0a ("drm/amdgpu: stop reserving the BO in the MMU callback v3")
4562236b3bc0 ("drm/amd/dc: Add dc display driver (v2)")
60de1c1740f3 ("drm/amdgpu: use a rw_semaphore for MMU notifiers")
7df7e505e82a ("drm/amd/display: Set requested plane state DCC params for
GFX9")
9a18999640fa ("drm/amdgpu: move MMU notifier related defines to
amdgpu_mn.h")
9cca0b8e5df0 ("drm/amdgpu: move amdgpu_cs_sysvm_access_required into
find_mapping")
a216ab09955d ("drm/amdgpu: fix userptr put_page handling")
b72cf4fca2bb ("drm/amdgpu: move taking mmap_sem into get_user_pages v2")
ca666a3c298f ("drm/amdgpu: stop using BO status for user pages")
e7b07ceef2a6 ("drm/amd/display: Merge amdgpu_dm_types and amdgpu_dm")
v4.9.235: Failed to apply! Possible dependencies:
1cec20f0ea0e ("dma-buf: Restart reservation_object_wait_timeout_rcu() after
writes")
248a1d6f1ac4 ("drm/amd: fix include notation and remove -Iinclude/drm flag")
4562236b3bc0 ("drm/amd/dc: Add dc display driver (v2)")
78010cd9736e ("dma-buf/fence: add an lockdep_assert_held()")
7df7e505e82a ("drm/amd/display: Set requested plane state DCC params for
GFX9")
e7b07ceef2a6 ("drm/amd/display: Merge amdgpu_dm_types and amdgpu_dm")
f54d1867005c ("dma-buf: Rename struct fence to dma_fence")
fedf54132d24 ("dma-buf: Restart reservation_object_get_fences_rcu() after
writes")
v4.4.235: Failed to apply! Possible dependencies:
0f477c6dea70 ("staging/android/sync: add sync_fence_create_dma")
1f7371b2a5fa ("drm/amd/powerplay: add basic powerplay framework")
248a1d6f1ac4 ("drm/amd: fix include notation and remove -Iinclude/drm flag")
288912cb95d1 ("drm/amdgpu: use $(src) in Makefile (v2)")
375fb53ec1be ("staging: android: replace explicit NULL comparison")
395dec6f6bc5 ("Documentation: add doc for sync_file_get_fence()")
4325198180e5 ("drm/amdgpu: remove GART page addr array")
4562236b3bc0 ("drm/amd/dc: Add dc display driver (v2)")
62304fb1fc08 ("dma-buf/sync_file: de-stage sync_file")
7df7e505e82a ("drm/amd/display: Set requested plane state DCC params for
GFX9")
a1d29476d666 ("drm/amdgpu: optionally enable GART debugfs file")
a8fe58cec351 ("drm/amd: add ACP driver support")
b70f014d58b9 ("drm/amdgpu: change default sched jobs to 32")
c784c82a3fd6 ("Documentation: add Sync File doc")
d4cab38e153d ("staging/android: prepare sync_file for de-staging")
d7fdb0ae9d11 ("staging/android: rename sync_fence to sync_file")
e7b07ceef2a6 ("drm/amd/display: Merge amdgpu_dm_types and amdgpu_dm")
f54d1867005c ("dma-buf: Rename struct fence to dma_fence")
fac8434dab96 ("Documentation: Fix some grammar mistakes in sync_file.txt")
fdba11f4079e ("drm/amdgpu: move all Kconfig options to amdgpu/Kconfig")
NOTE: The patch will not be queued to stable trees until it is upstream.
How should we proceed with this patch?
--
Thanks
Sasha
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v10 30/30] videobuf2: use sgtable-based scatterlist wrappers
On Mon, Sep 7, 2020 at 4:02 PM Marek Szyprowski
wrote:
>
> Hi Tomasz,
>
> On 07.09.2020 15:07, Tomasz Figa wrote:
> > On Fri, Sep 4, 2020 at 3:35 PM Marek Szyprowski
> > wrote:
> >> Use recently introduced common wrappers operating directly on the struct
> >> sg_table objects and scatterlist page iterators to make the code a bit
> >> more compact, robust, easier to follow and copy/paste safe.
> >>
> >> No functional change, because the code already properly did all the
> >> scatterlist related calls.
> >>
> >> Signed-off-by: Marek Szyprowski
> >> Reviewed-by: Robin Murphy
> >> ---
> >> .../common/videobuf2/videobuf2-dma-contig.c | 34 ---
> >> .../media/common/videobuf2/videobuf2-dma-sg.c | 32 +++--
> >> .../common/videobuf2/videobuf2-vmalloc.c | 12 +++
> >> 3 files changed, 31 insertions(+), 47 deletions(-)
> >>
> > Thanks for the patch! Please see my comments inline.
> >
> >> diff --git a/drivers/media/common/videobuf2/videobuf2-dma-contig.c
> >> b/drivers/media/common/videobuf2/videobuf2-dma-contig.c
> >> index ec3446cc45b8..1b242d844dde 100644
> >> --- a/drivers/media/common/videobuf2/videobuf2-dma-contig.c
> >> +++ b/drivers/media/common/videobuf2/videobuf2-dma-contig.c
> >> @@ -58,10 +58,10 @@ static unsigned long vb2_dc_get_contiguous_size(struct
> >> sg_table *sgt)
> >> unsigned int i;
> >> unsigned long size = 0;
> >>
> >> - for_each_sg(sgt->sgl, s, sgt->nents, i) {
> >> + for_each_sgtable_dma_sg(sgt, s, i) {
> >> if (sg_dma_address(s) != expected)
> >> break;
> >> - expected = sg_dma_address(s) + sg_dma_len(s);
> >> + expected += sg_dma_len(s);
> >> size += sg_dma_len(s);
> >> }
> >> return size;
> >> @@ -103,8 +103,7 @@ static void vb2_dc_prepare(void *buf_priv)
> >> if (!sgt)
> >> return;
> >>
> >> - dma_sync_sg_for_device(buf->dev, sgt->sgl, sgt->orig_nents,
> >> - buf->dma_dir);
> >> + dma_sync_sgtable_for_device(buf->dev, sgt, buf->dma_dir);
> >> }
> >>
> >> static void vb2_dc_finish(void *buf_priv)
> >> @@ -115,7 +114,7 @@ static void vb2_dc_finish(void *buf_priv)
> >> if (!sgt)
> >> return;
> >>
> >> - dma_sync_sg_for_cpu(buf->dev, sgt->sgl, sgt->orig_nents,
> >> buf->dma_dir);
> >> + dma_sync_sgtable_for_cpu(buf->dev, sgt, buf->dma_dir);
> >> }
> >>
> >> /*/
> >> @@ -275,8 +274,8 @@ static void vb2_dc_dmabuf_ops_detach(struct dma_buf
> >> *dbuf,
> >> * memory locations do not require any explicit cache
> >> * maintenance prior or after being used by the device.
> >> */
> >> - dma_unmap_sg_attrs(db_attach->dev, sgt->sgl,
> >> sgt->orig_nents,
> >> - attach->dma_dir,
> >> DMA_ATTR_SKIP_CPU_SYNC);
> >> + dma_unmap_sgtable(db_attach->dev, sgt, attach->dma_dir,
> >> + DMA_ATTR_SKIP_CPU_SYNC);
> >> sg_free_table(sgt);
> >> kfree(attach);
> >> db_attach->priv = NULL;
> >> @@ -301,8 +300,8 @@ static struct sg_table *vb2_dc_dmabuf_ops_map(
> >>
> >> /* release any previous cache */
> >> if (attach->dma_dir != DMA_NONE) {
> >> - dma_unmap_sg_attrs(db_attach->dev, sgt->sgl,
> >> sgt->orig_nents,
> >> - attach->dma_dir,
> >> DMA_ATTR_SKIP_CPU_SYNC);
> >> + dma_unmap_sgtable(db_attach->dev, sgt, attach->dma_dir,
> >> + DMA_ATTR_SKIP_CPU_SYNC);
> >> attach->dma_dir = DMA_NONE;
> >> }
> >>
> >> @@ -310,9 +309,8 @@ static struct sg_table *vb2_dc_dmabuf_ops_map(
> >> * mapping to the client with new direction, no cache sync
> >> * required see comment in vb2_dc_dmabuf_ops_detach()
> >> */
> >> - sgt->nents = dma_map_sg_attrs(db_attach->dev, sgt->sgl,
> >> sgt->orig_nents,
> >> - dma_dir, DMA_ATTR_SKIP_CPU_SYNC);
> >> - if (!sgt->nents) {
> >> + if (dma_map_sgtable(db_attach->dev, sgt, dma_dir,
> >> + DMA_ATTR_SKIP_CPU_SYNC)) {
> >> pr_err("failed to map scatterlist\n");
> >> mutex_unlock(lock);
> >> return ERR_PTR(-EIO);
> > As opposed to dma_map_sg_attrs(), dma_map_sgtable() now returns an
> > error code on its own. Is it expected to ignore it and return -EIO?
>
> Those errors are more or less propagated to userspace and -EIO has been
> already widely documented in V4L2 documentation as the error code for
> the most of the V4L2 ioctls. I don't want to change it. A possible
> -EINVAL returned from dma_map_sgtable() was just one of the 'generic'
> error codes, not very descriptive in that case. Prob
Re: [PATCH 5/9] arm64: dts: renesas: r8a77961: Add VSP device nodes
Hi Morimoto-san,
On 07/09/2020 03:59, Kuninori Morimoto wrote:
>
> From: Kuninori Morimoto
>
> This patch adds VSP device nodes for R-Car M3-W+ (r8a77961) SoC.
> This patch is test on R-Car M3-W+ Salvator-XS board.
>
> Signed-off-by: Kuninori Morimoto
> ---
> arch/arm64/boot/dts/renesas/r8a77961.dtsi | 55 +++
> 1 file changed, 55 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/renesas/r8a77961.dtsi
> b/arch/arm64/boot/dts/renesas/r8a77961.dtsi
> index fe0db11b9cb9..c2a6918ed5e6 100644
> --- a/arch/arm64/boot/dts/renesas/r8a77961.dtsi
> +++ b/arch/arm64/boot/dts/renesas/r8a77961.dtsi
> @@ -2056,6 +2056,61 @@ fcpvd2: fcp@fea37000 {
> iommus = <&ipmmu_vi0 10>;
> };
The FCP's added are:
fcpf0: fcp@fe95 {
fcpf1: fcp@fe951000 {
fcpvb0: fcp@fe96f000 {
fcpvb1: fcp@fe92f000 {
fcpvi0: fcp@fe9af000 {
fcpvi1: fcp@fe9bf000 {
fcpvd0: fcp@fea27000 {
fcpvd1: fcp@fea2f000 {
fcpvd2: fcp@fea37000 {
So indeed, the first fcpf0 comes before fe96.
Do we keep the items grouped by the first occurrence? or sort the nodes
based on address?
for some reason I thought we were ordering based on address, but I see
other situations where we group too - so I'm confused (and wishing there
was an automatic tool to get the sorting correct without fuss).
Is there a set policy?
--
Kieran
> + vspb: vsp@fe96 {
> + compatible = "renesas,vsp2";
> + reg = <0 0xfe96 0 0x8000>;
> + interrupts = ;
> + clocks = <&cpg CPG_MOD 626>;
> + power-domains = <&sysc R8A77961_PD_A3VC>;
> + resets = <&cpg 626>;
> +
> + renesas,fcp = <&fcpvb0>;
> + };
> +
> + vspd0: vsp@fea2 {
> + compatible = "renesas,vsp2";
> + reg = <0 0xfea2 0 0x5000>;
> + interrupts = ;
> + clocks = <&cpg CPG_MOD 623>;
> + power-domains = <&sysc R8A77961_PD_ALWAYS_ON>;
> + resets = <&cpg 623>;
> +
> + renesas,fcp = <&fcpvd0>;
> + };
> +
> + vspd1: vsp@fea28000 {
> + compatible = "renesas,vsp2";
> + reg = <0 0xfea28000 0 0x5000>;
> + interrupts = ;
> + clocks = <&cpg CPG_MOD 622>;
> + power-domains = <&sysc R8A77961_PD_ALWAYS_ON>;
> + resets = <&cpg 622>;
> +
> + renesas,fcp = <&fcpvd1>;
> + };
> +
> + vspd2: vsp@fea3 {
> + compatible = "renesas,vsp2";
> + reg = <0 0xfea3 0 0x5000>;
> + interrupts = ;
> + clocks = <&cpg CPG_MOD 621>;
> + power-domains = <&sysc R8A77961_PD_ALWAYS_ON>;
> + resets = <&cpg 621>;
> +
> + renesas,fcp = <&fcpvd2>;
> + };
> +
> + vspi0: vsp@fe9a {
> + compatible = "renesas,vsp2";
> + reg = <0 0xfe9a 0 0x8000>;
> + interrupts = ;
> + clocks = <&cpg CPG_MOD 631>;
> + power-domains = <&sysc R8A77961_PD_A3VC>;
> + resets = <&cpg 631>;
> +
> + renesas,fcp = <&fcpvi0>;
> + };
> +
> csi20: csi2@fea8 {
> reg = <0 0xfea8 0 0x1>;
> /* placeholder */
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm: mxsfb: check framebuffer pitch
The lcdif IP does not support a framebuffer pitch (stride) other than
the CRTC width. Check for equality and reject the state otherwise.
This prevents a distorted picture when using 640x800 and running the
Mesa graphics stack. Mesa tires to use a cache aligned stride, which
leads at that particular resolution to width != stride. Currently
Mesa has no fallback behavior, but rejecting this configuration allows
userspace to handle the issue correctly.
Signed-off-by: Stefan Agner
---
drivers/gpu/drm/mxsfb/mxsfb_kms.c | 22 ++
1 file changed, 18 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/mxsfb/mxsfb_kms.c
b/drivers/gpu/drm/mxsfb/mxsfb_kms.c
index b721b8b262ce..79aa14027f91 100644
--- a/drivers/gpu/drm/mxsfb/mxsfb_kms.c
+++ b/drivers/gpu/drm/mxsfb/mxsfb_kms.c
@@ -403,14 +403,28 @@ static int mxsfb_plane_atomic_check(struct drm_plane
*plane,
{
struct mxsfb_drm_private *mxsfb = to_mxsfb_drm_private(plane->dev);
struct drm_crtc_state *crtc_state;
+ unsigned int pitch;
+ int ret;
crtc_state = drm_atomic_get_new_crtc_state(plane_state->state,
&mxsfb->crtc);
- return drm_atomic_helper_check_plane_state(plane_state, crtc_state,
- DRM_PLANE_HELPER_NO_SCALING,
- DRM_PLANE_HELPER_NO_SCALING,
- false, true);
+ ret = drm_atomic_helper_check_plane_state(plane_state, crtc_state,
+ DRM_PLANE_HELPER_NO_SCALING,
+ DRM_PLANE_HELPER_NO_SCALING,
+ false, true);
+ if (ret || !plane_state->visible)
+ return ret;
+
+ pitch = crtc_state->mode.hdisplay *
+ plane_state->fb->format->cpp[0];
+ if (plane_state->fb->pitches[0] != pitch) {
+ dev_err(plane->dev->dev,
+ "Invalid pitch: fb and crtc widths must be the same");
+ return -EINVAL;
+ }
+
+ return 0;
}
static void mxsfb_plane_primary_atomic_update(struct drm_plane *plane,
--
2.28.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: mxsfb: check framebuffer pitch
Hi Stefan,
Thank you for the patch.
On Mon, Sep 07, 2020 at 06:03:43PM +0200, Stefan Agner wrote:
> The lcdif IP does not support a framebuffer pitch (stride) other than
> the CRTC width. Check for equality and reject the state otherwise.
>
> This prevents a distorted picture when using 640x800 and running the
> Mesa graphics stack. Mesa tires to use a cache aligned stride, which
s/tires/tries/
> leads at that particular resolution to width != stride. Currently
> Mesa has no fallback behavior, but rejecting this configuration allows
> userspace to handle the issue correctly.
I'm increasingly impressed by how featureful this IP core is :-)
> Signed-off-by: Stefan Agner
> ---
> drivers/gpu/drm/mxsfb/mxsfb_kms.c | 22 ++
> 1 file changed, 18 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/mxsfb/mxsfb_kms.c
> b/drivers/gpu/drm/mxsfb/mxsfb_kms.c
> index b721b8b262ce..79aa14027f91 100644
> --- a/drivers/gpu/drm/mxsfb/mxsfb_kms.c
> +++ b/drivers/gpu/drm/mxsfb/mxsfb_kms.c
> @@ -403,14 +403,28 @@ static int mxsfb_plane_atomic_check(struct drm_plane
> *plane,
> {
> struct mxsfb_drm_private *mxsfb = to_mxsfb_drm_private(plane->dev);
> struct drm_crtc_state *crtc_state;
> + unsigned int pitch;
> + int ret;
>
> crtc_state = drm_atomic_get_new_crtc_state(plane_state->state,
> &mxsfb->crtc);
>
> - return drm_atomic_helper_check_plane_state(plane_state, crtc_state,
> -DRM_PLANE_HELPER_NO_SCALING,
> -DRM_PLANE_HELPER_NO_SCALING,
> -false, true);
> + ret = drm_atomic_helper_check_plane_state(plane_state, crtc_state,
> + DRM_PLANE_HELPER_NO_SCALING,
> + DRM_PLANE_HELPER_NO_SCALING,
> + false, true);
> + if (ret || !plane_state->visible)
Would it be more explict to check for !plane_state->fb ? Otherwise I'll
have to verify that !fb always implies !visible :-)
> + return ret;
> +
> + pitch = crtc_state->mode.hdisplay *
> + plane_state->fb->format->cpp[0];
This holds on a single line.
> + if (plane_state->fb->pitches[0] != pitch) {
> + dev_err(plane->dev->dev,
> + "Invalid pitch: fb and crtc widths must be the same");
I'd turn this into a dev_dbg(), printing error messages to the kernel
log in response to user-triggered conditions is a bit too verbose and
could flood the log.
Wouldn't it be best to catch this issue when creating the framebuffer ?
> + return -EINVAL;
> + }
> +
> + return 0;
> }
>
> static void mxsfb_plane_primary_atomic_update(struct drm_plane *plane,
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.8 50/53] drm/amdgpu: Fix bug in reporting voltage for CIK
From: Sandeep Raghuraman [ Upstream commit d98299885c9ea140c1108545186593deba36c4ac ] On my R9 390, the voltage was reported as a constant 1000 mV. This was due to a bug in smu7_hwmgr.c, in the smu7_read_sensor() function, where some magic constants were used in a condition, to determine whether the voltage should be read from PLANE2_VID or PLANE1_VID. The VDDC mask was incorrectly used, instead of the VDDGFX mask. This patch changes the code to use the correct defined constants (and apply the correct bitshift), thus resulting in correct voltage reporting. Signed-off-by: Sandeep Raghuraman Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin --- drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c b/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c index 753cb2cf6b77e..3adf9c1dfdbb0 100644 --- a/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c +++ b/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c @@ -3587,7 +3587,8 @@ static int smu7_read_sensor(struct pp_hwmgr *hwmgr, int idx, case AMDGPU_PP_SENSOR_GPU_POWER: return smu7_get_gpu_power(hwmgr, (uint32_t *)value); case AMDGPU_PP_SENSOR_VDDGFX: - if ((data->vr_config & 0xff) == 0x2) + if ((data->vr_config & VRCONF_VDDGFX_MASK) == + (VR_SVI2_PLANE_2 << VRCONF_VDDGFX_SHIFT)) val_vid = PHM_READ_INDIRECT_FIELD(hwmgr->device, CGS_IND_REG__SMC, PWR_SVI2_STATUS, PLANE2_VID); else -- 2.25.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 4.19 24/26] drm/amdgpu: Fix bug in reporting voltage for CIK
From: Sandeep Raghuraman [ Upstream commit d98299885c9ea140c1108545186593deba36c4ac ] On my R9 390, the voltage was reported as a constant 1000 mV. This was due to a bug in smu7_hwmgr.c, in the smu7_read_sensor() function, where some magic constants were used in a condition, to determine whether the voltage should be read from PLANE2_VID or PLANE1_VID. The VDDC mask was incorrectly used, instead of the VDDGFX mask. This patch changes the code to use the correct defined constants (and apply the correct bitshift), thus resulting in correct voltage reporting. Signed-off-by: Sandeep Raghuraman Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin --- drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c b/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c index 219440bebd052..72c0a2ae2dd4f 100644 --- a/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c +++ b/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c @@ -3566,7 +3566,8 @@ static int smu7_read_sensor(struct pp_hwmgr *hwmgr, int idx, case AMDGPU_PP_SENSOR_GPU_POWER: return smu7_get_gpu_power(hwmgr, (uint32_t *)value); case AMDGPU_PP_SENSOR_VDDGFX: - if ((data->vr_config & 0xff) == 0x2) + if ((data->vr_config & VRCONF_VDDGFX_MASK) == + (VR_SVI2_PLANE_2 << VRCONF_VDDGFX_SHIFT)) val_vid = PHM_READ_INDIRECT_FIELD(hwmgr->device, CGS_IND_REG__SMC, PWR_SVI2_STATUS, PLANE2_VID); else -- 2.25.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.4 41/43] drm/amdgpu: Fix bug in reporting voltage for CIK
From: Sandeep Raghuraman [ Upstream commit d98299885c9ea140c1108545186593deba36c4ac ] On my R9 390, the voltage was reported as a constant 1000 mV. This was due to a bug in smu7_hwmgr.c, in the smu7_read_sensor() function, where some magic constants were used in a condition, to determine whether the voltage should be read from PLANE2_VID or PLANE1_VID. The VDDC mask was incorrectly used, instead of the VDDGFX mask. This patch changes the code to use the correct defined constants (and apply the correct bitshift), thus resulting in correct voltage reporting. Signed-off-by: Sandeep Raghuraman Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin --- drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c b/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c index e6da53e9c3f46..3a2a1dc9a786a 100644 --- a/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c +++ b/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c @@ -3575,7 +3575,8 @@ static int smu7_read_sensor(struct pp_hwmgr *hwmgr, int idx, case AMDGPU_PP_SENSOR_GPU_POWER: return smu7_get_gpu_power(hwmgr, (uint32_t *)value); case AMDGPU_PP_SENSOR_VDDGFX: - if ((data->vr_config & 0xff) == 0x2) + if ((data->vr_config & VRCONF_VDDGFX_MASK) == + (VR_SVI2_PLANE_2 << VRCONF_VDDGFX_SHIFT)) val_vid = PHM_READ_INDIRECT_FIELD(hwmgr->device, CGS_IND_REG__SMC, PWR_SVI2_STATUS, PLANE2_VID); else -- 2.25.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 208997] WARNING: CPU: 3 PID: 1633 at drivers/gpu/drm/drm_modeset_lock.c
https://bugzilla.kernel.org/show_bug.cgi?id=208997 Martin (martin...@gmx.com) changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |CODE_FIX --- Comment #2 from Martin (martin...@gmx.com) --- After upgrading to 5.8.6 I don't see the messages any more. Cheers. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
