[Bug 110363] done
https://bugs.freedesktop.org/show_bug.cgi?id=110363 rj changed: What|Removed |Added CC||rohanjhaveri...@gmail.com Assignee|dri-devel@lists.freedesktop |rohanjhaveri...@gmail.com |.org| --- Comment #1 from rj --- Created attachment 143907 --> https://bugs.freedesktop.org/attachment.cgi?id=143907&action=edit voucher validation not work -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 12/15] drm/vboxvideo: Convert vboxvideo driver to |struct drm_gem_ttm_object|
Hi,
On 08-04-19 11:21, Thomas Zimmermann wrote:
This patch replaces |struct vbox_bo| and its helpers with the generic
implementation of |struct drm_gem_ttm_object|. The only change in
semantics is that &ttm_bo_driver.verify_access() now does the actual
verification.
Signed-off-by: Thomas Zimmermann
Nice cleanup, thank you, patch looks good to me:
Reviewed-by: Hans de Goede
Regards,
Hans
---
drivers/gpu/drm/vboxvideo/Kconfig | 1 +
drivers/gpu/drm/vboxvideo/vbox_drv.c | 5 +-
drivers/gpu/drm/vboxvideo/vbox_drv.h | 58 +--
drivers/gpu/drm/vboxvideo/vbox_fb.c | 22 +--
drivers/gpu/drm/vboxvideo/vbox_main.c | 70 +---
drivers/gpu/drm/vboxvideo/vbox_mode.c | 36 +++--
drivers/gpu/drm/vboxvideo/vbox_ttm.c | 223 +-
7 files changed, 45 insertions(+), 370 deletions(-)
diff --git a/drivers/gpu/drm/vboxvideo/Kconfig
b/drivers/gpu/drm/vboxvideo/Kconfig
index 1f4182e2e980..c1ca87df81df 100644
--- a/drivers/gpu/drm/vboxvideo/Kconfig
+++ b/drivers/gpu/drm/vboxvideo/Kconfig
@@ -3,6 +3,7 @@ config DRM_VBOXVIDEO
depends on DRM && X86 && PCI
select DRM_KMS_HELPER
select DRM_TTM
+ select DRM_GEM_TTM_HELPER
select GENERIC_ALLOCATOR
help
This is a KMS driver for the virtual Graphics Card used in
diff --git a/drivers/gpu/drm/vboxvideo/vbox_drv.c
b/drivers/gpu/drm/vboxvideo/vbox_drv.c
index fb6a0f0b8167..75b165386935 100644
--- a/drivers/gpu/drm/vboxvideo/vbox_drv.c
+++ b/drivers/gpu/drm/vboxvideo/vbox_drv.c
@@ -215,9 +215,10 @@ static struct drm_driver driver = {
.minor = DRIVER_MINOR,
.patchlevel = DRIVER_PATCHLEVEL,
- .gem_free_object_unlocked = vbox_gem_free_object,
+ .gem_free_object_unlocked =
+ drm_gem_ttm_driver_gem_free_object_unlocked,
.dumb_create = vbox_dumb_create,
- .dumb_map_offset = vbox_dumb_mmap_offset,
+ .dumb_map_offset = drm_gem_ttm_driver_dumb_mmap_offset,
.prime_handle_to_fd = drm_gem_prime_handle_to_fd,
.prime_fd_to_handle = drm_gem_prime_fd_to_handle,
.gem_prime_export = drm_gem_prime_export,
diff --git a/drivers/gpu/drm/vboxvideo/vbox_drv.h
b/drivers/gpu/drm/vboxvideo/vbox_drv.h
index ece31f395540..7db4e961805d 100644
--- a/drivers/gpu/drm/vboxvideo/vbox_drv.h
+++ b/drivers/gpu/drm/vboxvideo/vbox_drv.h
@@ -18,6 +18,7 @@
#include
#include
#include
+#include
#include
#include
@@ -170,73 +171,16 @@ int vboxfb_create(struct drm_fb_helper *helper,
struct drm_fb_helper_surface_size *sizes);
void vbox_fbdev_fini(struct vbox_private *vbox);
-struct vbox_bo {
- struct ttm_buffer_object bo;
- struct ttm_placement placement;
- struct ttm_bo_kmap_obj kmap;
- struct drm_gem_object gem;
- struct ttm_place placements[3];
- int pin_count;
-};
-
-#define gem_to_vbox_bo(gobj) container_of((gobj), struct vbox_bo, gem)
-
-static inline struct vbox_bo *vbox_bo(struct ttm_buffer_object *bo)
-{
- return container_of(bo, struct vbox_bo, bo);
-}
-
-#define to_vbox_obj(x) container_of(x, struct vbox_gem_object, base)
-
-static inline u64 vbox_bo_gpu_offset(struct vbox_bo *bo)
-{
- return bo->bo.offset;
-}
-
int vbox_dumb_create(struct drm_file *file,
struct drm_device *dev,
struct drm_mode_create_dumb *args);
-void vbox_gem_free_object(struct drm_gem_object *obj);
-int vbox_dumb_mmap_offset(struct drm_file *file,
- struct drm_device *dev,
- u32 handle, u64 *offset);
-
int vbox_mm_init(struct vbox_private *vbox);
void vbox_mm_fini(struct vbox_private *vbox);
-int vbox_bo_create(struct vbox_private *vbox, int size, int align,
- u32 flags, struct vbox_bo **pvboxbo);
-
int vbox_gem_create(struct vbox_private *vbox,
u32 size, bool iskernel, struct drm_gem_object **obj);
-
-int vbox_bo_pin(struct vbox_bo *bo, u32 pl_flag);
-int vbox_bo_unpin(struct vbox_bo *bo);
-
-static inline int vbox_bo_reserve(struct vbox_bo *bo, bool no_wait)
-{
- int ret;
-
- ret = ttm_bo_reserve(&bo->bo, true, no_wait, NULL);
- if (ret) {
- if (ret != -ERESTARTSYS && ret != -EBUSY)
- DRM_ERROR("reserve failed %p\n", bo);
- return ret;
- }
- return 0;
-}
-
-static inline void vbox_bo_unreserve(struct vbox_bo *bo)
-{
- ttm_bo_unreserve(&bo->bo);
-}
-
-void vbox_ttm_placement(struct vbox_bo *bo, int domain);
-int vbox_bo_push_sysram(struct vbox_bo *bo);
int vbox_mmap(struct file *filp, struct vm_area_struct *vma);
-void *vbox_bo_kmap(struct vbox_bo *bo);
-void vbox_bo_kunmap(struct vbox_bo *bo);
/* vbox_prime.c */
int vbox_gem_prime_pin(struct drm_gem_object *obj);
diff --git a/drivers/gpu/drm/vboxvideo/vbox_fb.c
b/drivers/gpu/drm/vboxvideo/vbox_fb.c
index b724fe7c0c30..1cf0c6bd58b9 100644
--- a/drivers/gpu/drm/vboxvideo/vbox_
Re: [PATCH 13/15] drm/vboxvideo: Convert vboxvideo driver to Simple TTM
Hi,
On 08-04-19 11:21, Thomas Zimmermann wrote:
Signed-off-by: Thomas Zimmermann
Patch looks good to me (although perhaps it needs a commit msg):
Reviewed-by: Hans de Goede
Regards,
Hans
---
drivers/gpu/drm/vboxvideo/Kconfig| 1 +
drivers/gpu/drm/vboxvideo/vbox_drv.h | 6 +-
drivers/gpu/drm/vboxvideo/vbox_ttm.c | 123 ++-
3 files changed, 12 insertions(+), 118 deletions(-)
diff --git a/drivers/gpu/drm/vboxvideo/Kconfig
b/drivers/gpu/drm/vboxvideo/Kconfig
index c1ca87df81df..e29df360978d 100644
--- a/drivers/gpu/drm/vboxvideo/Kconfig
+++ b/drivers/gpu/drm/vboxvideo/Kconfig
@@ -4,6 +4,7 @@ config DRM_VBOXVIDEO
select DRM_KMS_HELPER
select DRM_TTM
select DRM_GEM_TTM_HELPER
+ select DRM_SIMPLE_TTM_HELPER
select GENERIC_ALLOCATOR
help
This is a KMS driver for the virtual Graphics Card used in
diff --git a/drivers/gpu/drm/vboxvideo/vbox_drv.h
b/drivers/gpu/drm/vboxvideo/vbox_drv.h
index 7db4e961805d..d4cfcc6339ef 100644
--- a/drivers/gpu/drm/vboxvideo/vbox_drv.h
+++ b/drivers/gpu/drm/vboxvideo/vbox_drv.h
@@ -20,6 +20,8 @@
#include
#include
+#include
+
#include
#include
#include
@@ -78,9 +80,7 @@ struct vbox_private {
int fb_mtrr;
- struct {
- struct ttm_bo_device bdev;
- } ttm;
+ struct drm_simple_ttm ttm;
struct mutex hw_mutex; /* protects modeset and accel/vbva accesses */
struct work_struct hotplug_work;
diff --git a/drivers/gpu/drm/vboxvideo/vbox_ttm.c
b/drivers/gpu/drm/vboxvideo/vbox_ttm.c
index a1d64e1ea90c..115ec44636ab 100644
--- a/drivers/gpu/drm/vboxvideo/vbox_ttm.c
+++ b/drivers/gpu/drm/vboxvideo/vbox_ttm.c
@@ -11,128 +11,25 @@
#include
#include "vbox_drv.h"
-static inline struct vbox_private *vbox_bdev(struct ttm_bo_device *bd)
-{
- return container_of(bd, struct vbox_private, ttm.bdev);
-}
-
-static int
-vbox_bo_init_mem_type(struct ttm_bo_device *bdev, u32 type,
- struct ttm_mem_type_manager *man)
-{
- switch (type) {
- case TTM_PL_SYSTEM:
- man->flags = TTM_MEMTYPE_FLAG_MAPPABLE;
- man->available_caching = TTM_PL_MASK_CACHING;
- man->default_caching = TTM_PL_FLAG_CACHED;
- break;
- case TTM_PL_VRAM:
- man->func = &ttm_bo_manager_func;
- man->flags = TTM_MEMTYPE_FLAG_FIXED | TTM_MEMTYPE_FLAG_MAPPABLE;
- man->available_caching = TTM_PL_FLAG_UNCACHED | TTM_PL_FLAG_WC;
- man->default_caching = TTM_PL_FLAG_WC;
- break;
- default:
- DRM_ERROR("Unsupported memory type %u\n", (unsigned int)type);
- return -EINVAL;
- }
-
- return 0;
-}
-
-static int vbox_ttm_io_mem_reserve(struct ttm_bo_device *bdev,
- struct ttm_mem_reg *mem)
-{
- struct ttm_mem_type_manager *man = &bdev->man[mem->mem_type];
- struct vbox_private *vbox = vbox_bdev(bdev);
-
- mem->bus.addr = NULL;
- mem->bus.offset = 0;
- mem->bus.size = mem->num_pages << PAGE_SHIFT;
- mem->bus.base = 0;
- mem->bus.is_iomem = false;
- if (!(man->flags & TTM_MEMTYPE_FLAG_MAPPABLE))
- return -EINVAL;
- switch (mem->mem_type) {
- case TTM_PL_SYSTEM:
- /* system memory */
- return 0;
- case TTM_PL_VRAM:
- mem->bus.offset = mem->start << PAGE_SHIFT;
- mem->bus.base = pci_resource_start(vbox->ddev.pdev, 0);
- mem->bus.is_iomem = true;
- break;
- default:
- return -EINVAL;
- }
- return 0;
-}
-
-static void vbox_ttm_io_mem_free(struct ttm_bo_device *bdev,
-struct ttm_mem_reg *mem)
-{
-}
-
-static void vbox_ttm_backend_destroy(struct ttm_tt *tt)
-{
- ttm_tt_fini(tt);
- kfree(tt);
-}
-
-static struct ttm_backend_func vbox_tt_backend_func = {
- .destroy = &vbox_ttm_backend_destroy,
-};
-
-static struct ttm_tt *vbox_ttm_tt_create(struct ttm_buffer_object *bo,
-u32 page_flags)
-{
- struct ttm_tt *tt;
-
- tt = kzalloc(sizeof(*tt), GFP_KERNEL);
- if (!tt)
- return NULL;
-
- tt->func = &vbox_tt_backend_func;
- if (ttm_tt_init(tt, bo, page_flags)) {
- kfree(tt);
- return NULL;
- }
-
- return tt;
-}
-
-static struct ttm_bo_driver vbox_bo_driver = {
- .ttm_tt_create = vbox_ttm_tt_create,
- .init_mem_type = vbox_bo_init_mem_type,
- .eviction_valuable = ttm_bo_eviction_valuable,
+static const struct drm_simple_ttm_funcs vbox_simple_ttm_funcs = {
.evict_flags = drm_gem_ttm_bo_driver_evict_flags,
- .verify_access = drm_gem_ttm_bo_driver_verify_access,
- .io_mem_reserve = &vbox_ttm_io_mem_reserve,
- .io_mem_free = &vbox_ttm_io_mem_free,
+
Re: [PATCH 00/15] Share TTM code among framebuffer drivers
Hi, > If not for TTM, what would be the alternative? One VMA manager per > memory region per device? Depends pretty much on the device. The cirrus is a display device with only 4 MB of vram. You can't fit much in there. A single 1024x768 @ 24bpp framebuffer needs more 50% of the video memory already. Which is why the cirrus driver (before the rewrite) had to migrate buffers from/to vram on every page flip[1]. Which is one[2] of the reasons why cirrus (after rewrite) doesn't ttm-manage the vram any more. gem objects are managed with the shmem helpers instead and the active framebuffer is blitted to vram. The qemu stdvga (bochs driver) has 16 MB vram by default and can be configured to have up to 256 MB. Plenty of room even for multiple 4k framebuffers if needed. So for the bochs driver all the ttm bo migration logic is not needed, it could just store everything in vram. A set of drm_gem_vram_* helpers would do the job for bochs. I'd expect the same applies to the vbox driver. Dunno about the other drm drivers and the fbdev drivers you plan to migrate over. cheers, Gerd [1] Note: The page-flip migration logic is present in some of the other drivers too, not sure whenever they actually need that due to being low on vram too or whenever they just copied the old cirrus code ... [2] The other reason is that this allow to convert formats at blit time, which helps to deal with some cirrus hardware limitations. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 08/12] arm64: dts: allwinner: h6: Add MMC1 pins
Hi,
On Tue, Apr 09, 2019 at 12:41:05AM +0200, Ondřej Jirman wrote:
> On Mon, Apr 08, 2019 at 09:43:27AM +0200, Maxime Ripard wrote:
> > On Sat, Apr 06, 2019 at 01:45:10AM +0200, meg...@megous.com wrote:
> > > From: Ondrej Jirman
> > >
> > > ---
> > > arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi | 9 +
> > > 1 file changed, 9 insertions(+)
> > >
> > > diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
> > > b/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
> > > index 91fecab58836..dccad79da90c 100644
> > > --- a/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
> > > +++ b/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
> > > @@ -238,6 +238,15 @@
> > > bias-pull-up;
> > > };
> > >
> > > +
> >
> > Extra line
> >
> > > + mmc1_pins: mmc1-pins {
> > > + pins = "PG0", "PG1", "PG2", "PG3",
> > > +"PG4", "PG5";
> > > + function = "mmc1";
> > > + drive-strength = <30>;
> > > + bias-pull-up;
> > > + };
> > > +
> >
> > Is that the only muxing option?
>
> I don't think so. I believe someone can use a 1-bit interface (bus-width =
> <1>),
> and then some data pins will be free. This pinconfig is for 4-bit bus width
> setup.
>
> Though other SoCs (ex. H3, A83T) don't consider this possibility and make the
> 4-bit config the default pinctrl for mmc1. To add to the confusion, on these
> SoCs 4-bit pinconf is the default, but 1bit bus-width is the (implicit)
> default.
> This led to some confusion in the past.
>
> So we can either:
> - keep consistency with what is done elsewhere, and make this default, despite
> not being the only option,
What is done elsewhere is that if it's the only option, just call it
$controller_pins and make that the default. If it isn't, then call it
$(controller)_$(bank)_pins, and put it at the board level.
If it's not the only muxing option, then your name should be called
mmc1-pg-pins
> - or perhaps I can rename this to mmc1_bus_width4_pins, or somesuch, to make
> it
> more explicit, and keep it non-default.
We haven't encountered a case where the 1-bit bus was actually used,
so there's no need to take care of that.
Maxime
--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: linux-next: build failure after merge of the drm-misc tree
On Tue, Apr 09, 2019 at 04:08:49PM +1000, Stephen Rothwell wrote: > Hi all, > > After merging the drm-misc tree, today's linux-next build (powerpc > allyesconfig) failed like this: > > drivers/gpu/drm/cirrus/cirrus.c: In function 'cirrus_fb_blit_rect': > drivers/gpu/drm/cirrus/cirrus.c:310:25: error: implicit declaration of > function '__io_virt'; did you mean '__do_irq'? > [-Werror=implicit-function-declaration] >drm_fb_memcpy_dstclip(__io_virt(cirrus->vram), > ^ > __do_irq Probably just a missing arm/io.h include. Test build is running ... cheers, Gerd ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] drm/lima: add missing Kconfig dependency
On 09/04/2019 02:36, Qiang Yu wrote:
> Current implementation does not support MMU-less
> plarforms.
>
> Cc: Randy Dunlap
You could also add :
Suggested-by: Randy Dunlap
Like patch 2.
But you can fix it while applying it
> Cc: Neil Armstrong
> Fixes: a1d2a6339961 ("drm/lima: driver for ARM Mali4xx GPUs")
> Signed-off-by: Qiang Yu
> ---
> drivers/gpu/drm/lima/Kconfig | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/gpu/drm/lima/Kconfig b/drivers/gpu/drm/lima/Kconfig
> index f11314448093..bb4ddc6bb0a6 100644
> --- a/drivers/gpu/drm/lima/Kconfig
> +++ b/drivers/gpu/drm/lima/Kconfig
> @@ -5,6 +5,9 @@ config DRM_LIMA
> tristate "LIMA (DRM support for ARM Mali 400/450 GPU)"
> depends on DRM
> depends on ARM || ARM64 || COMPILE_TEST
> + depends on MMU
> + depends on COMMON_CLK
> + depends on OF
> select DRM_SCHED
> help
> DRM driver for ARM Mali 400/450 GPUs.
>
Reviewed-by: Neil Armstrong
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 01/12] arm64: dts: allwinner: h6: Add Orange Pi 3 DTS
On Tue, Apr 09, 2019 at 12:58:51AM +0200, Ondřej Jirman wrote:
> > > +&usb2otg {
> > > + dr_mode = "host";
> > > + status = "okay";
> > > +};
> > > +
> > > +&usb2phy {
> > > + usb0_id_det-gpios = <&pio 2 15 GPIO_ACTIVE_HIGH>; /* PC15 */
> > > + usb0_vbus-supply = <®_vcc5v>;
> > > + usb3_vbus-supply = <®_vcc5v>;
> > > + status = "okay";
> >
> > If we have an ID pin, then why is the OTG controller set to host?
>
> This board has fixed conenction between VBUS and DCIN, so if it is powered
> from DCIN and someone will try to connect it to the PC as a peripheral,
> they'll get PC's VBUS shorted to the power supply connected to DCIN.
>
> Depending on voltage difference between DCIN and PC's VBUS, you can get
> overcurrent condidion and PC's port shutdown.
>
> The board is not entirely foolproof in this regard.
>
> - It can be host powered when connected via microUSB
> - It can be self-powered and host an device on microUSB
> - It can be self-powered and serve as a peripheral if you modify
> a cable (cut VBUS) or the host is expecting this and has some
> VBUS detection logic (most hosts will not have this)
>
> I just didn't want to encourage use as a peripheral, because it's not
> very foolproof. But I guess, DTS file will not stop anyone anyway.
>
> I'll change it to otg, and maybe leave a small note.
Your solution was great actually. I guess making a comment explaining
what you just did would be better though, so that no one is confused.
Maxime
--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] drm/lima: include used header file explicitly
On 09/04/2019 02:36, Qiang Yu wrote:
> To prevent build fail on some platform which does
> not have it in the include file chain.
>
> Cc: Neil Armstrong
> Suggested-by: Randy Dunlap
> Fixes: a1d2a6339961 ("drm/lima: driver for ARM Mali4xx GPUs")
> Signed-off-by: Qiang Yu
> ---
> drivers/gpu/drm/lima/lima_gem.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpu/drm/lima/lima_gem.c b/drivers/gpu/drm/lima/lima_gem.c
> index 2d3cf96f6c58..1d69498bc17e 100644
> --- a/drivers/gpu/drm/lima/lima_gem.c
> +++ b/drivers/gpu/drm/lima/lima_gem.c
> @@ -1,6 +1,7 @@
> // SPDX-License-Identifier: GPL-2.0 OR MIT
> /* Copyright 2017-2019 Qiang Yu */
>
> +#include
> #include
> #include
>
>
Reviewed-by: Neil Armstrong
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 07/12] arm64: dts: allwinner: orange-pi-3: Enable ethernet
On Tue, Apr 09, 2019 at 01:22:32AM +0200, Ondřej Jirman wrote:
> On Mon, Apr 08, 2019 at 09:40:42AM +0200, Maxime Ripard wrote:
> > On Sat, Apr 06, 2019 at 01:45:09AM +0200, meg...@megous.com wrote:
> > > From: Ondrej Jirman
> > >
> > > Orange Pi 3 has two regulators that power the Realtek RTL8211E.
> > > According to the phy datasheet, both regulators need to be enabled
> > > at the same time, but we can only specify a single phy-supply in
> > > the DT.
> > >
> > > This can be achieved by making one regulator depedning on the
> > > other via vin-supply. While it's not a technically correct
> > > description of the hardware, it achieves the purpose.
> > >
> > > All values of RX/TX delay were tested exhaustively and a middle
> > > one of the working values was chosen.
> > >
> > > Signed-off-by: Ondrej Jirman
> > > ---
> > > .../dts/allwinner/sun50i-h6-orangepi-3.dts| 44 +++
> > > 1 file changed, 44 insertions(+)
> > >
> > > diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-3.dts
> > > b/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-3.dts
> > > index 644946749088..5270142527f5 100644
> > > --- a/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-3.dts
> > > +++ b/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-3.dts
> > > @@ -15,6 +15,7 @@
> > >
> > > aliases {
> > > serial0 = &uart0;
> > > + ethernet0 = &emac;
> > > };
> > >
> > > chosen {
> > > @@ -64,6 +65,27 @@
> > > regulator-max-microvolt = <500>;
> > > regulator-always-on;
> > > };
> > > +
> > > + /*
> > > + * The board uses 2.5V RGMII signalling. Power sequence
> > > + * to enable the phy is to enable GMAC-2V5 and GMAC-3V3 (aldo2)
> > > + * power rails at the same time and to wait 100ms.
> > > + */
> > > + reg_gmac_2v5: gmac-2v5 {
> > > +compatible = "regulator-fixed";
> > > +regulator-name = "gmac-2v5";
> > > +regulator-min-microvolt = <250>;
> > > +regulator-max-microvolt = <250>;
> > > +startup-delay-us = <10>;
> > > +enable-active-high;
> > > +gpio = <&pio 3 6 GPIO_ACTIVE_HIGH>; /* PD6 */
> >
> > Is enable-active-high still needed? It's redundant with the
> > GPIO_ACTIVE_HIGH flag.
>
> Looking at the code, use/non-use of enable-active-high inhibits
> flags specified in gpio property. So the GPIO_ACTIVE_HIGH flag
> is ignored here (had GPIO_ACTIVE_LOW been used, the kernel would
> ignore it too and print a warning).
>
> So enable-active-high is still necessary here.
Too bad :/
> See comment in gpiolib-of.c where this is handled:
>
> /*
> * The regulator GPIO handles are specified such that the
> * presence or absence of "enable-active-high" solely controls
> * the polarity of the GPIO line. Any phandle flags must
> * be actively ignored.
> */
Thanks for digging this out
Maxime
--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: linux-next: manual merge of the drm-misc tree with the drm tree
On Tue, Apr 09, 2019 at 11:34:10AM +1000, Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the drm-misc tree got conflicts in:
>
> drivers/gpu/drm/cirrus/cirrus_drv.h
> drivers/gpu/drm/cirrus/cirrus_ttm.c
>
> between commits:
>
> aa8e2435b3d4 ("drm/ttm: Define a single DRM_FILE_PAGE_OFFSET constant")
> 7d1500f9fbfc ("drm/ttm: Remove file_page_offset parameter from
> ttm_bo_device_init()")
> bed2dd84212e ("drm/ttm: Quick-test mmap offset in ttm_bo_mmap()")
>
> from the drm tree and commit:
>
> ab3e023b1b4c ("drm/cirrus: rewrite and modernize driver.")
>
> from the drm-misc tree.
>
> I fixed it up (I just removed the files) and can carry the fix as
> necessary. This is now fixed as far as linux-next is concerned, but any
> non trivial conflicts should be mentioned to your upstream maintainer
> when your tree is submitted for merging. You may also want to consider
> cooperating with the maintainer of the conflicting tree to minimise any
> particularly complex conflicts.
Ping drm-misc maintainers. Time to update drm-misc-next with a
backmerge I think?
thanks,
Gerd
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 07/12] arm64: dts: allwinner: orange-pi-3: Enable ethernet
On Tue, Apr 9, 2019 at 1:22 AM Ondřej Jirman wrote: > > > +enable-active-high; > > > +gpio = <&pio 3 6 GPIO_ACTIVE_HIGH>; /* PD6 */ > > > > Is enable-active-high still needed? It's redundant with the > > GPIO_ACTIVE_HIGH flag. > > Looking at the code, use/non-use of enable-active-high inhibits > flags specified in gpio property. So the GPIO_ACTIVE_HIGH flag > is ignored here (had GPIO_ACTIVE_LOW been used, the kernel would > ignore it too and print a warning). > > So enable-active-high is still necessary here. > > See comment in gpiolib-of.c where this is handled: > > /* > * The regulator GPIO handles are specified such that the > * presence or absence of "enable-active-high" solely controls > * the polarity of the GPIO line. Any phandle flags must > * be actively ignored. > */ Yeah this caused me special headache in the current merge window because of buggy code on my part. This is an effect of this flag being defined for powerpc ages before we properly implemented generic GPIO bindings. We just have to respect it. See: https://marc.info/?l=linux-gpio&m=155417774822532&w=2 Yours, Linus Walleij ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 13/15] drm/vboxvideo: Convert vboxvideo driver to Simple TTM
Hi
Am 09.04.19 um 09:09 schrieb Hans de Goede:
> Hi,
>
> On 08-04-19 11:21, Thomas Zimmermann wrote:
>> Signed-off-by: Thomas Zimmermann
>
> Patch looks good to me (although perhaps it needs a commit msg):
OK, thanks. I'll add that message here and to the other patches.
Best regards
Thomas
>
> Reviewed-by: Hans de Goede
>
> Regards,
>
> Hans
>
>
>
>> ---
>> drivers/gpu/drm/vboxvideo/Kconfig | 1 +
>> drivers/gpu/drm/vboxvideo/vbox_drv.h | 6 +-
>> drivers/gpu/drm/vboxvideo/vbox_ttm.c | 123 ++-
>> 3 files changed, 12 insertions(+), 118 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/vboxvideo/Kconfig
>> b/drivers/gpu/drm/vboxvideo/Kconfig
>> index c1ca87df81df..e29df360978d 100644
>> --- a/drivers/gpu/drm/vboxvideo/Kconfig
>> +++ b/drivers/gpu/drm/vboxvideo/Kconfig
>> @@ -4,6 +4,7 @@ config DRM_VBOXVIDEO
>> select DRM_KMS_HELPER
>> select DRM_TTM
>> select DRM_GEM_TTM_HELPER
>> + select DRM_SIMPLE_TTM_HELPER
>> select GENERIC_ALLOCATOR
>> help
>> This is a KMS driver for the virtual Graphics Card used in
>> diff --git a/drivers/gpu/drm/vboxvideo/vbox_drv.h
>> b/drivers/gpu/drm/vboxvideo/vbox_drv.h
>> index 7db4e961805d..d4cfcc6339ef 100644
>> --- a/drivers/gpu/drm/vboxvideo/vbox_drv.h
>> +++ b/drivers/gpu/drm/vboxvideo/vbox_drv.h
>> @@ -20,6 +20,8 @@
>> #include
>> #include
>> +#include
>> +
>> #include
>> #include
>> #include
>> @@ -78,9 +80,7 @@ struct vbox_private {
>> int fb_mtrr;
>> - struct {
>> - struct ttm_bo_device bdev;
>> - } ttm;
>> + struct drm_simple_ttm ttm;
>> struct mutex hw_mutex; /* protects modeset and accel/vbva
>> accesses */
>> struct work_struct hotplug_work;
>> diff --git a/drivers/gpu/drm/vboxvideo/vbox_ttm.c
>> b/drivers/gpu/drm/vboxvideo/vbox_ttm.c
>> index a1d64e1ea90c..115ec44636ab 100644
>> --- a/drivers/gpu/drm/vboxvideo/vbox_ttm.c
>> +++ b/drivers/gpu/drm/vboxvideo/vbox_ttm.c
>> @@ -11,128 +11,25 @@
>> #include
>> #include "vbox_drv.h"
>> -static inline struct vbox_private *vbox_bdev(struct ttm_bo_device *bd)
>> -{
>> - return container_of(bd, struct vbox_private, ttm.bdev);
>> -}
>> -
>> -static int
>> -vbox_bo_init_mem_type(struct ttm_bo_device *bdev, u32 type,
>> - struct ttm_mem_type_manager *man)
>> -{
>> - switch (type) {
>> - case TTM_PL_SYSTEM:
>> - man->flags = TTM_MEMTYPE_FLAG_MAPPABLE;
>> - man->available_caching = TTM_PL_MASK_CACHING;
>> - man->default_caching = TTM_PL_FLAG_CACHED;
>> - break;
>> - case TTM_PL_VRAM:
>> - man->func = &ttm_bo_manager_func;
>> - man->flags = TTM_MEMTYPE_FLAG_FIXED | TTM_MEMTYPE_FLAG_MAPPABLE;
>> - man->available_caching = TTM_PL_FLAG_UNCACHED | TTM_PL_FLAG_WC;
>> - man->default_caching = TTM_PL_FLAG_WC;
>> - break;
>> - default:
>> - DRM_ERROR("Unsupported memory type %u\n", (unsigned int)type);
>> - return -EINVAL;
>> - }
>> -
>> - return 0;
>> -}
>> -
>> -static int vbox_ttm_io_mem_reserve(struct ttm_bo_device *bdev,
>> - struct ttm_mem_reg *mem)
>> -{
>> - struct ttm_mem_type_manager *man = &bdev->man[mem->mem_type];
>> - struct vbox_private *vbox = vbox_bdev(bdev);
>> -
>> - mem->bus.addr = NULL;
>> - mem->bus.offset = 0;
>> - mem->bus.size = mem->num_pages << PAGE_SHIFT;
>> - mem->bus.base = 0;
>> - mem->bus.is_iomem = false;
>> - if (!(man->flags & TTM_MEMTYPE_FLAG_MAPPABLE))
>> - return -EINVAL;
>> - switch (mem->mem_type) {
>> - case TTM_PL_SYSTEM:
>> - /* system memory */
>> - return 0;
>> - case TTM_PL_VRAM:
>> - mem->bus.offset = mem->start << PAGE_SHIFT;
>> - mem->bus.base = pci_resource_start(vbox->ddev.pdev, 0);
>> - mem->bus.is_iomem = true;
>> - break;
>> - default:
>> - return -EINVAL;
>> - }
>> - return 0;
>> -}
>> -
>> -static void vbox_ttm_io_mem_free(struct ttm_bo_device *bdev,
>> - struct ttm_mem_reg *mem)
>> -{
>> -}
>> -
>> -static void vbox_ttm_backend_destroy(struct ttm_tt *tt)
>> -{
>> - ttm_tt_fini(tt);
>> - kfree(tt);
>> -}
>> -
>> -static struct ttm_backend_func vbox_tt_backend_func = {
>> - .destroy = &vbox_ttm_backend_destroy,
>> -};
>> -
>> -static struct ttm_tt *vbox_ttm_tt_create(struct ttm_buffer_object *bo,
>> - u32 page_flags)
>> -{
>> - struct ttm_tt *tt;
>> -
>> - tt = kzalloc(sizeof(*tt), GFP_KERNEL);
>> - if (!tt)
>> - return NULL;
>> -
>> - tt->func = &vbox_tt_backend_func;
>> - if (ttm_tt_init(tt, bo, page_flags)) {
>> - kfree(tt);
>> - return NULL;
>> - }
>> -
>> - return tt;
>> -}
>> -
>> -static struct ttm_bo_driver vbox_bo_driver = {
>> - .ttm_tt_create = vbox_ttm_tt_create,
>> - .init_mem_type = vbox_bo_init_mem_type,
>> - .eviction_valuable = ttm_bo_eviction_valuable,
>> +static const struct drm_simple_ttm_funcs
Re: [PATCH 00/15] Share TTM code among framebuffer drivers
On Tue, 9 Apr 2019 at 17:12, kra...@redhat.com wrote: > > Hi, > > > If not for TTM, what would be the alternative? One VMA manager per > > memory region per device? > > Depends pretty much on the device. > > The cirrus is a display device with only 4 MB of vram. You can't fit > much in there. A single 1024x768 @ 24bpp framebuffer needs more 50% > of the video memory already. Which is why the cirrus driver (before the > rewrite) had to migrate buffers from/to vram on every page flip[1]. Which > is one[2] of the reasons why cirrus (after rewrite) doesn't ttm-manage the > vram any more. gem objects are managed with the shmem helpers instead > and the active framebuffer is blitted to vram. > > The qemu stdvga (bochs driver) has 16 MB vram by default and can be > configured to have up to 256 MB. Plenty of room even for multiple 4k > framebuffers if needed. So for the bochs driver all the ttm bo > migration logic is not needed, it could just store everything in vram. To clarify I assume you mean it doesn't need the migrate each bo logic, but it still needs the when VRAM fills up migrate stuff logic. Dave. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [linux-sunxi] Re: [PATCH 02/12] drm: sun4i: Add support for enabling DDC I2C bus to dw_hdmi glue
On Mon, Apr 08, 2019 at 02:17:27PM +0200, Ondřej Jirman wrote: > On Mon, Apr 08, 2019 at 10:47:14AM +0200, Maxime Ripard wrote: > > On Mon, Apr 08, 2019 at 03:28:24PM +0800, Chen-Yu Tsai wrote: > > > On Mon, Apr 8, 2019 at 3:23 PM Maxime Ripard > > > wrote: > > > > > > > > On Sat, Apr 06, 2019 at 01:45:04AM +0200, meg...@megous.com wrote: > > > > > From: Ondrej Jirman > > > > > > > > > > Orange Pi 3 board requires enabling DDC I2C bus via some GPIO > > > > > connected > > > > > transistors, before it can be used. Model this as a power supply for > > > > > DDC > > > > > (via regulator framework). > > > > > > > > > > Signed-off-by: Ondrej Jirman > > > > > > > > The DDC bus itself is usually attached to the HDMI connector, so it > > > > would make sense to make the supply also a property of the connector. > > > > > > I believe these are separate things. What this patch covers is power for > > > a voltage shifter between the SoC and HDMI DDC pins. The HDMI connector's > > > 5V supply to power the remote DDC chip is something else. And on the > > > Orange Pi 3 they are indeed separate supplies. > > > > Then maybe the endpoint link between the two would be the best place > > to put this? > > Interestingly &hdmi node configures the DDC bus pins via pinctrl on the SoC > side, so I put this there too, because it's related to those pins. I'm not > sure > if that changes anything in the discussion. It's kind of different though. The DDC controller is within the HDMI controller, which is inside the SoC. Just like the pin muxer. As far as the hardware goes, even on your board, you don't need that supply so that the signal gets out of the SoC. If the regulator is to power up some component on the path between the SoC and the connector, then it should be attached there. Maxime -- Maxime Ripard, Bootlin Embedded Linux and Kernel engineering https://bootlin.com signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] drm/ttm: fix out-of-bounds read in ttm_put_pages() v2
On 4/8/19 9:13 PM, Christian König wrote:
When ttm_put_pages() tries to figure out whether it's dealing with
transparent hugepages, it just reads past the bounds of the pages array
without a check.
v2: simplify the test if enough pages are left in the array (Christian).
Series is Reviewed-by: Junwei Zhang
Regards,
Jerry
Signed-off-by: Jann Horn
Signed-off-by: Christian König
Fixes: 5c42c64f7d54 ("drm/ttm: fix the fix for huge compound pages")
Cc: sta...@vger.kernel.org
---
drivers/gpu/drm/ttm/ttm_page_alloc.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc.c
b/drivers/gpu/drm/ttm/ttm_page_alloc.c
index f841accc2c00..f77c81db161b 100644
--- a/drivers/gpu/drm/ttm/ttm_page_alloc.c
+++ b/drivers/gpu/drm/ttm/ttm_page_alloc.c
@@ -730,7 +730,8 @@ static void ttm_put_pages(struct page **pages, unsigned
npages, int flags,
}
#ifdef CONFIG_TRANSPARENT_HUGEPAGE
- if (!(flags & TTM_PAGE_FLAG_DMA32)) {
+ if (!(flags & TTM_PAGE_FLAG_DMA32) &&
+ (npages - i) >= HPAGE_PMD_NR) {
for (j = 0; j < HPAGE_PMD_NR; ++j)
if (p++ != pages[i + j])
break;
@@ -759,7 +760,7 @@ static void ttm_put_pages(struct page **pages, unsigned
npages, int flags,
unsigned max_size, n2free;
spin_lock_irqsave(&huge->lock, irq_flags);
- while (i < npages) {
+ while ((npages - i) >= HPAGE_PMD_NR) {
struct page *p = pages[i];
unsigned j;
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 00/15] Share TTM code among framebuffer drivers
Hi Am 09.04.19 um 09:12 schrieb kra...@redhat.com: > Hi, > >> If not for TTM, what would be the alternative? One VMA manager per >> memory region per device? > > Depends pretty much on the device. > > The cirrus is a display device with only 4 MB of vram. You can't fit > much in there. A single 1024x768 @ 24bpp framebuffer needs more 50% > of the video memory already. Which is why the cirrus driver (before the > rewrite) had to migrate buffers from/to vram on every page flip[1]. Which > is one[2] of the reasons why cirrus (after rewrite) doesn't ttm-manage the > vram any more. gem objects are managed with the shmem helpers instead > and the active framebuffer is blitted to vram. > > The qemu stdvga (bochs driver) has 16 MB vram by default and can be > configured to have up to 256 MB. Plenty of room even for multiple 4k > framebuffers if needed. So for the bochs driver all the ttm bo > migration logic is not needed, it could just store everything in vram. > > A set of drm_gem_vram_* helpers would do the job for bochs. Thanks for clarifying. drm_gem_vram_* (and drm_vram_mm for Simple TTM) is probably a better name for the data structures. > I'd expect the same applies to the vbox driver. > > Dunno about the other drm drivers and the fbdev drivers you plan to > migrate over. The AST HW can support up to 512 MiB, but 32-64 MiB seems more realistic for a server. It's similar with mgag200 HW. The old fbdev-supported device are all somewhere in the range between cirrus and bochs. Some drivers would probably benefit from the cirrus approach, some could use VRAM directly. Best regards Thomas > > cheers, > Gerd > > [1] Note: The page-flip migration logic is present in some of the other > drivers too, not sure whenever they actually need that due to being low > on vram too or whenever they just copied the old cirrus code ... > > [2] The other reason is that this allow to convert formats at blit time, > which helps to deal with some cirrus hardware limitations. > -- Thomas Zimmermann Graphics Driver Developer SUSE Linux GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany GF: Felix Imendörffer, Mary Higgins, Sri Rasiah HRB 21284 (AG Nürnberg) signature.asc Description: OpenPGP digital signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: linux-next: build failure after merge of the drm-misc tree
Hi Gerd, On Tue, 9 Apr 2019 09:22:18 +0200 Gerd Hoffmann wrote: > > On Tue, Apr 09, 2019 at 04:08:49PM +1000, Stephen Rothwell wrote: > > Hi all, > > > > After merging the drm-misc tree, today's linux-next build (powerpc > > allyesconfig) failed like this: > > > > drivers/gpu/drm/cirrus/cirrus.c: In function 'cirrus_fb_blit_rect': > > drivers/gpu/drm/cirrus/cirrus.c:310:25: error: implicit declaration of > > function '__io_virt'; did you mean '__do_irq'? > > [-Werror=implicit-function-declaration] > >drm_fb_memcpy_dstclip(__io_virt(cirrus->vram), > > ^ > > __do_irq > > Probably just a missing arm/io.h include. I assume you meant asm/io.h? -- Cheers, Stephen Rothwell pgpZIh9G9GYtk.pgp Description: OpenPGP digital signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 01/13] dt-bindings: sunxi: Add compatible for OrangePi 3 board
On Tue, Apr 09, 2019 at 02:24:40AM +0200, meg...@megous.com wrote: > From: Ondrej Jirman > > Add new Xunlong Orange Pi 3 board compatible string to the bindings > documentation. > > Signed-off-by: Ondrej Jirman Applied, thanks! Maxime -- Maxime Ripard, Bootlin Embedded Linux and Kernel engineering https://bootlin.com signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 02/13] arm64: dts: allwinner: h6: Add Orange Pi 3 DTS
Hi,
On Tue, Apr 09, 2019 at 02:24:41AM +0200, meg...@megous.com wrote:
> +&mmc0 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&mmc0_pins>;
Since 5 minutes ago, that's now the default.
> +&usb2otg {
> + /*
> + * Beware that this board will not automatically disconnect
> + * VBUS from DCIN, when self-powered and used as a peripheral.
> + */
> + dr_mode = "otg";
> + status = "okay";
> +};
As we were discussing, I guess leaving it as host is the safest
option.
I can fix both issues while applying if that's ok for you.
Maxime
--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4] dt-bindings: gpu: add bindings for the ARM Mali Bifrost GPU
On 08/04/2019 21:07, Rob Herring wrote: > On Sun, Apr 7, 2019 at 5:17 AM Neil Armstrong wrote: >> >> Hi Rob, >> >> Le 01/04/2019 13:24, Neil Armstrong a écrit : >>> On 01/04/2019 12:00, Steven Price wrote: On 01/04/2019 09:09, Neil Armstrong wrote: > Add the bindings for the Bifrost family of ARM Mali GPUs. > > The Bifrost GPU architecture is similar to the Midgard family, > but with a different Shader Core & Execution Engine structures. > > Bindings are based on the Midgard family bindings, but the inner > architectural changes makes it a separate family needing separate > bindings. > > The Bifrost GPUs are present in a number of recent SoCs, like the > Amlogic G12A Family, and many other vendors. > The Amlogic vendor specific compatible is added to handle the > specific IP integration differences and dependencies. > > Signed-off-by: Neil Armstrong > --- > .../bindings/gpu/arm,mali-bifrost.txt | 92 +++ > 1 file changed, 92 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/gpu/arm,mali-bifrost.txt > > Changes since v3: > - Added note about discoverable model/revision > - Enforced fixed defined irq order > - Fixed typo in accommodate > > Changes since v2: > - moved to a single compatible since HW is fully discoverable > > diff --git a/Documentation/devicetree/bindings/gpu/arm,mali-bifrost.txt > b/Documentation/devicetree/bindings/gpu/arm,mali-bifrost.txt > new file mode 100644 > index ..711c9ead17a2 > --- /dev/null > +++ b/Documentation/devicetree/bindings/gpu/arm,mali-bifrost.txt > @@ -0,0 +1,92 @@ > +ARM Mali Bifrost GPU > + > + > +Required properties: > + > +- compatible : > + * Since Mali Bifrost GPU model/revision if fully discoverable by > reading ^^ s/if/is/ >> >> Should I still send a v5 to fixing this typo ? I can fix it while applying >> it. > > No need to resend. I planned to apply it, but if you are going to: > > Reviewed-by: Rob Herring > Thanks, Fixed and applied on drm-misc-next Neil ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 09/12] pinctrl: sunxi: Prepare for alternative bias voltage setting methods
Hi Linus, On Mon, Apr 08, 2019 at 02:53:58PM +0200, Linus Walleij wrote: > On Sat, Apr 6, 2019 at 1:45 AM wrote: > > > From: Ondrej Jirman > > > > H6 has a different I/O voltage bias setting method than A80. Prepare > > existing code for using alternative bias voltage setting methods. > > > > Signed-off-by: Ondrej Jirman > > --- > > drivers/pinctrl/sunxi/pinctrl-sun9i-a80.c | 2 +- > > drivers/pinctrl/sunxi/pinctrl-sunxi.c | 38 --- > > drivers/pinctrl/sunxi/pinctrl-sunxi.h | 4 ++- > > I need Maxime's ACK on these patches to merge. > > Can the pinctrl parts be applied independently of the rest > of the changes when Maxime is happy with the patches? Yes, the two pinctrl patches are independent of the rest of the series. thank you, Ondrej > Yours, > Linus Walleij ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] sync_file: Return reasonable timestamp when merging signaled fences
If all the sync points were signaled in both fences a and b,
there was only one sync point in merged fence which is a_fence[0].
The Fence structure in android framework might be confused about
timestamp if there were any sync points which were signaled after
a_fence[0]. It might be more reasonable to use timestamp of last signaled
sync point to represent the merged fence.
The issue can be found from EGL extension ANDROID_get_frame_timestamps.
Sometimes the return value of EGL_READS_DONE_TIME_ANDROID is head of
the return value of EGL_RENDERING_COMPLETE_TIME_ANDROID.
That means display/composition had been completed before rendering
was completed that is incorrect.
Some discussion can be found at:
https://android-review.googlesource.com/c/kernel/common/+/907009
Signed-off-by: Michael Yang
---
drivers/dma-buf/sync_file.c | 25 +++--
1 file changed, 23 insertions(+), 2 deletions(-)
diff --git a/drivers/dma-buf/sync_file.c b/drivers/dma-buf/sync_file.c
index 4f6305c..d46bfe1 100644
--- a/drivers/dma-buf/sync_file.c
+++ b/drivers/dma-buf/sync_file.c
@@ -274,8 +274,29 @@ static struct sync_file *sync_file_merge(const char *name,
struct sync_file *a,
for (; i_b < b_num_fences; i_b++)
add_fence(fences, &i, b_fences[i_b]);
- if (i == 0)
- fences[i++] = dma_fence_get(a_fences[0]);
+ /* If all the sync pts were signaled, then adding the sync_pt who
+* was the last signaled to the fence.
+*/
+ if (i == 0) {
+ struct dma_fence *last_signaled_sync_pt = a_fences[0];
+ int iter;
+
+ for (iter = 1; iter < a_num_fences; iter++) {
+ if (ktime_compare(last_signaled_sync_pt->timestamp,
+ a_fences[iter]->timestamp) < 0) {
+ last_signaled_sync_pt = a_fences[iter];
+ }
+ }
+
+ for (iter = 0; iter < b_num_fences; iter++) {
+ if (ktime_compare(last_signaled_sync_pt->timestamp,
+ b_fences[iter]->timestamp) < 0) {
+ last_signaled_sync_pt = b_fences[iter];
+ }
+ }
+
+ fences[i++] = dma_fence_get(last_signaled_sync_pt);
+ }
if (num_fences > i) {
nfences = krealloc(fences, i * sizeof(*fences),
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH RFC tip/core/rcu 0/4] Forbid static SRCU use in modules
On Mon, Apr 08, 2019 at 09:05:34AM -0400, Mathieu Desnoyers wrote: > - On Apr 7, 2019, at 10:27 PM, paulmck paul...@linux.ibm.com wrote: > > > On Sun, Apr 07, 2019 at 09:07:18PM +, Joel Fernandes wrote: > >> On Sun, Apr 07, 2019 at 04:41:36PM -0400, Mathieu Desnoyers wrote: > >> > > >> > - On Apr 7, 2019, at 3:32 PM, Joel Fernandes, Google > >> > j...@joelfernandes.org > >> > wrote: > >> > > >> > > On Sun, Apr 07, 2019 at 03:26:16PM -0400, Mathieu Desnoyers wrote: > >> > >> - On Apr 7, 2019, at 9:59 AM, paulmck paul...@linux.ibm.com wrote: > >> > >> > >> > >> > On Sun, Apr 07, 2019 at 06:39:41AM -0700, Paul E. McKenney wrote: > >> > >> >> On Sat, Apr 06, 2019 at 07:06:13PM -0400, Joel Fernandes wrote: > >> > >> > > >> > >> > [ . . . ] > >> > >> > > >> > >> >> > > diff --git a/include/asm-generic/vmlinux.lds.h > >> > >> >> > > b/include/asm-generic/vmlinux.lds.h > >> > >> >> > > index f8f6f04c4453..c2d919a1566e 100644 > >> > >> >> > > --- a/include/asm-generic/vmlinux.lds.h > >> > >> >> > > +++ b/include/asm-generic/vmlinux.lds.h > >> > >> >> > > @@ -338,6 +338,10 @@ > >> > >> >> > >KEEP(*(__tracepoints_ptrs)) /* Tracepoints: > >> > >> >> > > pointer array */ \ > >> > >> >> > >__stop___tracepoints_ptrs = .; > >> > >> >> > > \ > >> > >> >> > >*(__tracepoints_strings)/* Tracepoints: strings > >> > >> >> > > */ \ > >> > >> >> > > + . = ALIGN(8); > >> > >> >> > > \ > >> > >> >> > > + __start___srcu_struct = .; > >> > >> >> > > \ > >> > >> >> > > + *(___srcu_struct_ptrs) > >> > >> >> > > \ > >> > >> >> > > + __end___srcu_struct = .; > >> > >> >> > > \ > >> > >> >> > >} > >> > >> >> > > \ > >> > >> >> > > >> > >> >> > This vmlinux linker modification is not needed. I tested without > >> > >> >> > it and srcu > >> > >> >> > torture works fine with rcutorture built as a module. Putting > >> > >> >> > further prints > >> > >> >> > in kernel/module.c verified that the kernel is able to find the > >> > >> >> > srcu structs > >> > >> >> > just fine. You could squash the below patch into this one or > >> > >> >> > apply it on top > >> > >> >> > of the dev branch. > >> > >> >> > >> > >> >> Good point, given that otherwise FORTRAN named common blocks would > >> > >> >> not > >> > >> >> work. > >> > >> >> > >> > >> >> But isn't one advantage of leaving that stuff in the > >> > >> >> RO_DATA_SECTION() > >> > >> >> macro that it can be mapped read-only? Or am I suffering from > >> > >> >> excessive > >> > >> >> optimism? > >> > >> > > >> > >> > And to answer the other question, in the case where I am suffering > >> > >> > from > >> > >> > excessive optimism, it should be a separate commit. Please see > >> > >> > below > >> > >> > for the updated original commit thus far. > >> > >> > > >> > >> > And may I have your Tested-by? > >> > >> > >> > >> Just to confirm: does the cleanup performed in the modules going > >> > >> notifier end up acting as a barrier first before freeing the memory ? > >> > >> If not, is it explicitly stated that a barrier must be issued before > >> > >> module unload ? > >> > >> > >> > > > >> > > You mean rcu_barrier? It is mentioned in the documentation that this > >> > > is the > >> > > responsibility of the module writer to prevent delays for all modules. > >> > > >> > It's a srcu barrier yes. Considering it would be a barrier specific to > >> > the > >> > srcu domain within that module, I don't see how it would cause delays for > >> > "all" modules if we implicitly issue the barrier on module unload. What > >> > am I missing ? > >> > >> Yes you are right. I thought of this after I just sent my email. I think it > >> makes sense for srcu case to do and could avoid a class of bugs. > > > > If there are call_srcu() callbacks outstanding, the module writer still > > needs the srcu_barrier() because otherwise callbacks arrive after > > the module text has gone, which will be disappoint the CPU when it > > tries fetching instructions that are no longer mapped. If there are > > no call_srcu() callbacks from that module, then there is no need for > > srcu_barrier() either way. > > > > So if an srcu_barrier() is needed, the module developer needs to > > supply it. > > When you say "callbacks arrive after the module text has gone", > I think you assume that free_module() is invoked before the > MODULE_STATE_GOING notifiers are called. But it's done in the > opposite order: going notifiers are called first, and then > free_module() is invoked. > > So AFAIU it would be safe to issue the srcu_barrier() from the module > going notifier. > > Or am I missing something ? We do seem to be talking past each other. ;-) This has n
Re: [PATCH RFC tip/core/rcu 0/4] Forbid static SRCU use in modules
- On Apr 7, 2019, at 10:27 PM, paulmck paul...@linux.ibm.com wrote: > On Sun, Apr 07, 2019 at 09:07:18PM +, Joel Fernandes wrote: >> On Sun, Apr 07, 2019 at 04:41:36PM -0400, Mathieu Desnoyers wrote: >> > >> > - On Apr 7, 2019, at 3:32 PM, Joel Fernandes, Google >> > j...@joelfernandes.org >> > wrote: >> > >> > > On Sun, Apr 07, 2019 at 03:26:16PM -0400, Mathieu Desnoyers wrote: >> > >> - On Apr 7, 2019, at 9:59 AM, paulmck paul...@linux.ibm.com wrote: >> > >> >> > >> > On Sun, Apr 07, 2019 at 06:39:41AM -0700, Paul E. McKenney wrote: >> > >> >> On Sat, Apr 06, 2019 at 07:06:13PM -0400, Joel Fernandes wrote: >> > >> > >> > >> > [ . . . ] >> > >> > >> > >> >> > > diff --git a/include/asm-generic/vmlinux.lds.h >> > >> >> > > b/include/asm-generic/vmlinux.lds.h >> > >> >> > > index f8f6f04c4453..c2d919a1566e 100644 >> > >> >> > > --- a/include/asm-generic/vmlinux.lds.h >> > >> >> > > +++ b/include/asm-generic/vmlinux.lds.h >> > >> >> > > @@ -338,6 +338,10 @@ >> > >> >> > > KEEP(*(__tracepoints_ptrs)) /* Tracepoints: >> > >> >> > > pointer array */ \ >> > >> >> > > __stop___tracepoints_ptrs = .; >> > >> >> > > \ >> > >> >> > > *(__tracepoints_strings)/* Tracepoints: strings >> > >> >> > > */ \ >> > >> >> > > +. = ALIGN(8); >> > >> >> > > \ >> > >> >> > > +__start___srcu_struct = .; >> > >> >> > > \ >> > >> >> > > +*(___srcu_struct_ptrs) >> > >> >> > > \ >> > >> >> > > +__end___srcu_struct = .; >> > >> >> > > \ >> > >> >> > > } >> > >> >> > > \ >> > >> >> > >> > >> >> > This vmlinux linker modification is not needed. I tested without >> > >> >> > it and srcu >> > >> >> > torture works fine with rcutorture built as a module. Putting >> > >> >> > further prints >> > >> >> > in kernel/module.c verified that the kernel is able to find the >> > >> >> > srcu structs >> > >> >> > just fine. You could squash the below patch into this one or apply >> > >> >> > it on top >> > >> >> > of the dev branch. >> > >> >> >> > >> >> Good point, given that otherwise FORTRAN named common blocks would >> > >> >> not >> > >> >> work. >> > >> >> >> > >> >> But isn't one advantage of leaving that stuff in the >> > >> >> RO_DATA_SECTION() >> > >> >> macro that it can be mapped read-only? Or am I suffering from >> > >> >> excessive >> > >> >> optimism? >> > >> > >> > >> > And to answer the other question, in the case where I am suffering >> > >> > from >> > >> > excessive optimism, it should be a separate commit. Please see below >> > >> > for the updated original commit thus far. >> > >> > >> > >> > And may I have your Tested-by? >> > >> >> > >> Just to confirm: does the cleanup performed in the modules going >> > >> notifier end up acting as a barrier first before freeing the memory ? >> > >> If not, is it explicitly stated that a barrier must be issued before >> > >> module unload ? >> > >> >> > > >> > > You mean rcu_barrier? It is mentioned in the documentation that this is >> > > the >> > > responsibility of the module writer to prevent delays for all modules. >> > >> > It's a srcu barrier yes. Considering it would be a barrier specific to the >> > srcu domain within that module, I don't see how it would cause delays for >> > "all" modules if we implicitly issue the barrier on module unload. What >> > am I missing ? >> >> Yes you are right. I thought of this after I just sent my email. I think it >> makes sense for srcu case to do and could avoid a class of bugs. > > If there are call_srcu() callbacks outstanding, the module writer still > needs the srcu_barrier() because otherwise callbacks arrive after > the module text has gone, which will be disappoint the CPU when it > tries fetching instructions that are no longer mapped. If there are > no call_srcu() callbacks from that module, then there is no need for > srcu_barrier() either way. > > So if an srcu_barrier() is needed, the module developer needs to > supply it. When you say "callbacks arrive after the module text has gone", I think you assume that free_module() is invoked before the MODULE_STATE_GOING notifiers are called. But it's done in the opposite order: going notifiers are called first, and then free_module() is invoked. So AFAIU it would be safe to issue the srcu_barrier() from the module going notifier. Or am I missing something ? Thanks, Mathieu -- Mathieu Desnoyers EfficiOS Inc. http://www.efficios.com ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 3/5] media: uapi: Add RGB bus formats for the GiantPlus GPM940B0 panel
Hi Thierry, Le mer. 3 avril 2019 à 18:32, Thierry Reding a écrit : On Thu, Mar 14, 2019 at 01:26:20PM +0100, Paul Cercueil wrote: The GiantPlus GPM940B0 is a 24-bit TFT panel where the RGB components are transferred sequentially on a 8-bit bus. Signed-off-by: Paul Cercueil --- Notes: v2: New patch include/uapi/linux/media-bus-format.h | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) Please make sure you Cc the media maintainers on this one when you send the next version. Adding them now. Oops. Will do. diff --git a/include/uapi/linux/media-bus-format.h b/include/uapi/linux/media-bus-format.h index d6a5a3bfe6c4..f31724d6cd40 100644 --- a/include/uapi/linux/media-bus-format.h +++ b/include/uapi/linux/media-bus-format.h @@ -34,7 +34,7 @@ #define MEDIA_BUS_FMT_FIXED 0x0001 -/* RGB - next is 0x101b */ +/* RGB - next is 0x101d */ #define MEDIA_BUS_FMT_RGB444_1X12 0x1016 #define MEDIA_BUS_FMT_RGB444_2X8_PADHI_BE 0x1001 #define MEDIA_BUS_FMT_RGB444_2X8_PADHI_LE 0x1002 @@ -54,6 +54,8 @@ #define MEDIA_BUS_FMT_RGB888_1X24 0x100a #define MEDIA_BUS_FMT_RGB888_2X12_BE 0x100b #define MEDIA_BUS_FMT_RGB888_2X12_LE 0x100c +#define MEDIA_BUS_FMT_RGB888_3X8_BE 0x101b +#define MEDIA_BUS_FMT_RGB888_3X8_LE 0x101c The list looks roughly sorted, but these are not. That said, there are others that don't seem like they are sorted either. To me it looks like it's sorted alphabetically, that's why I put the two new macros there. All the more important to get feedback from the media maintainers. Thierry ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] drm/omap: fix possible object reference leak
On 4/8/2019 8:28 AM, Wen Yang wrote: The call to of_find_matching_node returns a node pointer with refcount incremented thus it must be explicitly decremented after the last usage. Detected by coccinelle with the following warnings: drivers/gpu/drm/omapdrm/dss/omapdss-boot-init.c:212:2-8: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 209, but without a corresponding object release within this function. drivers/gpu/drm/omapdrm/dss/omapdss-boot-init.c:237:1-7: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 209, but without a corresponding object release within this function. Signed-off-by: Wen Yang Reviewed-by: Mukesh Ojha Cheers, -Mukesh Reviewed-by: Laurent Pinchart Cc: Tomi Valkeinen Cc: David Airlie Cc: Daniel Vetter Cc: Sebastian Reichel Cc: Laurent Pinchart Cc: dri-devel@lists.freedesktop.org Cc: linux-ker...@vger.kernel.org Cc: Markus Elfring --- v2->v1: add a jump target. drivers/gpu/drm/omapdrm/dss/omapdss-boot-init.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/omapdrm/dss/omapdss-boot-init.c b/drivers/gpu/drm/omapdrm/dss/omapdss-boot-init.c index 2b41c75..13b3b4a 100644 --- a/drivers/gpu/drm/omapdrm/dss/omapdss-boot-init.c +++ b/drivers/gpu/drm/omapdrm/dss/omapdss-boot-init.c @@ -209,7 +209,7 @@ static int __init omapdss_boot_init(void) dss = of_find_matching_node(NULL, omapdss_of_match); if (dss == NULL || !of_device_is_available(dss)) - return 0; + goto put_node; omapdss_walk_device(dss, true); @@ -234,6 +234,8 @@ static int __init omapdss_boot_init(void) kfree(n); } +put_node: + of_node_put(dss); return 0; } ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] drm/meson: fix possible object reference leak
> v2->v1: convert a if statement into a ternary statement.
Would you like to omit the arrow in such version information?
> @@ -720,15 +720,10 @@ static bool meson_hdmi_connector_is_available(struct
> device *dev)
>
> /* If the endpoint node exists, consider it enabled */
> remote = of_graph_get_remote_port(ep);
> - if (remote) {
> - of_node_put(ep);
> - return true;
> - }
> -
> of_node_put(ep);
> of_node_put(remote);
Can a reordering of the passed variables be useful for such function calls?
+ of_node_put(remote);
+ of_node_put(ep);
Regards,
Markus
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] drm/meson: fix possible object reference leak
> > v2->v1: convert a if statement into a ternary statement.
>
> Would you like to omit the arrow in such version information?
Thank you for your comments
The information about the previous versions goes below the ---,
and only the reviewers can see it.
It does not appear in the git log log.
Thanks.
> > @@ -720,15 +720,10 @@ static bool meson_hdmi_connector_is_available(struct
> > device *dev)
> >
> > /* If the endpoint node exists, consider it enabled */
> > remote = of_graph_get_remote_port(ep);
> > -if (remote) {
> > -of_node_put(ep);
> > -return true;
> > -}
> > -
> > of_node_put(ep);
> > of_node_put(remote);
>
> Can a reordering of the passed variables be useful for such function calls?
>
> + of_node_put(remote);
> + of_node_put(ep);
>
Thank you.
But considering the multiprocessor concurrent execution,
the reverse of the order of these two statements may not have additional
benefits.
The previous code implementation also maintains this order,
and we will keep the original order unless we can prove that the reverse order
can indeed bring real benefits.
--
Regards,
Wen___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: linux-next: build failure after merge of the drm-misc tree
On Tue, Apr 09, 2019 at 06:08:55PM +1000, Stephen Rothwell wrote: > Hi Gerd, > > > >drm_fb_memcpy_dstclip(__io_virt(cirrus->vram), > > > ^ > > > __do_irq > > > > Probably just a missing arm/io.h include. > > I assume you meant asm/io.h? Yes. cheers, Gerd ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [linux-sunxi] [PATCH 00/12] Add support for Orange Pi 3
Hi Jagan, On Mon, Apr 08, 2019 at 11:31:22AM +0530, Jagan Teki wrote: > On Sun, Apr 7, 2019 at 8:02 PM 'Ondřej Jirman' via linux-sunxi > wrote: > > > > On Sun, Apr 07, 2019 at 03:36:21PM +0200, Clément Péron wrote: > > > Hi, > > > > > > On Sat, 6 Apr 2019 at 01:45, megous via linux-sunxi > > > wrote: > > > > > > > > From: Ondrej Jirman > > > > > > > > This series implements support for Xunlong Orange Pi 3 board. > > > > > > OrangePi 3 Lite2 and One Plus boards support has already been merged. > > > The support is not complete but you should rebase your patches on top > > > of sunxi/for-next > > > > Hi, > > > > OrangePi 3 is somewhat different from these two boards (mostly it has a > > differnt > > power tree). It doesn't use the AXP regulators that are defined in the > > sun50i-h6-orangepi.dtsi in the same way. > > > > For example: > > > > - bldo3 (is turned always on in sun50i-h6-orangepi.dtsi but unused for opi3) > > - cldo2 and cldo3 are unused on opi3 and have nothing to do with WiFi > > - aldo3 is not for dram > > - bldo1 on the other hand is for dram on opi3 > > - some other regulators are used for different/more functions and thus > > named differntly > > - USB id-det pin is differnt > > - ... > > Based on my communication with OrangePI, OPI-3 has PCIE, 4 USB-3.0 > ports and AV are the key differences and rest seems to be similar. but > if we have a diff or unused regulators may be we can't enable them in > dtsi (I never looked that close as of now) These regulators are not just disabled on Opi 3, they have different/no meaning. Schematics allow for high amount of variability in the power tree (see all the NC (not connected) / 0R resistors) in the schematic around AXP805. Every board based on this Xunlong design can be subtly different. I already suggested a maintainable solution, below. Where base dtsi has empty config for regulators and every board based on that just defines it completely for itself. A few regulators (for CPU/GPU) will most probably have the same meaning on every derived board, so these can probably be kept in dtsi without causing too much annoyance. It's unpleasant to have wrong regulator setup defined in an underlying dtsi, and then trying to override it by removing/adding random properties in the board dts for the new boards based on that, so that it fits. The rest of the current HW descriptions in the sun50i-h6-orangepi.dtsi can be shared (as of now). thank you and regards, o. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 07/12] arm64: dts: allwinner: orange-pi-3: Enable ethernet
On Mon, Apr 08, 2019 at 11:41:38AM +0530, Jagan Teki wrote: > On Sat, Apr 6, 2019 at 5:15 AM wrote: > > > > From: Ondrej Jirman > > > > Orange Pi 3 has two regulators that power the Realtek RTL8211E. > > According to the phy datasheet, both regulators need to be enabled > > at the same time, but we can only specify a single phy-supply in > > the DT. > > > > This can be achieved by making one regulator depedning on the > > other via vin-supply. While it's not a technically correct > > description of the hardware, it achieves the purpose. > > > > All values of RX/TX delay were tested exhaustively and a middle > > one of the working values was chosen. > > > > Signed-off-by: Ondrej Jirman > > --- > > .../dts/allwinner/sun50i-h6-orangepi-3.dts| 44 +++ > > 1 file changed, 44 insertions(+) > > This was in ML[1], I thought this change would already merged. I > remember Chen-Yu applied and revert due to emac node not mainlined at > that time. > > [1] https://patchwork.kernel.org/patch/10558281/ The patch was not merged at the time, and bitrotted a bit. Armbian folks were applying the bitortted patch out-of-the mainline and were experiencing NPEs. I fixed the patch, and it is also part of this series. It's patch 5. o. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH V10 2/5] drm/mediatek: fix the rate and divder of hdmi phy for MT2701
From: Wangyan Wang
Due to a clerical error,there is one zero less for 1280.
Fix it for 12800
Fixes: 0fc721b2968e ("drm/mediatek: add hdmi driver for MT2701 and MT7623")
Reviewed-by: CK Hu
Signed-off-by: Wangyan Wang
---
drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c
b/drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c
index 67a814649e19..844e622f052c 100644
--- a/drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c
+++ b/drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c
@@ -116,8 +116,8 @@ static int mtk_hdmi_pll_set_rate(struct clk_hw *hw,
unsigned long rate,
if (rate <= 6400)
pos_div = 3;
- else if (rate <= 1280)
- pos_div = 1;
+ else if (rate <= 12800)
+ pos_div = 2;
else
pos_div = 1;
--
2.14.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH RFC tip/core/rcu 0/4] Forbid static SRCU use in modules
On Mon, Apr 08, 2019 at 10:49:32AM -0400, Mathieu Desnoyers wrote: > - On Apr 8, 2019, at 10:22 AM, paulmck paul...@linux.ibm.com wrote: > > > On Mon, Apr 08, 2019 at 09:05:34AM -0400, Mathieu Desnoyers wrote: > >> - On Apr 7, 2019, at 10:27 PM, paulmck paul...@linux.ibm.com wrote: > >> > >> > On Sun, Apr 07, 2019 at 09:07:18PM +, Joel Fernandes wrote: > >> >> On Sun, Apr 07, 2019 at 04:41:36PM -0400, Mathieu Desnoyers wrote: > >> >> > > >> >> > - On Apr 7, 2019, at 3:32 PM, Joel Fernandes, Google > >> >> > j...@joelfernandes.org > >> >> > wrote: > >> >> > > >> >> > > On Sun, Apr 07, 2019 at 03:26:16PM -0400, Mathieu Desnoyers wrote: > >> >> > >> - On Apr 7, 2019, at 9:59 AM, paulmck paul...@linux.ibm.com > >> >> > >> wrote: > >> >> > >> > >> >> > >> > On Sun, Apr 07, 2019 at 06:39:41AM -0700, Paul E. McKenney wrote: > >> >> > >> >> On Sat, Apr 06, 2019 at 07:06:13PM -0400, Joel Fernandes wrote: > >> >> > >> > > >> >> > >> > [ . . . ] > >> >> > >> > > >> >> > >> >> > > diff --git a/include/asm-generic/vmlinux.lds.h > >> >> > >> >> > > b/include/asm-generic/vmlinux.lds.h > >> >> > >> >> > > index f8f6f04c4453..c2d919a1566e 100644 > >> >> > >> >> > > --- a/include/asm-generic/vmlinux.lds.h > >> >> > >> >> > > +++ b/include/asm-generic/vmlinux.lds.h > >> >> > >> >> > > @@ -338,6 +338,10 @@ > >> >> > >> >> > > KEEP(*(__tracepoints_ptrs)) /* Tracepoints: > >> >> > >> >> > > pointer array */ \ > >> >> > >> >> > > __stop___tracepoints_ptrs = .; > >> >> > >> >> > > \ > >> >> > >> >> > > *(__tracepoints_strings)/* Tracepoints: strings > >> >> > >> >> > > */ \ > >> >> > >> >> > > + . = ALIGN(8); > >> >> > >> >> > > \ > >> >> > >> >> > > + __start___srcu_struct = .; > >> >> > >> >> > > \ > >> >> > >> >> > > + *(___srcu_struct_ptrs) > >> >> > >> >> > > \ > >> >> > >> >> > > + __end___srcu_struct = .; > >> >> > >> >> > > \ > >> >> > >> >> > > } > >> >> > >> >> > > \ > >> >> > >> >> > > >> >> > >> >> > This vmlinux linker modification is not needed. I tested > >> >> > >> >> > without it and srcu > >> >> > >> >> > torture works fine with rcutorture built as a module. Putting > >> >> > >> >> > further prints > >> >> > >> >> > in kernel/module.c verified that the kernel is able to find > >> >> > >> >> > the srcu structs > >> >> > >> >> > just fine. You could squash the below patch into this one or > >> >> > >> >> > apply it on top > >> >> > >> >> > of the dev branch. > >> >> > >> >> > >> >> > >> >> Good point, given that otherwise FORTRAN named common blocks > >> >> > >> >> would not > >> >> > >> >> work. > >> >> > >> >> > >> >> > >> >> But isn't one advantage of leaving that stuff in the > >> >> > >> >> RO_DATA_SECTION() > >> >> > >> >> macro that it can be mapped read-only? Or am I suffering from > >> >> > >> >> excessive > >> >> > >> >> optimism? > >> >> > >> > > >> >> > >> > And to answer the other question, in the case where I am > >> >> > >> > suffering from > >> >> > >> > excessive optimism, it should be a separate commit. Please see > >> >> > >> > below > >> >> > >> > for the updated original commit thus far. > >> >> > >> > > >> >> > >> > And may I have your Tested-by? > >> >> > >> > >> >> > >> Just to confirm: does the cleanup performed in the modules going > >> >> > >> notifier end up acting as a barrier first before freeing the > >> >> > >> memory ? > >> >> > >> If not, is it explicitly stated that a barrier must be issued > >> >> > >> before > >> >> > >> module unload ? > >> >> > >> > >> >> > > > >> >> > > You mean rcu_barrier? It is mentioned in the documentation that > >> >> > > this is the > >> >> > > responsibility of the module writer to prevent delays for all > >> >> > > modules. > >> >> > > >> >> > It's a srcu barrier yes. Considering it would be a barrier specific > >> >> > to the > >> >> > srcu domain within that module, I don't see how it would cause delays > >> >> > for > >> >> > "all" modules if we implicitly issue the barrier on module unload. > >> >> > What > >> >> > am I missing ? > >> >> > >> >> Yes you are right. I thought of this after I just sent my email. I > >> >> think it > >> >> makes sense for srcu case to do and could avoid a class of bugs. > >> > > >> > If there are call_srcu() callbacks outstanding, the module writer still > >> > needs the srcu_barrier() because otherwise callbacks arrive after > >> > the module text has gone, which will be disappoint the CPU when it > >> > tries fetching instructions that are no longer mapped. If there are > >> > no call_srcu() callbacks from that module, then there is no need for > >> > srcu_barrier() either way. > >> > > >> > So if an srcu_barrier() is needed, the module develope
Re: [PATCH 01/12] arm64: dts: allwinner: h6: Add Orange Pi 3 DTS
On Mon, Apr 08, 2019 at 09:46:28AM +0200, Maxime Ripard wrote:
> On Sat, Apr 06, 2019 at 01:45:03AM +0200, meg...@megous.com wrote:
> > From: Ondrej Jirman
> >
> > Orange Pi 3 is a H6 based SBC made by Xulong, released in
> > January 2019. It has the following features:
> >
> > - Allwinner H6 quad-core 64-bit ARM Cortex-A53
> > - GPU Mali-T720
> > - 1GB or 2GB LPDDR3 RAM
> > - AXP805 PMIC
> > - AP6256 Wifi/BT 5.0
> > - USB 2.0 host port (A)
> > - USB 2.0 micro usb, OTG
> > - USB 3.0 Host + 4 port USB hub (GL3510)
> > - Gigabit Ethernet (Realtek RTL8211E phy)
> > - HDMI 2.0 port
> > - soldered eMMC (optional)
> > - 3x LED (one is on the bottom)
> > - microphone
> > - audio jack
> > - PCIe
> >
> > Add basic support for the board.
> >
> > Signed-off-by: Ondrej Jirman
> > ---
> > arch/arm64/boot/dts/allwinner/Makefile| 1 +
> > .../dts/allwinner/sun50i-h6-orangepi-3.dts| 212 ++
> > 2 files changed, 213 insertions(+)
> > create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-3.dts
> >
> > diff --git a/arch/arm64/boot/dts/allwinner/Makefile
> > b/arch/arm64/boot/dts/allwinner/Makefile
> > index e4dce2f6fa3a..285a7cb5135b 100644
> > --- a/arch/arm64/boot/dts/allwinner/Makefile
> > +++ b/arch/arm64/boot/dts/allwinner/Makefile
> > @@ -20,6 +20,7 @@ dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h5-orangepi-pc2.dtb
> > dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h5-orangepi-prime.dtb
> > dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h5-orangepi-zero-plus.dtb
> > dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h5-orangepi-zero-plus2.dtb
> > +dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h6-orangepi-3.dtb
> > dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h6-orangepi-lite2.dtb
> > dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h6-orangepi-one-plus.dtb
> > dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h6-pine-h64.dtb
> > diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-3.dts
> > b/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-3.dts
> > new file mode 100644
> > index ..7a2424fcaed7
> > --- /dev/null
> > +++ b/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-3.dts
> > @@ -0,0 +1,212 @@
> > +// SPDX-License-Identifier: (GPL-2.0+ or MIT)
> > +/*
> > + * Copyright (C) 2019 Ondřej Jirman
> > + */
> > +
> > +/dts-v1/;
> > +
> > +#include "sun50i-h6.dtsi"
> > +
> > +#include
> > +
> > +/ {
> > + model = "OrangePi 3";
> > + compatible = "xunlong,orangepi-3", "allwinner,sun50i-h6";
>
> As Clement pointed out, this should be documented in
> Documentation/devicetree/bindings/arm/sunxi.yaml
>
> It's part of sunxi/for-next only at this point, and it will go through
> a different branch than the H6 DTS, so it would be great to have it in
> a separate patch.
>
> > + aliases {
> > + serial0 = &uart0;
> > + };
> > +
> > + chosen {
> > + stdout-path = "serial0:115200n8";
> > + };
> > +
> > + leds {
> > + compatible = "gpio-leds";
> > +
> > + power {
> > + label = "orangepi:red:power";
> > + gpios = <&r_pio 0 4 GPIO_ACTIVE_HIGH>; /* PL4 */
> > + default-state = "on";
> > + };
> > +
> > + status {
> > + label = "orangepi:green:status";
> > + gpios = <&r_pio 0 7 GPIO_ACTIVE_HIGH>; /* PL7 */
> > + };
> > + };
> > +
> > + reg_vcc5v: vcc5v {
> > + /* board wide 5V supply directly from the DC jack */
> > + compatible = "regulator-fixed";
> > + regulator-name = "vcc-5v";
> > + regulator-min-microvolt = <500>;
> > + regulator-max-microvolt = <500>;
> > + regulator-always-on;
> > + };
> > +};
> > +
> > +&cpu0 {
> > + cpu-supply = <®_dcdca>;
> > +};
> > +
> > +&ehci0 {
> > + status = "okay";
> > +};
> > +
> > +&ehci3 {
> > + status = "okay";
> > +};
> > +
> > +&mmc0 {
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&mmc0_pins>;
> > + vmmc-supply = <®_cldo1>;
> > + cd-gpios = <&pio 5 6 GPIO_ACTIVE_LOW>; /* PF6 */
> > + bus-width = <4>;
> > + status = "okay";
> > +};
> > +
> > +&ohci0 {
> > + status = "okay";
> > +};
> > +
> > +&ohci3 {
> > + status = "okay";
> > +};
> > +
> > +&pio {
> > + vcc-pc-supply = <®_bldo2>;
> > + vcc-pd-supply = <®_cldo1>;
> > +};
> > +
> > +&r_i2c {
> > + status = "okay";
> > +
> > + axp805: pmic@36 {
> > + compatible = "x-powers,axp805", "x-powers,axp806";
> > + reg = <0x36>;
> > + interrupt-parent = <&r_intc>;
> > + interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
> > + interrupt-controller;
> > + #interrupt-cells = <1>;
> > + x-powers,self-working-mode;
> > + vina-supply = <®_vcc5v>;
> > + vinb-supply = <®_vcc5v>;
> > + vinc-supply = <®_vcc5v>;
> > + vind-supply = <®_vcc5v>;
> > + vine-supply = <®_vcc5v>;
> > + aldoin-supply = <®_vcc5v>;
> > + bldoin-supply = <®_vcc5v>;
> > + cldoin-supply = <®_vcc5v>;
> > +
>
Re: [linux-sunxi] Re: [PATCH 02/12] drm: sun4i: Add support for enabling DDC I2C bus to dw_hdmi glue
On Mon, Apr 08, 2019 at 10:47:14AM +0200, Maxime Ripard wrote: > On Mon, Apr 08, 2019 at 03:28:24PM +0800, Chen-Yu Tsai wrote: > > On Mon, Apr 8, 2019 at 3:23 PM Maxime Ripard > > wrote: > > > > > > On Sat, Apr 06, 2019 at 01:45:04AM +0200, meg...@megous.com wrote: > > > > From: Ondrej Jirman > > > > > > > > Orange Pi 3 board requires enabling DDC I2C bus via some GPIO connected > > > > transistors, before it can be used. Model this as a power supply for DDC > > > > (via regulator framework). > > > > > > > > Signed-off-by: Ondrej Jirman > > > > > > The DDC bus itself is usually attached to the HDMI connector, so it > > > would make sense to make the supply also a property of the connector. > > > > I believe these are separate things. What this patch covers is power for > > a voltage shifter between the SoC and HDMI DDC pins. The HDMI connector's > > 5V supply to power the remote DDC chip is something else. And on the > > Orange Pi 3 they are indeed separate supplies. > > Then maybe the endpoint link between the two would be the best place > to put this? Interestingly &hdmi node configures the DDC bus pins via pinctrl on the SoC side, so I put this there too, because it's related to those pins. I'm not sure if that changes anything in the discussion. regards, o. > Maxime > > -- > Maxime Ripard, Bootlin > Embedded Linux and Kernel engineering > https://bootlin.com ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH V9 0/5] make mt7623 clock of hdmi stable
From: Wangyan Wang
V9 adopt maintainer's suggestion.
Here is the change list between V8 & V9
1. Align the first character to the right of '(' in
mtk_hdmi_phy_clk_get_data() of "drm/mediatek: remove flag ..."
2. Align the first character to the right of '(' in
mtk_hdmi_pll_recalc_rate() of "drm/mediatek: make implementation ..."
3. Align the first character to the right of '(' in
mtk_hdmi_pll_round_rate() of "drm/mediatek: no change ..."
4. move patch " drm/mediatek: make implementation ..." before
patch "drm/mediatek: no change parent ..."
5. To make MT2701 HDMI stable, TVDPLL should not be adjusted and
it's the parent clock of HDMI phy, so HDMI phy could not adjust parent
rate. there are 3 steps to make MT2701 HDMI stable.
1). remove flag CLK_SET_RATE_PARENT for mt2701 hdmi phy to not propagate
rate change to parent in "drm/mediatek: remove flag ...".
2). Using new factor for tvdpll in mt2701 to match divider of DPI in
mt2701 in "drm/mediatek: using new...".
3). No change parent rate in round_rate() for mt2701 hdmi phy in
"drm/mediatek: no change parent...".
6. Recalculate the rate of this clock, by querying hardware to
make implementation of recalc_rate() to match the definition.
Wangyan Wang (5):
drm/mediatek: remove flag CLK_SET_RATE_PARENT for mt2701 hdmi phy
drm/mediatek: fix the rate and divder of hdmi phy for MT2701
drm/mediatek: using new factor for tvdpll in MT2701
drm/mediatek: make implementation of recalc_rate() to match the definition
drm/mediatek: no change parent rate in round_rate() for mt2701 hdmi phy
03_27_ck.diff | 91
drivers/gpu/drm/mediatek/mtk_dpi.c | 8 +--
drivers/gpu/drm/mediatek/mtk_hdmi_phy.c| 35 ++
drivers/gpu/drm/mediatek/mtk_hdmi_phy.h| 5 +-
drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c | 50 --
drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c | 23 +++
patch1.diff| 75
patch_5_4.diff | 95 ++
remove_parent_flag.diff| 75
9 files changed, 412 insertions(+), 45 deletions(-)
create mode 100644 03_27_ck.diff
create mode 100644 patch1.diff
create mode 100644 patch_5_4.diff
create mode 100644 remove_parent_flag.diff
--
2.14.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 6/7] ARM: dts: rockchip: Specify rk3288-veyron-chromebook's display timings
Hi, On Mon, Apr 8, 2019 at 3:21 PM Doug Anderson wrote: > > Hi, > > On Sat, Apr 6, 2019 at 6:16 PM Urja Rannikko wrote: > > > > Hi, > > > > The difference would be in this format just setting hfront-porch = 87 > > and vback-porch = 14. > > Anyways the point is: I support moving this mode info into the dts, > > and I'd like to know how if at all should i go about getting a > > 60Hz(ish) mode upstreamed? > > I'm a bit torn here. I like the idea of actually getting 60 Hz and > you also increase the vblank time by a little bit (which means that if > anyone ever gets DDRFreq upstream it will work better). ...but I'm > also slightly nervous changing something like this without a really > good motivation. As you said in your commit message the pixels clocks > claimed by the spec don't actually all work and thus, to some extent, > we can only rely on trial-and-error here. While your new mode works > well on your device (and you wisely gave it a bit of margin), it is > _possible_ that there could be devices out there where it doesn't work > (especially across various temperature extremes). All devices were > tested in the factory with the old timings and presumably have been > running fine for years like that... Re: the trial and error: it might be the case that the panels actually work at 1506 vtotal if you also adjust the sync length and/or back porch "accordingly", whatever that accordingly would be for this panel since the datasheet doesnt tell. I missed this point when i was doing my testing and just adjusted the variables with the most "adjustability" (bigger starting value) to them. > I will certainly admit that it's unlikely devices would be affected, > but at the same time I'd want to know how much of a difference going > from 58.3 Hz to 60 Hz made for you. Could you actually notice any > visible difference, or was it just nice to be at 60 Hz? Honestly I was just doing this because i really liked the idea of actually making it 60Hz and my eyes arent that good at noticing high-fps things - i think the one case where it might be visible to a keen eye is 720p60 playback where you'd need to skip "about 2" (1.7..) frames a second if running at 58.3 Hz. But currently the C201 isnt doing a lot of that given i dont think i/we have a good software setup for it. That could be changing in the future with panfrost and the VPU hardware decoder support, etc. Anyways I'm thinking it would be prudent to first get this framework of device-tree modes in and then maybe adjust the mode later. Testing the 60Hz mode is simple enough: xrandr --newmode 1366x768p60 74.25 1366 1453 1483 1543 768 776 790 802 -HSync -VSync xrandr --addmode eDP-1 1366x768p60 xrandr --output eDP-1 --mode 1366x768p60 (The mode name can be anything...) So meanwhile I would appreciate it if we could get some test reports of the mode with other veyron chromebooks that have this panel :) -- Urja Rannikko ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Re: Need a pair decrement for fence's refcount if ttm_bo_add_move_fence failed?
> Am 07.04.19 um 13:44 schrieb 易林:
> > Hi, all:
> > when analyzing v5.1 source code, I notice that in
> > ttm_bo_add_move_fence,
> > when reservation_object_reserve_shared failed and return ENOMEM,
> > the fence's refcount increased without a pair decrement even after return
> > to ttm_bo_add_move_fence's caller ttm_bo_mem_force_space:
> >
> > static int ttm_bo_add_move_fence(struct ttm_buffer_object *bo,
> > struct ttm_mem_type_manager *man,
> > struct ttm_mem_reg *mem)
> > {
> > ..
> > fence = dma_fence_get(man->move);
> > spin_unlock(&man->move_lock);
> >
> > if (fence) {
> > reservation_object_add_shared_fence(bo->resv, fence);
> >
> > ret = reservation_object_reserve_shared(bo->resv, 1);
> > if (unlikely(ret))
> > return ret;
> >
> > dma_fence_put(bo->moving);
> > bo->moving = fence;
> > }
> >
> > return 0;
> > }
> >
> > can this lead to the imbalance of the fence's refcount? though the ENOMEN
> > almost won't be trigger.
>
> Yeah, the fence is leaked in the error path. Feel free to provide a
> patch to fix this.
>
> Otherwise I will provide one in the next merge window.
>
> Thanks,
> Christian.
>
> >
> > Best Regards
> >
> > Lin Yi
>
when I git clone your maintained subsystem from
'git://people.freedesktop.org/~agd5f/linux' provided on Maintainer list, why
all the commits is below 2011?
so where can I get the newest subsystem version?
Thanks,
Lin Yi.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 1/3] iommu: io-pgtable: Add ARM Mali midgard MMU page table format
On 05/04/2019 11:36, Steven Price wrote:
> On 05/04/2019 10:51, Robin Murphy wrote:
>> Hi Steve,
>>
>> On 05/04/2019 10:42, Steven Price wrote:
>>> First let me say congratulations to everyone working on Panfrost - it's
>>> an impressive achievement!
>>>
>>> Full disclosure: I used to work on the Mali kbase driver. And have been
>>> playing around with running the Mali user-space blob with the Panfrost
>>> kernel driver.
>>>
>>> On 01/04/2019 08:47, Rob Herring wrote:
ARM Mali midgard GPU is similar to standard 64-bit stage 1 page
tables, but
have a few differences. Add a new format type to represent the
format. The
input address size is 48-bits and the output address size is 40-bits
(and
possibly less?). Note that the later bifrost GPUs follow the standard
64-bit stage 1 format.
The differences in the format compared to 64-bit stage 1 format are:
The 3rd level page entry bits are 0x1 instead of 0x3 for page entries.
The access flags are not read-only and unprivileged, but read and write.
This is similar to stage 2 entries, but the memory attributes field
matches
stage 1 being an index.
The nG bit is not set by the vendor driver. This one didn't seem to
matter,
but we'll keep it aligned to the vendor driver.
>>>
>>> The nG bit should be ignored by the hardware.
>>>
>>> The MMU in Midgard/Bifrost has a quirk similar to
>>> IO_PGTABLE_QUIRK_TLBI_ON_MAP - you must perform a cache flush for the
>>> GPU to (reliably) pick up new page table mappings.
>>>
>>> You may not have seen this because of the use of the JS_CONFIG_START_MMU
>>> bit - this effectively performs a cache flush and TLB invalidate before
>>> starting a job, however when using a GPU like T760 (e.g. on the Firefly
>>> RK3288) this bit isn't being set. In my testing on the Firefly board I
>>> saw GPU page faults because of this.
>>>
>>> There's two options for fixing this - a patch like below adds the quirk
>>> mode to the MMU. Or alternatively always set JS_CONFIG_START_MMU on
>>> jobs. In my testing both options solve the page faults.
>>>
>>> To be honest I don't know the reasoning behind kbase making the
>>> JS_CONFIG_START_MMU bit conditional - I'm not aware of any reason why it
>>> can't always be set. My guess is performance, but I haven't benchmarked
>>> the difference between this and JS_CONFIG_START_MMU.
>>>
>>> -8<--
>>> From e3f75c7f04e43238dfc579029b8c11fb6b4a0c18 Mon Sep 17 00:00:00 2001
>>> From: Steven Price
>>> Date: Thu, 4 Apr 2019 15:53:17 +0100
>>> Subject: [PATCH] iommu: io-pgtable: IO_PGTABLE_QUIRK_TLBI_ON_MAP for LPAE
>>>
>>> Midgard/Bifrost GPUs require a TLB invalidation when mapping pages,
>>> implement IO_PGTABLE_QUIRK_TLBI_ON_MAP for LPAE iommu page table
>>> formats and add the quirk bit to Panfrost.
>>>
>>> Signed-off-by: Steven Price
>>> ---
>>> drivers/gpu/drm/panfrost/panfrost_mmu.c | 1 +
>>> drivers/iommu/io-pgtable-arm.c | 11 +--
>>> 2 files changed, 10 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/panfrost/panfrost_mmu.c
>>> b/drivers/gpu/drm/panfrost/panfrost_mmu.c
>>> index f3aad8591cf4..094312074d66 100644
>>> --- a/drivers/gpu/drm/panfrost/panfrost_mmu.c
>>> +++ b/drivers/gpu/drm/panfrost/panfrost_mmu.c
>>> @@ -343,6 +343,7 @@ int panfrost_mmu_init(struct panfrost_device *pfdev)
>>> mmu_write(pfdev, MMU_INT_MASK, ~0);
>>>
>>> pfdev->mmu->pgtbl_cfg = (struct io_pgtable_cfg) {
>>> + .quirks = IO_PGTABLE_QUIRK_TLBI_ON_MAP,
>>> .pgsize_bitmap = SZ_4K, // | SZ_2M | SZ_1G),
>>> .ias = 48,
>>> .oas = 40, /* Should come from dma mask? */
>>> diff --git a/drivers/iommu/io-pgtable-arm.c
>>> b/drivers/iommu/io-pgtable-arm.c
>>> index 84beea1f47a7..45fd7bbdf9aa 100644
>>> --- a/drivers/iommu/io-pgtable-arm.c
>>> +++ b/drivers/iommu/io-pgtable-arm.c
>>> @@ -505,7 +505,13 @@ static int arm_lpae_map(struct io_pgtable_ops *ops,
>>> unsigned long iova,
>>> * Synchronise all PTE updates for the new mapping before there's
>>> * a chance for anything to kick off a table walk for the new iova.
>>> */
>>> - wmb();
>>> + if (data->iop.cfg.quirks & IO_PGTABLE_QUIRK_TLBI_ON_MAP) {
>>> + io_pgtable_tlb_add_flush(&data->iop, iova, size,
>>> + ARM_LPAE_BLOCK_SIZE(2, data), false);
>>
>> For correctness (in case this ever ends up used for something with
>> VMSA-like invalidation behaviour), the granule would need to be "size"
>> here, rather than effectively hard-coded.
>
> Ah yes - I did rather just copy/paste this from io-pgtable-arm-v7s with
> minor fix-ups.
>
>> However, since Mali's invalidations appear to operate on arbitrary
>> ranges, it would probably be a lot more efficient for the driver to
>> handle this case directly, by just issuing a single big invalidation
>> after the for_each_sg() loop in panfrost_mmu_map().
>
> Yes - that would
Re: [PATCH RFC tip/core/rcu 0/4] Forbid static SRCU use in modules
- On Apr 8, 2019, at 11:46 AM, paulmck paul...@linux.ibm.com wrote: > On Mon, Apr 08, 2019 at 10:49:32AM -0400, Mathieu Desnoyers wrote: >> - On Apr 8, 2019, at 10:22 AM, paulmck paul...@linux.ibm.com wrote: >> >> > On Mon, Apr 08, 2019 at 09:05:34AM -0400, Mathieu Desnoyers wrote: >> >> - On Apr 7, 2019, at 10:27 PM, paulmck paul...@linux.ibm.com wrote: >> >> >> >> > On Sun, Apr 07, 2019 at 09:07:18PM +, Joel Fernandes wrote: >> >> >> On Sun, Apr 07, 2019 at 04:41:36PM -0400, Mathieu Desnoyers wrote: >> >> >> > >> >> >> > - On Apr 7, 2019, at 3:32 PM, Joel Fernandes, Google >> >> >> > j...@joelfernandes.org >> >> >> > wrote: >> >> >> > >> >> >> > > On Sun, Apr 07, 2019 at 03:26:16PM -0400, Mathieu Desnoyers wrote: >> >> >> > >> - On Apr 7, 2019, at 9:59 AM, paulmck paul...@linux.ibm.com >> >> >> > >> wrote: >> >> >> > >> >> >> >> > >> > On Sun, Apr 07, 2019 at 06:39:41AM -0700, Paul E. McKenney >> >> >> > >> > wrote: >> >> >> > >> >> On Sat, Apr 06, 2019 at 07:06:13PM -0400, Joel Fernandes wrote: >> >> >> > >> > >> >> >> > >> > [ . . . ] >> >> >> > >> > >> >> >> > >> >> > > diff --git a/include/asm-generic/vmlinux.lds.h >> >> >> > >> >> > > b/include/asm-generic/vmlinux.lds.h >> >> >> > >> >> > > index f8f6f04c4453..c2d919a1566e 100644 >> >> >> > >> >> > > --- a/include/asm-generic/vmlinux.lds.h >> >> >> > >> >> > > +++ b/include/asm-generic/vmlinux.lds.h >> >> >> > >> >> > > @@ -338,6 +338,10 @@ >> >> >> > >> >> > >KEEP(*(__tracepoints_ptrs)) /* Tracepoints: >> >> >> > >> >> > > pointer array */ \ >> >> >> > >> >> > >__stop___tracepoints_ptrs = .; >> >> >> > >> >> > > \ >> >> >> > >> >> > >*(__tracepoints_strings)/* Tracepoints: strings >> >> >> > >> >> > > */ \ >> >> >> > >> >> > > + . = ALIGN(8); >> >> >> > >> >> > > \ >> >> >> > >> >> > > + __start___srcu_struct = .; >> >> >> > >> >> > > \ >> >> >> > >> >> > > + *(___srcu_struct_ptrs) >> >> >> > >> >> > > \ >> >> >> > >> >> > > + __end___srcu_struct = .; >> >> >> > >> >> > > \ >> >> >> > >> >> > >} >> >> >> > >> >> > > \ >> >> >> > >> >> > >> >> >> > >> >> > This vmlinux linker modification is not needed. I tested >> >> >> > >> >> > without it and srcu >> >> >> > >> >> > torture works fine with rcutorture built as a module. >> >> >> > >> >> > Putting further prints >> >> >> > >> >> > in kernel/module.c verified that the kernel is able to find >> >> >> > >> >> > the srcu structs >> >> >> > >> >> > just fine. You could squash the below patch into this one or >> >> >> > >> >> > apply it on top >> >> >> > >> >> > of the dev branch. >> >> >> > >> >> >> >> >> > >> >> Good point, given that otherwise FORTRAN named common blocks >> >> >> > >> >> would not >> >> >> > >> >> work. >> >> >> > >> >> >> >> >> > >> >> But isn't one advantage of leaving that stuff in the >> >> >> > >> >> RO_DATA_SECTION() >> >> >> > >> >> macro that it can be mapped read-only? Or am I suffering from >> >> >> > >> >> excessive >> >> >> > >> >> optimism? >> >> >> > >> > >> >> >> > >> > And to answer the other question, in the case where I am >> >> >> > >> > suffering from >> >> >> > >> > excessive optimism, it should be a separate commit. Please see >> >> >> > >> > below >> >> >> > >> > for the updated original commit thus far. >> >> >> > >> > >> >> >> > >> > And may I have your Tested-by? >> >> >> > >> >> >> >> > >> Just to confirm: does the cleanup performed in the modules going >> >> >> > >> notifier end up acting as a barrier first before freeing the >> >> >> > >> memory ? >> >> >> > >> If not, is it explicitly stated that a barrier must be issued >> >> >> > >> before >> >> >> > >> module unload ? >> >> >> > >> >> >> >> > > >> >> >> > > You mean rcu_barrier? It is mentioned in the documentation that >> >> >> > > this is the >> >> >> > > responsibility of the module writer to prevent delays for all >> >> >> > > modules. >> >> >> > >> >> >> > It's a srcu barrier yes. Considering it would be a barrier specific >> >> >> > to the >> >> >> > srcu domain within that module, I don't see how it would cause >> >> >> > delays for >> >> >> > "all" modules if we implicitly issue the barrier on module unload. >> >> >> > What >> >> >> > am I missing ? >> >> >> >> >> >> Yes you are right. I thought of this after I just sent my email. I >> >> >> think it >> >> >> makes sense for srcu case to do and could avoid a class of bugs. >> >> > >> >> > If there are call_srcu() callbacks outstanding, the module writer still >> >> > needs the srcu_barrier() because otherwise callbacks arrive after >> >> > the module text has gone, which will be disappoint the CPU when it >> >> > tries fetching instructions that are no longer mapped. If ther
[PATCH V10 0/5] make mt7623 clock of hdmi stable
From: Wangyan Wang
V10 adopt maintainer's suggestion.
Here is the change list between V9 & V10
1. Align the first character to the right of '(' in
mtk_hdmi_phy_clk_get_data() of "drm/mediatek: remove flag ..."
2. Align the first character to the right of '(' in
mtk_hdmi_pll_recalc_rate() of "drm/mediatek: make implementation ..."
3. Align the first character to the right of '(' in
mtk_hdmi_pll_round_rate() of "drm/mediatek: no change ..."
4. move patch " drm/mediatek: make implementation ..." before
patch "drm/mediatek: no change parent ..."
5. To make MT2701 HDMI stable, TVDPLL should not be adjusted and
it's the parent clock of HDMI phy, so HDMI phy could not adjust parent
rate. there are 3 steps to make MT2701 HDMI stable.
1). remove flag CLK_SET_RATE_PARENT for mt2701 hdmi phy to not propagate
rate change to parent in "drm/mediatek: remove flag ...".
2). Using new factor for tvdpll in mt2701 to match divider of DPI in
mt2701 in "drm/mediatek: using new...".
3). No change parent rate in round_rate() for mt2701 hdmi phy in
"drm/mediatek: no change parent...".
6. Recalculate the rate of this clock, by querying hardware to
make implementation of recalc_rate() to match the definition.
Wangyan Wang (5):
drm/mediatek: remove flag CLK_SET_RATE_PARENT for mt2701 hdmi phy
drm/mediatek: fix the rate and divder of hdmi phy for MT2701
drm/mediatek: using new factor for tvdpll in MT2701
drm/mediatek: make implementation of recalc_rate() to match the definition
drm/mediatek: no change parent rate in round_rate() for mt2701 hdmi phy
03_27_ck.diff | 91
drivers/gpu/drm/mediatek/mtk_dpi.c | 8 +--
drivers/gpu/drm/mediatek/mtk_hdmi_phy.c| 35 ++
drivers/gpu/drm/mediatek/mtk_hdmi_phy.h| 5 +-
drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c | 50 --
drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c | 23 +++
patch1.diff| 75
patch_5_4.diff | 95 ++
remove_parent_flag.diff| 75
9 files changed, 412 insertions(+), 45 deletions(-)
create mode 100644 03_27_ck.diff
create mode 100644 patch1.diff
create mode 100644 patch_5_4.diff
create mode 100644 remove_parent_flag.diff
--
2.14.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] drm: rcar-du: fix possible object reference leak
> > The call to of_get_parent returns a node pointer with refcount
> > incremented thus it must be explicitly decremented after the last
> > usage.
> >
> > Detected by coccinelle with the following warnings:
> > drivers/gpu/drm/rcar-du/rcar_du_of.c:235:2-8: ERROR: missing of_node_put;
> > acquired a node pointer with refcount incremented on line 216, but without
> > a corresponding object release within this function.
> > drivers/gpu/drm/rcar-du/rcar_du_of.c:236:2-8: ERROR: missing of_node_put;
> > acquired a node pointer with refcount incremented on line 209, but without
> > a corresponding object release within this function.
> >
> > Signed-off-by: Wen Yang
> > Suggested-by: Laurent Pinchart
> > Cc: Laurent Pinchart
> > Cc: Kieran Bingham
> > Cc: David Airlie
> > Cc: Daniel Vetter
> > Cc: dri-devel@lists.freedesktop.org
> > Cc: linux-renesas-...@vger.kernel.org
> > Cc: linux-ker...@vger.kernel.org (open list)
> > ---
> > v2->v1: turn the return into a goto done.
> >
> > drivers/gpu/drm/rcar-du/rcar_du_of.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/rcar-du/rcar_du_of.c
> > b/drivers/gpu/drm/rcar-du/rcar_du_of.c
> > index afef696..782bfc7 100644
> > --- a/drivers/gpu/drm/rcar-du/rcar_du_of.c
> > +++ b/drivers/gpu/drm/rcar-du/rcar_du_of.c
> > @@ -232,7 +232,7 @@ static void __init rcar_du_of_lvds_patch(const struct
> > of_device_id *of_ids)
> > lvds_node = of_find_compatible_node(NULL, NULL, compatible);
> > if (lvds_node) {
> > of_node_put(lvds_node);
> > -return;
> > +goto done;
> > }
> >
>
>
> you might have to create multiple level to do handling it.. there are
> unnecessary put being done on "done" which is not valid
>
> for this case.
Hi Mukesh,
Thank you for your comments.
lvds_data has been initialized to 0,
so the put operation in the done tag may have no effect:
199 struct lvds_of_data lvds_data[2] = { };
...
309 done:
310 for (i = 0; i < info->num_lvds; ++i) {
311 of_node_put(lvds_data[i].clkspec.np);
312 of_node_put(lvds_data[i].local);
313 of_node_put(lvds_data[i].remote);
314 }
315
316 of_node_put(soc_node);
317 of_node_put(du_node);
---
Thanks and regards,
Wen___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH V9 5/5] drm/mediatek: no change parent rate in round_rate() for mt2701 hdmi phy
From: Wangyan Wang
This is the third step to make MT2701 HDMI stable.
We should not change the rate of parent for hdmi phy when
doing round_rate for this clock. The parent clock of hdmi
phy must be the same as it. We change it when doing set_rate
only.
Signed-off-by: Wangyan Wang
---
drivers/gpu/drm/mediatek/mtk_hdmi_phy.c| 14 --
drivers/gpu/drm/mediatek/mtk_hdmi_phy.h| 2 --
drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c | 6 ++
drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c | 14 ++
4 files changed, 20 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi_phy.c
b/drivers/gpu/drm/mediatek/mtk_hdmi_phy.c
index 9e153e080739..e3a6b50e0cf2 100644
--- a/drivers/gpu/drm/mediatek/mtk_hdmi_phy.c
+++ b/drivers/gpu/drm/mediatek/mtk_hdmi_phy.c
@@ -15,20 +15,6 @@ static const struct phy_ops mtk_hdmi_phy_dev_ops = {
.owner = THIS_MODULE,
};
-long mtk_hdmi_pll_round_rate(struct clk_hw *hw, unsigned long rate,
-unsigned long *parent_rate)
-{
- struct mtk_hdmi_phy *hdmi_phy = to_mtk_hdmi_phy(hw);
-
- hdmi_phy->pll_rate = rate;
- if (rate <= 7425)
- *parent_rate = rate;
- else
- *parent_rate = rate / 2;
-
- return rate;
-}
-
void mtk_hdmi_phy_clear_bits(struct mtk_hdmi_phy *hdmi_phy, u32 offset,
u32 bits)
{
diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi_phy.h
b/drivers/gpu/drm/mediatek/mtk_hdmi_phy.h
index d28b8d5ed2b4..2d8b3182470d 100644
--- a/drivers/gpu/drm/mediatek/mtk_hdmi_phy.h
+++ b/drivers/gpu/drm/mediatek/mtk_hdmi_phy.h
@@ -49,8 +49,6 @@ void mtk_hdmi_phy_set_bits(struct mtk_hdmi_phy *hdmi_phy, u32
offset,
void mtk_hdmi_phy_mask(struct mtk_hdmi_phy *hdmi_phy, u32 offset,
u32 val, u32 mask);
struct mtk_hdmi_phy *to_mtk_hdmi_phy(struct clk_hw *hw);
-long mtk_hdmi_pll_round_rate(struct clk_hw *hw, unsigned long rate,
-unsigned long *parent_rate);
extern struct platform_driver mtk_hdmi_phy_driver;
extern struct mtk_hdmi_phy_conf mtk_hdmi_phy_8173_conf;
diff --git a/drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c
b/drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c
index b24ea6651db4..e3f05ad89b1e 100644
--- a/drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c
+++ b/drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c
@@ -106,6 +106,12 @@ static void mtk_hdmi_pll_unprepare(struct clk_hw *hw)
usleep_range(80, 100);
}
+static long mtk_hdmi_pll_round_rate(struct clk_hw *hw, unsigned long rate,
+ unsigned long *parent_rate)
+
+{
+ return rate;
+}
+
static int mtk_hdmi_pll_set_rate(struct clk_hw *hw, unsigned long rate,
unsigned long parent_rate)
{
diff --git a/drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c
b/drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c
index 625739b4e938..78c638c29102 100644
--- a/drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c
+++ b/drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c
@@ -199,6 +199,20 @@ static void mtk_hdmi_pll_unprepare(struct clk_hw *hw)
usleep_range(100, 150);
}
+long mtk_hdmi_pll_round_rate(struct clk_hw *hw, unsigned long rate,
+ unsigned long *parent_rate)
+
+{
+ struct mtk_hdmi_phy *hdmi_phy = to_mtk_hdmi_phy(hw);
+
+ hdmi_phy->pll_rate = rate;
+ if (rate <= 7425)
+ *parent_rate = rate;
+ else
+ *parent_rate = rate / 2;
+
+ return rate;
+}
+
static int mtk_hdmi_pll_set_rate(struct clk_hw *hw, unsigned long rate,
unsigned long parent_rate)
{
--
2.14.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH V9 4/5] drm/mediatek: make implementation of recalc_rate() to match the definition
From: Wangyan Wang
Recalculate the rate of this clock, by querying hardware to
make implementation of recalc_rate() to match the definition.
Signed-off-by: Wangyan Wang
---
drivers/gpu/drm/mediatek/mtk_hdmi_phy.c| 8 --
drivers/gpu/drm/mediatek/mtk_hdmi_phy.h| 2 --
drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c | 39 +++---
drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c | 8 ++
4 files changed, 43 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi_phy.c
b/drivers/gpu/drm/mediatek/mtk_hdmi_phy.c
index 0879ce47d4c5..9e153e080739 100644
--- a/drivers/gpu/drm/mediatek/mtk_hdmi_phy.c
+++ b/drivers/gpu/drm/mediatek/mtk_hdmi_phy.c
@@ -29,14 +29,6 @@ long mtk_hdmi_pll_round_rate(struct clk_hw *hw, unsigned
long rate,
return rate;
}
-unsigned long mtk_hdmi_pll_recalc_rate(struct clk_hw *hw,
- unsigned long parent_rate)
-{
- struct mtk_hdmi_phy *hdmi_phy = to_mtk_hdmi_phy(hw);
-
- return hdmi_phy->pll_rate;
-}
-
void mtk_hdmi_phy_clear_bits(struct mtk_hdmi_phy *hdmi_phy, u32 offset,
u32 bits)
{
diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi_phy.h
b/drivers/gpu/drm/mediatek/mtk_hdmi_phy.h
index 0045824c1be9..d28b8d5ed2b4 100644
--- a/drivers/gpu/drm/mediatek/mtk_hdmi_phy.h
+++ b/drivers/gpu/drm/mediatek/mtk_hdmi_phy.h
@@ -51,8 +51,6 @@ void mtk_hdmi_phy_mask(struct mtk_hdmi_phy *hdmi_phy, u32
offset,
struct mtk_hdmi_phy *to_mtk_hdmi_phy(struct clk_hw *hw);
long mtk_hdmi_pll_round_rate(struct clk_hw *hw, unsigned long rate,
unsigned long *parent_rate);
-unsigned long mtk_hdmi_pll_recalc_rate(struct clk_hw *hw,
- unsigned long parent_rate);
extern struct platform_driver mtk_hdmi_phy_driver;
extern struct mtk_hdmi_phy_conf mtk_hdmi_phy_8173_conf;
diff --git a/drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c
b/drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c
index 844e622f052c..b24ea6651db4 100644
--- a/drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c
+++ b/drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c
@@ -79,7 +79,6 @@ static int mtk_hdmi_pll_prepare(struct clk_hw *hw)
mtk_hdmi_phy_set_bits(hdmi_phy, HDMI_CON0, RG_HDMITX_EN_SLDO_MASK);
usleep_range(80, 100);
mtk_hdmi_phy_set_bits(hdmi_phy, HDMI_CON2, RG_HDMITX_MBIAS_LPF_EN);
- mtk_hdmi_phy_set_bits(hdmi_phy, HDMI_CON2, RG_HDMITX_EN_TX_POSDIV);
mtk_hdmi_phy_set_bits(hdmi_phy, HDMI_CON0, RG_HDMITX_EN_SER_MASK);
mtk_hdmi_phy_set_bits(hdmi_phy, HDMI_CON0, RG_HDMITX_EN_PRED_MASK);
mtk_hdmi_phy_set_bits(hdmi_phy, HDMI_CON0, RG_HDMITX_EN_DRV_MASK);
@@ -94,7 +93,6 @@ static void mtk_hdmi_pll_unprepare(struct clk_hw *hw)
mtk_hdmi_phy_clear_bits(hdmi_phy, HDMI_CON0, RG_HDMITX_EN_DRV_MASK);
mtk_hdmi_phy_clear_bits(hdmi_phy, HDMI_CON0, RG_HDMITX_EN_PRED_MASK);
mtk_hdmi_phy_clear_bits(hdmi_phy, HDMI_CON0, RG_HDMITX_EN_SER_MASK);
- mtk_hdmi_phy_clear_bits(hdmi_phy, HDMI_CON2, RG_HDMITX_EN_TX_POSDIV);
mtk_hdmi_phy_clear_bits(hdmi_phy, HDMI_CON2, RG_HDMITX_MBIAS_LPF_EN);
usleep_range(80, 100);
mtk_hdmi_phy_clear_bits(hdmi_phy, HDMI_CON0, RG_HDMITX_EN_SLDO_MASK);
@@ -123,6 +121,7 @@ static int mtk_hdmi_pll_set_rate(struct clk_hw *hw,
unsigned long rate,
mtk_hdmi_phy_set_bits(hdmi_phy, HDMI_CON6, RG_HTPLL_PREDIV_MASK);
mtk_hdmi_phy_set_bits(hdmi_phy, HDMI_CON6, RG_HTPLL_POSDIV_MASK);
+ mtk_hdmi_phy_set_bits(hdmi_phy, HDMI_CON2, RG_HDMITX_EN_TX_POSDIV);
mtk_hdmi_phy_mask(hdmi_phy, HDMI_CON6, (0x1 << RG_HTPLL_IC),
RG_HTPLL_IC_MASK);
mtk_hdmi_phy_mask(hdmi_phy, HDMI_CON6, (0x1 << RG_HTPLL_IR),
@@ -154,6 +153,40 @@ static int mtk_hdmi_pll_set_rate(struct clk_hw *hw,
unsigned long rate,
return 0;
}
+static unsigned long mtk_hdmi_pll_recalc_rate(struct clk_hw *hw,
+ unsigned long parent_rate)
+
+{
+ struct mtk_hdmi_phy *hdmi_phy = to_mtk_hdmi_phy(hw);
+ unsigned long out_rate, val;
+
+ val = (readl(hdmi_phy->regs + HDMI_CON6)
+ & RG_HTPLL_PREDIV_MASK) >> RG_HTPLL_PREDIV;
+ switch (val) {
+ case 0x00:
+ out_rate = parent_rate;
+ break;
+ case 0x01:
+ out_rate = parent_rate / 2;
+ break;
+ default:
+ out_rate = parent_rate / 4;
+ break;
+ }
+
+ val = (readl(hdmi_phy->regs + HDMI_CON6)
+ & RG_HTPLL_FBKDIV_MASK) >> RG_HTPLL_FBKDIV;
+ out_rate *= (val + 1) * 2;
+ val = (readl(hdmi_phy->regs + HDMI_CON2)
+ & RG_HDMITX_TX_POSDIV_MASK);
+
+ out_rate >>= (val >> RG_HDMITX_TX_POSDIV);
+
+ if (readl(hdmi_phy->regs + HDMI_CON2) & RG_HDMITX_EN_TX_POSDIV)
+ out_rate = out_rate / 5;
+
+ return out_rate;
+}
+
Re: [PATCH v2] drm: rcar-du: fix possible object reference leak
> v2->v1: turn the return into a goto done. * The version identification can be shorter, can't it? * The expection handling should be completed for the implementation of the function “rcar_du_of_lvds_patch” in a different way. https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/drivers/gpu/drm/rcar-du/rcar_du_of.c?id=ac5b84a1ffe93c9fb882c0f2bdfac1c33077b920#n195 How do you think about to add a few jump targets (at the end)? Regards, Markus ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH V9 2/5] drm/mediatek: fix the rate and divder of hdmi phy for MT2701
From: Wangyan Wang
Due to a clerical error,there is one zero less for 1280.
Fix it for 12800
Fixes: 0fc721b2968e ("drm/mediatek: add hdmi driver for MT2701 and MT7623")
Reviewed-by: CK Hu
Signed-off-by: Wangyan Wang
---
drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c
b/drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c
index 67a814649e19..844e622f052c 100644
--- a/drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c
+++ b/drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c
@@ -116,8 +116,8 @@ static int mtk_hdmi_pll_set_rate(struct clk_hw *hw,
unsigned long rate,
if (rate <= 6400)
pos_div = 3;
- else if (rate <= 1280)
- pos_div = 1;
+ else if (rate <= 12800)
+ pos_div = 2;
else
pos_div = 1;
--
2.14.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH V10 4/5] drm/mediatek: make implementation of recalc_rate() to match the definition
From: Wangyan Wang
Recalculate the rate of this clock, by querying hardware to
make implementation of recalc_rate() to match the definition.
Signed-off-by: Wangyan Wang
---
drivers/gpu/drm/mediatek/mtk_hdmi_phy.c| 8 --
drivers/gpu/drm/mediatek/mtk_hdmi_phy.h| 2 --
drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c | 39 +++---
drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c | 8 ++
4 files changed, 43 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi_phy.c
b/drivers/gpu/drm/mediatek/mtk_hdmi_phy.c
index 0879ce47d4c5..9e153e080739 100644
--- a/drivers/gpu/drm/mediatek/mtk_hdmi_phy.c
+++ b/drivers/gpu/drm/mediatek/mtk_hdmi_phy.c
@@ -29,14 +29,6 @@ long mtk_hdmi_pll_round_rate(struct clk_hw *hw, unsigned
long rate,
return rate;
}
-unsigned long mtk_hdmi_pll_recalc_rate(struct clk_hw *hw,
- unsigned long parent_rate)
-{
- struct mtk_hdmi_phy *hdmi_phy = to_mtk_hdmi_phy(hw);
-
- return hdmi_phy->pll_rate;
-}
-
void mtk_hdmi_phy_clear_bits(struct mtk_hdmi_phy *hdmi_phy, u32 offset,
u32 bits)
{
diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi_phy.h
b/drivers/gpu/drm/mediatek/mtk_hdmi_phy.h
index 0045824c1be9..d28b8d5ed2b4 100644
--- a/drivers/gpu/drm/mediatek/mtk_hdmi_phy.h
+++ b/drivers/gpu/drm/mediatek/mtk_hdmi_phy.h
@@ -51,8 +51,6 @@ void mtk_hdmi_phy_mask(struct mtk_hdmi_phy *hdmi_phy, u32
offset,
struct mtk_hdmi_phy *to_mtk_hdmi_phy(struct clk_hw *hw);
long mtk_hdmi_pll_round_rate(struct clk_hw *hw, unsigned long rate,
unsigned long *parent_rate);
-unsigned long mtk_hdmi_pll_recalc_rate(struct clk_hw *hw,
- unsigned long parent_rate);
extern struct platform_driver mtk_hdmi_phy_driver;
extern struct mtk_hdmi_phy_conf mtk_hdmi_phy_8173_conf;
diff --git a/drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c
b/drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c
index 844e622f052c..b24ea6651db4 100644
--- a/drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c
+++ b/drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c
@@ -79,7 +79,6 @@ static int mtk_hdmi_pll_prepare(struct clk_hw *hw)
mtk_hdmi_phy_set_bits(hdmi_phy, HDMI_CON0, RG_HDMITX_EN_SLDO_MASK);
usleep_range(80, 100);
mtk_hdmi_phy_set_bits(hdmi_phy, HDMI_CON2, RG_HDMITX_MBIAS_LPF_EN);
- mtk_hdmi_phy_set_bits(hdmi_phy, HDMI_CON2, RG_HDMITX_EN_TX_POSDIV);
mtk_hdmi_phy_set_bits(hdmi_phy, HDMI_CON0, RG_HDMITX_EN_SER_MASK);
mtk_hdmi_phy_set_bits(hdmi_phy, HDMI_CON0, RG_HDMITX_EN_PRED_MASK);
mtk_hdmi_phy_set_bits(hdmi_phy, HDMI_CON0, RG_HDMITX_EN_DRV_MASK);
@@ -94,7 +93,6 @@ static void mtk_hdmi_pll_unprepare(struct clk_hw *hw)
mtk_hdmi_phy_clear_bits(hdmi_phy, HDMI_CON0, RG_HDMITX_EN_DRV_MASK);
mtk_hdmi_phy_clear_bits(hdmi_phy, HDMI_CON0, RG_HDMITX_EN_PRED_MASK);
mtk_hdmi_phy_clear_bits(hdmi_phy, HDMI_CON0, RG_HDMITX_EN_SER_MASK);
- mtk_hdmi_phy_clear_bits(hdmi_phy, HDMI_CON2, RG_HDMITX_EN_TX_POSDIV);
mtk_hdmi_phy_clear_bits(hdmi_phy, HDMI_CON2, RG_HDMITX_MBIAS_LPF_EN);
usleep_range(80, 100);
mtk_hdmi_phy_clear_bits(hdmi_phy, HDMI_CON0, RG_HDMITX_EN_SLDO_MASK);
@@ -123,6 +121,7 @@ static int mtk_hdmi_pll_set_rate(struct clk_hw *hw,
unsigned long rate,
mtk_hdmi_phy_set_bits(hdmi_phy, HDMI_CON6, RG_HTPLL_PREDIV_MASK);
mtk_hdmi_phy_set_bits(hdmi_phy, HDMI_CON6, RG_HTPLL_POSDIV_MASK);
+ mtk_hdmi_phy_set_bits(hdmi_phy, HDMI_CON2, RG_HDMITX_EN_TX_POSDIV);
mtk_hdmi_phy_mask(hdmi_phy, HDMI_CON6, (0x1 << RG_HTPLL_IC),
RG_HTPLL_IC_MASK);
mtk_hdmi_phy_mask(hdmi_phy, HDMI_CON6, (0x1 << RG_HTPLL_IR),
@@ -154,6 +153,40 @@ static int mtk_hdmi_pll_set_rate(struct clk_hw *hw,
unsigned long rate,
return 0;
}
+static unsigned long mtk_hdmi_pll_recalc_rate(struct clk_hw *hw,
+ unsigned long parent_rate)
+{
+ struct mtk_hdmi_phy *hdmi_phy = to_mtk_hdmi_phy(hw);
+ unsigned long out_rate, val;
+
+ val = (readl(hdmi_phy->regs + HDMI_CON6)
+ & RG_HTPLL_PREDIV_MASK) >> RG_HTPLL_PREDIV;
+ switch (val) {
+ case 0x00:
+ out_rate = parent_rate;
+ break;
+ case 0x01:
+ out_rate = parent_rate / 2;
+ break;
+ default:
+ out_rate = parent_rate / 4;
+ break;
+ }
+
+ val = (readl(hdmi_phy->regs + HDMI_CON6)
+ & RG_HTPLL_FBKDIV_MASK) >> RG_HTPLL_FBKDIV;
+ out_rate *= (val + 1) * 2;
+ val = (readl(hdmi_phy->regs + HDMI_CON2)
+ & RG_HDMITX_TX_POSDIV_MASK);
+
+ out_rate >>= (val >> RG_HDMITX_TX_POSDIV);
+
+ if (readl(hdmi_phy->regs + HDMI_CON2) & RG_HDMITX_EN_TX_POSDIV)
+ out_rate = out_rate / 5;
+
+ return out_rate;
+}
+
stati
[PATCH V9 3/5] drm/mediatek: using new factor for tvdpll in MT2701
From: Wangyan Wang
This is the second step to make MT2701 HDMI stable.
The factor depends on the divider of DPI in MT2701, therefore,
we should fix this factor to the right and new one.
Test: search ok
Reviewed-by: CK Hu
Signed-off-by: Wangyan Wang
---
drivers/gpu/drm/mediatek/mtk_dpi.c | 8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_dpi.c
b/drivers/gpu/drm/mediatek/mtk_dpi.c
index 69c6e42dad6b..4a2f4a650494 100644
--- a/drivers/gpu/drm/mediatek/mtk_dpi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dpi.c
@@ -662,13 +662,11 @@ static unsigned int mt8173_calculate_factor(int clock)
static unsigned int mt2701_calculate_factor(int clock)
{
if (clock <= 64000)
- return 16;
- else if (clock <= 128000)
- return 8;
- else if (clock <= 256000)
return 4;
- else
+ else if (clock <= 128000)
return 2;
+ else
+ return 1;
}
static const struct mtk_dpi_conf mt8173_conf = {
--
2.14.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH V10 3/5] drm/mediatek: using new factor for tvdpll in MT2701
From: Wangyan Wang
This is the second step to make MT2701 HDMI stable.
The factor depends on the divider of DPI in MT2701, therefore,
we should fix this factor to the right and new one.
Test: search ok
Reviewed-by: CK Hu
Signed-off-by: Wangyan Wang
---
drivers/gpu/drm/mediatek/mtk_dpi.c | 8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_dpi.c
b/drivers/gpu/drm/mediatek/mtk_dpi.c
index 69c6e42dad6b..4a2f4a650494 100644
--- a/drivers/gpu/drm/mediatek/mtk_dpi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dpi.c
@@ -662,13 +662,11 @@ static unsigned int mt8173_calculate_factor(int clock)
static unsigned int mt2701_calculate_factor(int clock)
{
if (clock <= 64000)
- return 16;
- else if (clock <= 128000)
- return 8;
- else if (clock <= 256000)
return 4;
- else
+ else if (clock <= 128000)
return 2;
+ else
+ return 1;
}
static const struct mtk_dpi_conf mt8173_conf = {
--
2.14.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 3/3] drm/panel: simple: Add support for VXT VL050-8048NT-C01 panel
On Mon, Apr 1, 2019 at 12:21 PM Fabio Estevam wrote: > On Mon, Feb 18, 2019 at 9:27 PM Fabio Estevam wrote: > > > > Add support for the VXT VL050-8048NT-C01 800x480 panel to the > > panel-simple driver. > > > > This panel is used on some boards manufactured by TechNexion, such as > > imx7d-pico. > > > > Reviewed-by: Otavio Salvador > > Reviewed-by: Sam Ravnborg > > Signed-off-by: Fabio Estevam > > Any feedback, please? > > Trying to get this one upstreamed for four months already and hope to > get it to 5.2. Any news on this? It has been waiting for review for a while. Is there someone else who could review this? -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://code.ossystems.com.br Mobile: +55 (53) 9 9981-7854 Mobile: +1 (347) 903-9750 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 07/12] arm64: dts: allwinner: orange-pi-3: Enable ethernet
On Mon, Apr 08, 2019 at 09:40:42AM +0200, Maxime Ripard wrote:
> On Sat, Apr 06, 2019 at 01:45:09AM +0200, meg...@megous.com wrote:
> > From: Ondrej Jirman
> >
> > Orange Pi 3 has two regulators that power the Realtek RTL8211E.
> > According to the phy datasheet, both regulators need to be enabled
> > at the same time, but we can only specify a single phy-supply in
> > the DT.
> >
> > This can be achieved by making one regulator depedning on the
> > other via vin-supply. While it's not a technically correct
> > description of the hardware, it achieves the purpose.
> >
> > All values of RX/TX delay were tested exhaustively and a middle
> > one of the working values was chosen.
> >
> > Signed-off-by: Ondrej Jirman
> > ---
> > .../dts/allwinner/sun50i-h6-orangepi-3.dts| 44 +++
> > 1 file changed, 44 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-3.dts
> > b/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-3.dts
> > index 644946749088..5270142527f5 100644
> > --- a/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-3.dts
> > +++ b/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-3.dts
> > @@ -15,6 +15,7 @@
> >
> > aliases {
> > serial0 = &uart0;
> > + ethernet0 = &emac;
> > };
> >
> > chosen {
> > @@ -64,6 +65,27 @@
> > regulator-max-microvolt = <500>;
> > regulator-always-on;
> > };
> > +
> > + /*
> > +* The board uses 2.5V RGMII signalling. Power sequence
> > +* to enable the phy is to enable GMAC-2V5 and GMAC-3V3 (aldo2)
> > +* power rails at the same time and to wait 100ms.
> > +*/
> > + reg_gmac_2v5: gmac-2v5 {
> > +compatible = "regulator-fixed";
> > +regulator-name = "gmac-2v5";
> > +regulator-min-microvolt = <250>;
> > +regulator-max-microvolt = <250>;
> > +startup-delay-us = <10>;
> > +enable-active-high;
> > +gpio = <&pio 3 6 GPIO_ACTIVE_HIGH>; /* PD6 */
>
> Is enable-active-high still needed? It's redundant with the
> GPIO_ACTIVE_HIGH flag.
Looking at the code, use/non-use of enable-active-high inhibits
flags specified in gpio property. So the GPIO_ACTIVE_HIGH flag
is ignored here (had GPIO_ACTIVE_LOW been used, the kernel would
ignore it too and print a warning).
So enable-active-high is still necessary here.
See comment in gpiolib-of.c where this is handled:
/*
* The regulator GPIO handles are specified such that the
* presence or absence of "enable-active-high" solely controls
* the polarity of the GPIO line. Any phandle flags must
* be actively ignored.
*/
regards,
o.
> The indentation is wrong here as well.
>
> Maxime
>
> --
> Maxime Ripard, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH V9 1/5] drm/mediatek: remove flag CLK_SET_RATE_PARENT for mt2701 hdmi phy to not propagate rate change to parent
From: Wangyan Wang
This is the first step to make MT2701 hdmi stable.
The parent rate of hdmi phy had set by DPI driver.
We should not set or change the parent rate of MT2701 hdmi phy,
as a result we should remove the flags of "CLK_SET_RATE_PARENT"
from the clock of MT2701 hdmi phy.
Signed-off-by: Wangyan Wang
---
drivers/gpu/drm/mediatek/mtk_hdmi_phy.c| 13 +
drivers/gpu/drm/mediatek/mtk_hdmi_phy.h| 1 +
drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c | 1 +
drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c | 1 +
4 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi_phy.c
b/drivers/gpu/drm/mediatek/mtk_hdmi_phy.c
index 4ef9c57ffd44..13bbaf997819 100644
--- a/drivers/gpu/drm/mediatek/mtk_hdmi_phy.c
+++ b/drivers/gpu/drm/mediatek/mtk_hdmi_phy.c
@@ -110,13 +110,11 @@ mtk_hdmi_phy_dev_get_ops(const struct mtk_hdmi_phy
*hdmi_phy)
return NULL;
}
-static void mtk_hdmi_phy_clk_get_ops(struct mtk_hdmi_phy *hdmi_phy,
-const struct clk_ops **ops)
+static void mtk_hdmi_phy_clk_get_data(struct mtk_hdmi_phy *hdmi_phy,
+ struct clk_init_data *clk_init)
{
- if (hdmi_phy && hdmi_phy->conf && hdmi_phy->conf->hdmi_phy_clk_ops)
- *ops = hdmi_phy->conf->hdmi_phy_clk_ops;
- else
- dev_err(hdmi_phy->dev, "Failed to get clk ops of phy\n");
+ clk_init->flags = hdmi_phy->conf->flags;
+ clk_init->ops = hdmi_phy->conf->hdmi_phy_clk_ops;
}
static int mtk_hdmi_phy_probe(struct platform_device *pdev)
@@ -129,7 +127,6 @@ static int mtk_hdmi_phy_probe(struct platform_device *pdev)
struct clk_init_data clk_init = {
.num_parents = 1,
.parent_names = (const char * const *)&ref_clk_name,
- .flags = CLK_SET_RATE_PARENT | CLK_SET_RATE_GATE,
};
struct phy *phy;
@@ -167,7 +164,7 @@ static int mtk_hdmi_phy_probe(struct platform_device *pdev)
hdmi_phy->dev = dev;
hdmi_phy->conf =
(struct mtk_hdmi_phy_conf *)of_device_get_match_data(dev);
- mtk_hdmi_phy_clk_get_ops(hdmi_phy, &clk_init.ops);
+ mtk_hdmi_phy_clk_get_data(hdmi_phy, &clk_init);
hdmi_phy->pll_hw.init = &clk_init;
hdmi_phy->pll = devm_clk_register(dev, &hdmi_phy->pll_hw);
if (IS_ERR(hdmi_phy->pll)) {
diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi_phy.h
b/drivers/gpu/drm/mediatek/mtk_hdmi_phy.h
index f39b1fc66612..0045824c1be9 100644
--- a/drivers/gpu/drm/mediatek/mtk_hdmi_phy.h
+++ b/drivers/gpu/drm/mediatek/mtk_hdmi_phy.h
@@ -21,6 +21,7 @@ struct mtk_hdmi_phy;
struct mtk_hdmi_phy_conf {
bool tz_disabled;
+ unsigned long flags;
const struct clk_ops *hdmi_phy_clk_ops;
void (*hdmi_phy_enable_tmds)(struct mtk_hdmi_phy *hdmi_phy);
void (*hdmi_phy_disable_tmds)(struct mtk_hdmi_phy *hdmi_phy);
diff --git a/drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c
b/drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c
index fcc42dc6ea7f..67a814649e19 100644
--- a/drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c
+++ b/drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c
@@ -202,6 +202,7 @@ static void mtk_hdmi_phy_disable_tmds(struct mtk_hdmi_phy
*hdmi_phy)
struct mtk_hdmi_phy_conf mtk_hdmi_phy_2701_conf = {
.tz_disabled = true,
+ .flags = CLK_SET_RATE_GATE,
.hdmi_phy_clk_ops = &mtk_hdmi_phy_pll_ops,
.hdmi_phy_enable_tmds = mtk_hdmi_phy_enable_tmds,
.hdmi_phy_disable_tmds = mtk_hdmi_phy_disable_tmds,
diff --git a/drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c
b/drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c
index ed5916b27658..f44066875dcd 100644
--- a/drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c
+++ b/drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c
@@ -309,6 +309,7 @@ static void mtk_hdmi_phy_disable_tmds(struct mtk_hdmi_phy
*hdmi_phy)
}
struct mtk_hdmi_phy_conf mtk_hdmi_phy_8173_conf = {
+ .flags = CLK_SET_RATE_PARENT | CLK_SET_RATE_GATE,
.hdmi_phy_clk_ops = &mtk_hdmi_phy_pll_ops,
.hdmi_phy_enable_tmds = mtk_hdmi_phy_enable_tmds,
.hdmi_phy_disable_tmds = mtk_hdmi_phy_disable_tmds,
--
2.14.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH V10 5/5] drm/mediatek: no change parent rate in round_rate() for mt2701 hdmi phy
From: Wangyan Wang
This is the third step to make MT2701 HDMI stable.
We should not change the rate of parent for hdmi phy when
doing round_rate for this clock. The parent clock of hdmi
phy must be the same as it. We change it when doing set_rate
only.
Signed-off-by: Wangyan Wang
---
drivers/gpu/drm/mediatek/mtk_hdmi_phy.c| 14 --
drivers/gpu/drm/mediatek/mtk_hdmi_phy.h| 2 --
drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c | 6 ++
drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c | 14 ++
4 files changed, 20 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi_phy.c
b/drivers/gpu/drm/mediatek/mtk_hdmi_phy.c
index 9e153e080739..e3a6b50e0cf2 100644
--- a/drivers/gpu/drm/mediatek/mtk_hdmi_phy.c
+++ b/drivers/gpu/drm/mediatek/mtk_hdmi_phy.c
@@ -15,20 +15,6 @@ static const struct phy_ops mtk_hdmi_phy_dev_ops = {
.owner = THIS_MODULE,
};
-long mtk_hdmi_pll_round_rate(struct clk_hw *hw, unsigned long rate,
-unsigned long *parent_rate)
-{
- struct mtk_hdmi_phy *hdmi_phy = to_mtk_hdmi_phy(hw);
-
- hdmi_phy->pll_rate = rate;
- if (rate <= 7425)
- *parent_rate = rate;
- else
- *parent_rate = rate / 2;
-
- return rate;
-}
-
void mtk_hdmi_phy_clear_bits(struct mtk_hdmi_phy *hdmi_phy, u32 offset,
u32 bits)
{
diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi_phy.h
b/drivers/gpu/drm/mediatek/mtk_hdmi_phy.h
index d28b8d5ed2b4..2d8b3182470d 100644
--- a/drivers/gpu/drm/mediatek/mtk_hdmi_phy.h
+++ b/drivers/gpu/drm/mediatek/mtk_hdmi_phy.h
@@ -49,8 +49,6 @@ void mtk_hdmi_phy_set_bits(struct mtk_hdmi_phy *hdmi_phy, u32
offset,
void mtk_hdmi_phy_mask(struct mtk_hdmi_phy *hdmi_phy, u32 offset,
u32 val, u32 mask);
struct mtk_hdmi_phy *to_mtk_hdmi_phy(struct clk_hw *hw);
-long mtk_hdmi_pll_round_rate(struct clk_hw *hw, unsigned long rate,
-unsigned long *parent_rate);
extern struct platform_driver mtk_hdmi_phy_driver;
extern struct mtk_hdmi_phy_conf mtk_hdmi_phy_8173_conf;
diff --git a/drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c
b/drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c
index b24ea6651db4..e3f05ad89b1e 100644
--- a/drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c
+++ b/drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c
@@ -106,6 +106,12 @@ static void mtk_hdmi_pll_unprepare(struct clk_hw *hw)
usleep_range(80, 100);
}
+static long mtk_hdmi_pll_round_rate(struct clk_hw *hw, unsigned long rate,
+unsigned long *parent_rate)
+{
+ return rate;
+}
+
static int mtk_hdmi_pll_set_rate(struct clk_hw *hw, unsigned long rate,
unsigned long parent_rate)
{
diff --git a/drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c
b/drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c
index 625739b4e938..78c638c29102 100644
--- a/drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c
+++ b/drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c
@@ -199,6 +199,20 @@ static void mtk_hdmi_pll_unprepare(struct clk_hw *hw)
usleep_range(100, 150);
}
+long mtk_hdmi_pll_round_rate(struct clk_hw *hw, unsigned long rate,
+ unsigned long *parent_rate)
+{
+ struct mtk_hdmi_phy *hdmi_phy = to_mtk_hdmi_phy(hw);
+
+ hdmi_phy->pll_rate = rate;
+ if (rate <= 7425)
+ *parent_rate = rate;
+ else
+ *parent_rate = rate / 2;
+
+ return rate;
+}
+
static int mtk_hdmi_pll_set_rate(struct clk_hw *hw, unsigned long rate,
unsigned long parent_rate)
{
--
2.14.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH V10 1/5] drm/mediatek: remove flag CLK_SET_RATE_PARENT for mt2701 hdmi phy to not propagate rate change to parent
From: Wangyan Wang
This is the first step to make MT2701 hdmi stable.
The parent rate of hdmi phy had set by DPI driver.
We should not set or change the parent rate of MT2701 hdmi phy,
as a result we should remove the flags of "CLK_SET_RATE_PARENT"
from the clock of MT2701 hdmi phy.
Signed-off-by: Wangyan Wang
---
drivers/gpu/drm/mediatek/mtk_hdmi_phy.c| 13 +
drivers/gpu/drm/mediatek/mtk_hdmi_phy.h| 1 +
drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c | 1 +
drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c | 1 +
4 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi_phy.c
b/drivers/gpu/drm/mediatek/mtk_hdmi_phy.c
index 4ef9c57ffd44..13bbaf997819 100644
--- a/drivers/gpu/drm/mediatek/mtk_hdmi_phy.c
+++ b/drivers/gpu/drm/mediatek/mtk_hdmi_phy.c
@@ -110,13 +110,11 @@ mtk_hdmi_phy_dev_get_ops(const struct mtk_hdmi_phy
*hdmi_phy)
return NULL;
}
-static void mtk_hdmi_phy_clk_get_ops(struct mtk_hdmi_phy *hdmi_phy,
-const struct clk_ops **ops)
+static void mtk_hdmi_phy_clk_get_data(struct mtk_hdmi_phy *hdmi_phy,
+ struct clk_init_data *clk_init)
{
- if (hdmi_phy && hdmi_phy->conf && hdmi_phy->conf->hdmi_phy_clk_ops)
- *ops = hdmi_phy->conf->hdmi_phy_clk_ops;
- else
- dev_err(hdmi_phy->dev, "Failed to get clk ops of phy\n");
+ clk_init->flags = hdmi_phy->conf->flags;
+ clk_init->ops = hdmi_phy->conf->hdmi_phy_clk_ops;
}
static int mtk_hdmi_phy_probe(struct platform_device *pdev)
@@ -129,7 +127,6 @@ static int mtk_hdmi_phy_probe(struct platform_device *pdev)
struct clk_init_data clk_init = {
.num_parents = 1,
.parent_names = (const char * const *)&ref_clk_name,
- .flags = CLK_SET_RATE_PARENT | CLK_SET_RATE_GATE,
};
struct phy *phy;
@@ -167,7 +164,7 @@ static int mtk_hdmi_phy_probe(struct platform_device *pdev)
hdmi_phy->dev = dev;
hdmi_phy->conf =
(struct mtk_hdmi_phy_conf *)of_device_get_match_data(dev);
- mtk_hdmi_phy_clk_get_ops(hdmi_phy, &clk_init.ops);
+ mtk_hdmi_phy_clk_get_data(hdmi_phy, &clk_init);
hdmi_phy->pll_hw.init = &clk_init;
hdmi_phy->pll = devm_clk_register(dev, &hdmi_phy->pll_hw);
if (IS_ERR(hdmi_phy->pll)) {
diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi_phy.h
b/drivers/gpu/drm/mediatek/mtk_hdmi_phy.h
index f39b1fc66612..0045824c1be9 100644
--- a/drivers/gpu/drm/mediatek/mtk_hdmi_phy.h
+++ b/drivers/gpu/drm/mediatek/mtk_hdmi_phy.h
@@ -21,6 +21,7 @@ struct mtk_hdmi_phy;
struct mtk_hdmi_phy_conf {
bool tz_disabled;
+ unsigned long flags;
const struct clk_ops *hdmi_phy_clk_ops;
void (*hdmi_phy_enable_tmds)(struct mtk_hdmi_phy *hdmi_phy);
void (*hdmi_phy_disable_tmds)(struct mtk_hdmi_phy *hdmi_phy);
diff --git a/drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c
b/drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c
index fcc42dc6ea7f..67a814649e19 100644
--- a/drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c
+++ b/drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c
@@ -202,6 +202,7 @@ static void mtk_hdmi_phy_disable_tmds(struct mtk_hdmi_phy
*hdmi_phy)
struct mtk_hdmi_phy_conf mtk_hdmi_phy_2701_conf = {
.tz_disabled = true,
+ .flags = CLK_SET_RATE_GATE,
.hdmi_phy_clk_ops = &mtk_hdmi_phy_pll_ops,
.hdmi_phy_enable_tmds = mtk_hdmi_phy_enable_tmds,
.hdmi_phy_disable_tmds = mtk_hdmi_phy_disable_tmds,
diff --git a/drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c
b/drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c
index ed5916b27658..f44066875dcd 100644
--- a/drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c
+++ b/drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c
@@ -309,6 +309,7 @@ static void mtk_hdmi_phy_disable_tmds(struct mtk_hdmi_phy
*hdmi_phy)
}
struct mtk_hdmi_phy_conf mtk_hdmi_phy_8173_conf = {
+ .flags = CLK_SET_RATE_PARENT | CLK_SET_RATE_GATE,
.hdmi_phy_clk_ops = &mtk_hdmi_phy_pll_ops,
.hdmi_phy_enable_tmds = mtk_hdmi_phy_enable_tmds,
.hdmi_phy_disable_tmds = mtk_hdmi_phy_disable_tmds,
--
2.14.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 08/12] arm64: dts: allwinner: h6: Add MMC1 pins
On Mon, Apr 08, 2019 at 09:43:27AM +0200, Maxime Ripard wrote:
> On Sat, Apr 06, 2019 at 01:45:10AM +0200, meg...@megous.com wrote:
> > From: Ondrej Jirman
> >
> > ---
> > arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi | 9 +
> > 1 file changed, 9 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
> > b/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
> > index 91fecab58836..dccad79da90c 100644
> > --- a/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
> > +++ b/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
> > @@ -238,6 +238,15 @@
> > bias-pull-up;
> > };
> >
> > +
>
> Extra line
>
> > + mmc1_pins: mmc1-pins {
> > + pins = "PG0", "PG1", "PG2", "PG3",
> > + "PG4", "PG5";
> > + function = "mmc1";
> > + drive-strength = <30>;
> > + bias-pull-up;
> > + };
> > +
>
> Is that the only muxing option?
I don't think so. I believe someone can use a 1-bit interface (bus-width = <1>),
and then some data pins will be free. This pinconfig is for 4-bit bus width
setup.
Though other SoCs (ex. H3, A83T) don't consider this possibility and make the
4-bit config the default pinctrl for mmc1. To add to the confusion, on these
SoCs 4-bit pinconf is the default, but 1bit bus-width is the (implicit) default.
This led to some confusion in the past.
So we can either:
- keep consistency with what is done elsewhere, and make this default, despite
not being the only option,
- or perhaps I can rename this to mmc1_bus_width4_pins, or somesuch, to make it
more explicit, and keep it non-default.
What do you think is better?
thank you and regards,
o.
> If so, then it should be assigned by default to mmc1
>
> Thanks!
> Maxime
>
> --
> Maxime Ripard, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RESEND PATCH v4 0/9] mm: Use vm_map_pages() and vm_map_pages_zero() API
Hi Andrew/ Michal, On Mon, Apr 1, 2019 at 10:56 AM Souptick Joarder wrote: > > Hi Andrew, > > On Tue, Mar 19, 2019 at 7:47 AM Souptick Joarder wrote: > > > > Previouly drivers have their own way of mapping range of > > kernel pages/memory into user vma and this was done by > > invoking vm_insert_page() within a loop. > > > > As this pattern is common across different drivers, it can > > be generalized by creating new functions and use it across > > the drivers. > > > > vm_map_pages() is the API which could be used to map > > kernel memory/pages in drivers which has considered vm_pgoff. > > > > vm_map_pages_zero() is the API which could be used to map > > range of kernel memory/pages in drivers which has not considered > > vm_pgoff. vm_pgoff is passed default as 0 for those drivers. > > > > We _could_ then at a later "fix" these drivers which are using > > vm_map_pages_zero() to behave according to the normal vm_pgoff > > offsetting simply by removing the _zero suffix on the function > > name and if that causes regressions, it gives us an easy way to revert. > > > > Tested on Rockchip hardware and display is working fine, including talking > > to Lima via prime. > > > > v1 -> v2: > > Few Reviewed-by. > > > > Updated the change log in [8/9] > > > > In [7/9], vm_pgoff is treated in V4L2 API as a 'cookie' > > to select a buffer, not as a in-buffer offset by design > > and it always want to mmap a whole buffer from its beginning. > > Added additional changes after discussing with Marek and > > vm_map_pages() could be used instead of vm_map_pages_zero(). > > > > v2 -> v3: > > Corrected the documentation as per review comment. > > > > As suggested in v2, renaming the interfaces to - > > *vm_insert_range() -> vm_map_pages()* and > > *vm_insert_range_buggy() -> vm_map_pages_zero()*. > > As the interface is renamed, modified the code accordingly, > > updated the change logs and modified the subject lines to use the > > new interfaces. There is no other change apart from renaming and > > using the new interface. > > > > Patch[1/9] & [4/9], Tested on Rockchip hardware. > > > > v3 -> v4: > > Fixed build warnings on patch [8/9] reported by kbuild test robot. > > > > Souptick Joarder (9): > > mm: Introduce new vm_map_pages() and vm_map_pages_zero() API > > arm: mm: dma-mapping: Convert to use vm_map_pages() > > drivers/firewire/core-iso.c: Convert to use vm_map_pages_zero() > > drm/rockchip/rockchip_drm_gem.c: Convert to use vm_map_pages() > > drm/xen/xen_drm_front_gem.c: Convert to use vm_map_pages() > > iommu/dma-iommu.c: Convert to use vm_map_pages() > > videobuf2/videobuf2-dma-sg.c: Convert to use vm_map_pages() > > xen/gntdev.c: Convert to use vm_map_pages() > > xen/privcmd-buf.c: Convert to use vm_map_pages_zero() > > Is it fine to take these patches into mm tree for regression ? v4 of this series has not received any further comments/ kbuild error in last 8 weeks (including the previously posted v4). Any suggestion, if it safe to take these changes through mm tree ? or any other tree is preferred ? > > > > > arch/arm/mm/dma-mapping.c | 22 ++ > > drivers/firewire/core-iso.c| 15 +--- > > drivers/gpu/drm/rockchip/rockchip_drm_gem.c| 17 + > > drivers/gpu/drm/xen/xen_drm_front_gem.c| 18 ++--- > > drivers/iommu/dma-iommu.c | 12 +--- > > drivers/media/common/videobuf2/videobuf2-core.c| 7 ++ > > .../media/common/videobuf2/videobuf2-dma-contig.c | 6 -- > > drivers/media/common/videobuf2/videobuf2-dma-sg.c | 22 ++ > > drivers/xen/gntdev.c | 11 ++- > > drivers/xen/privcmd-buf.c | 8 +-- > > include/linux/mm.h | 4 ++ > > mm/memory.c| 81 > > ++ > > mm/nommu.c | 14 > > 13 files changed, 134 insertions(+), 103 deletions(-) > > > > -- > > 1.9.1 > > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH RFC tip/core/rcu 0/4] Forbid static SRCU use in modules
- On Apr 8, 2019, at 10:22 AM, paulmck paul...@linux.ibm.com wrote: > On Mon, Apr 08, 2019 at 09:05:34AM -0400, Mathieu Desnoyers wrote: >> - On Apr 7, 2019, at 10:27 PM, paulmck paul...@linux.ibm.com wrote: >> >> > On Sun, Apr 07, 2019 at 09:07:18PM +, Joel Fernandes wrote: >> >> On Sun, Apr 07, 2019 at 04:41:36PM -0400, Mathieu Desnoyers wrote: >> >> > >> >> > - On Apr 7, 2019, at 3:32 PM, Joel Fernandes, Google >> >> > j...@joelfernandes.org >> >> > wrote: >> >> > >> >> > > On Sun, Apr 07, 2019 at 03:26:16PM -0400, Mathieu Desnoyers wrote: >> >> > >> - On Apr 7, 2019, at 9:59 AM, paulmck paul...@linux.ibm.com >> >> > >> wrote: >> >> > >> >> >> > >> > On Sun, Apr 07, 2019 at 06:39:41AM -0700, Paul E. McKenney wrote: >> >> > >> >> On Sat, Apr 06, 2019 at 07:06:13PM -0400, Joel Fernandes wrote: >> >> > >> > >> >> > >> > [ . . . ] >> >> > >> > >> >> > >> >> > > diff --git a/include/asm-generic/vmlinux.lds.h >> >> > >> >> > > b/include/asm-generic/vmlinux.lds.h >> >> > >> >> > > index f8f6f04c4453..c2d919a1566e 100644 >> >> > >> >> > > --- a/include/asm-generic/vmlinux.lds.h >> >> > >> >> > > +++ b/include/asm-generic/vmlinux.lds.h >> >> > >> >> > > @@ -338,6 +338,10 @@ >> >> > >> >> > > KEEP(*(__tracepoints_ptrs)) /* Tracepoints: >> >> > >> >> > > pointer array */ \ >> >> > >> >> > > __stop___tracepoints_ptrs = .; >> >> > >> >> > > \ >> >> > >> >> > > *(__tracepoints_strings)/* Tracepoints: strings >> >> > >> >> > > */ \ >> >> > >> >> > > + . = ALIGN(8); >> >> > >> >> > > \ >> >> > >> >> > > + __start___srcu_struct = .; >> >> > >> >> > > \ >> >> > >> >> > > + *(___srcu_struct_ptrs) >> >> > >> >> > > \ >> >> > >> >> > > + __end___srcu_struct = .; >> >> > >> >> > > \ >> >> > >> >> > > } >> >> > >> >> > > \ >> >> > >> >> > >> >> > >> >> > This vmlinux linker modification is not needed. I tested >> >> > >> >> > without it and srcu >> >> > >> >> > torture works fine with rcutorture built as a module. Putting >> >> > >> >> > further prints >> >> > >> >> > in kernel/module.c verified that the kernel is able to find the >> >> > >> >> > srcu structs >> >> > >> >> > just fine. You could squash the below patch into this one or >> >> > >> >> > apply it on top >> >> > >> >> > of the dev branch. >> >> > >> >> >> >> > >> >> Good point, given that otherwise FORTRAN named common blocks >> >> > >> >> would not >> >> > >> >> work. >> >> > >> >> >> >> > >> >> But isn't one advantage of leaving that stuff in the >> >> > >> >> RO_DATA_SECTION() >> >> > >> >> macro that it can be mapped read-only? Or am I suffering from >> >> > >> >> excessive >> >> > >> >> optimism? >> >> > >> > >> >> > >> > And to answer the other question, in the case where I am suffering >> >> > >> > from >> >> > >> > excessive optimism, it should be a separate commit. Please see >> >> > >> > below >> >> > >> > for the updated original commit thus far. >> >> > >> > >> >> > >> > And may I have your Tested-by? >> >> > >> >> >> > >> Just to confirm: does the cleanup performed in the modules going >> >> > >> notifier end up acting as a barrier first before freeing the memory ? >> >> > >> If not, is it explicitly stated that a barrier must be issued before >> >> > >> module unload ? >> >> > >> >> >> > > >> >> > > You mean rcu_barrier? It is mentioned in the documentation that this >> >> > > is the >> >> > > responsibility of the module writer to prevent delays for all modules. >> >> > >> >> > It's a srcu barrier yes. Considering it would be a barrier specific to >> >> > the >> >> > srcu domain within that module, I don't see how it would cause delays >> >> > for >> >> > "all" modules if we implicitly issue the barrier on module unload. What >> >> > am I missing ? >> >> >> >> Yes you are right. I thought of this after I just sent my email. I think >> >> it >> >> makes sense for srcu case to do and could avoid a class of bugs. >> > >> > If there are call_srcu() callbacks outstanding, the module writer still >> > needs the srcu_barrier() because otherwise callbacks arrive after >> > the module text has gone, which will be disappoint the CPU when it >> > tries fetching instructions that are no longer mapped. If there are >> > no call_srcu() callbacks from that module, then there is no need for >> > srcu_barrier() either way. >> > >> > So if an srcu_barrier() is needed, the module developer needs to >> > supply it. >> >> When you say "callbacks arrive after the module text has gone", >> I think you assume that free_module() is invoked before the >> MODULE_STATE_GOING notifiers are called. But it's done in the >> opposite order: going notifiers are called first, and then >> free_module()
[PATCH v2 01/13] dt-bindings: sunxi: Add compatible for OrangePi 3 board
From: Ondrej Jirman Add new Xunlong Orange Pi 3 board compatible string to the bindings documentation. Signed-off-by: Ondrej Jirman --- Documentation/devicetree/bindings/arm/sunxi.yaml | 5 + 1 file changed, 5 insertions(+) diff --git a/Documentation/devicetree/bindings/arm/sunxi.yaml b/Documentation/devicetree/bindings/arm/sunxi.yaml index 11563d3f7c65..b82db740125b 100644 --- a/Documentation/devicetree/bindings/arm/sunxi.yaml +++ b/Documentation/devicetree/bindings/arm/sunxi.yaml @@ -711,6 +711,11 @@ properties: - const: xunlong,orangepi-2 - const: allwinner,sun8i-h3 + - description: Xunlong OrangePi 3 +items: + - const: xunlong,orangepi-3 + - const: allwinner,sun50i-h6 + - description: Xunlong OrangePi Lite items: - const: xunlong,orangepi-lite -- 2.21.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] drm: rcar-du: fix possible object reference leak
On 4/8/2019 8:28 AM, Wen Yang wrote:
The call to of_get_parent returns a node pointer with refcount
incremented thus it must be explicitly decremented after the last
usage.
Detected by coccinelle with the following warnings:
drivers/gpu/drm/rcar-du/rcar_du_of.c:235:2-8: ERROR: missing of_node_put;
acquired a node pointer with refcount incremented on line 216, but without a
corresponding object release within this function.
drivers/gpu/drm/rcar-du/rcar_du_of.c:236:2-8: ERROR: missing of_node_put;
acquired a node pointer with refcount incremented on line 209, but without a
corresponding object release within this function.
Signed-off-by: Wen Yang
Suggested-by: Laurent Pinchart
Cc: Laurent Pinchart
Cc: Kieran Bingham
Cc: David Airlie
Cc: Daniel Vetter
Cc: dri-devel@lists.freedesktop.org
Cc: linux-renesas-...@vger.kernel.org
Cc: linux-ker...@vger.kernel.org (open list)
---
v2->v1: turn the return into a goto done.
drivers/gpu/drm/rcar-du/rcar_du_of.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_of.c
b/drivers/gpu/drm/rcar-du/rcar_du_of.c
index afef696..782bfc7 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_of.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_of.c
@@ -232,7 +232,7 @@ static void __init rcar_du_of_lvds_patch(const struct
of_device_id *of_ids)
lvds_node = of_find_compatible_node(NULL, NULL, compatible);
if (lvds_node) {
of_node_put(lvds_node);
- return;
+ goto done;
}
you might have to create multiple level to do handling it.. there are
unnecessary put being done on "done" which is not valid
for this case.
-Mukesh
/*
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 00/15] Share TTM code among framebuffer drivers
Hi, > > The qemu stdvga (bochs driver) has 16 MB vram by default and can be > > configured to have up to 256 MB. Plenty of room even for multiple 4k > > framebuffers if needed. So for the bochs driver all the ttm bo > > migration logic is not needed, it could just store everything in vram. > > To clarify I assume you mean it doesn't need the migrate each bo > logic, but it still needs the when VRAM fills up migrate stuff logic. I think even the "when vram fills up" logic isn't that important. The driver has no acceleration so there is nothing to store beside dumb framebuffers, and the vram size can easily be increased if needed. cheers, Gerd ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [linux-sunxi] [PATCH v2 02/13] arm64: dts: allwinner: h6: Add Orange Pi 3 DTS
Based on the conversation about using common dtsi from this thread[1],
I'm commenting here to make show the diff directly on the nodes,
giving comments on each node so-that we can see the diff globally.
On Tue, Apr 9, 2019 at 5:55 AM megous via linux-sunxi
wrote:
>
> From: Ondrej Jirman
>
> Orange Pi 3 is a H6 based SBC made by Xulong, released in January 2019. It
> has the following features:
>
> - Allwinner H6 quad-core 64-bit ARM Cortex-A53
> - GPU Mali-T720
> - 1GB or 2GB LPDDR3 RAM
> - AXP805 PMIC
> - AP6256 Wifi/BT 5.0
> - USB 2.0 host port (A)
> - USB 2.0 micro usb, OTG
> - USB 3.0 Host + 4 port USB hub (GL3510)
> - Gigabit Ethernet (Realtek RTL8211E phy)
> - HDMI 2.0 port
> - soldered eMMC (optional)
> - 3x LED (one is on the bottom)
> - microphone
> - audio jack
> - PCIe
>
> Add basic support for the board.
>
> Signed-off-by: Ondrej Jirman
> ---
> arch/arm64/boot/dts/allwinner/Makefile| 1 +
> .../dts/allwinner/sun50i-h6-orangepi-3.dts| 216 ++
> 2 files changed, 217 insertions(+)
> create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-3.dts
>
> diff --git a/arch/arm64/boot/dts/allwinner/Makefile
> b/arch/arm64/boot/dts/allwinner/Makefile
> index e4dce2f6fa3a..285a7cb5135b 100644
> --- a/arch/arm64/boot/dts/allwinner/Makefile
> +++ b/arch/arm64/boot/dts/allwinner/Makefile
> @@ -20,6 +20,7 @@ dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h5-orangepi-pc2.dtb
> dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h5-orangepi-prime.dtb
> dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h5-orangepi-zero-plus.dtb
> dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h5-orangepi-zero-plus2.dtb
> +dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h6-orangepi-3.dtb
> dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h6-orangepi-lite2.dtb
> dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h6-orangepi-one-plus.dtb
> dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h6-pine-h64.dtb
> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-3.dts
> b/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-3.dts
> new file mode 100644
> index ..5fbc5e410883
> --- /dev/null
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-3.dts
> @@ -0,0 +1,216 @@
> +// SPDX-License-Identifier: (GPL-2.0+ or MIT)
> +/*
> + * Copyright (C) 2019 Ondřej Jirman
> + */
> +
> +/dts-v1/;
> +
> +#include "sun50i-h6.dtsi"
> +
> +#include
> +
> +/ {
> + model = "OrangePi 3";
> + compatible = "xunlong,orangepi-3", "allwinner,sun50i-h6";
> +
> + aliases {
> + serial0 = &uart0;
> + };
> +
> + chosen {
> + stdout-path = "serial0:115200n8";
> + };
> +
> + leds {
> + compatible = "gpio-leds";
> +
> + power {
> + label = "orangepi:red:power";
> + gpios = <&r_pio 0 4 GPIO_ACTIVE_HIGH>; /* PL4 */
> + default-state = "on";
> + };
> +
> + status {
> + label = "orangepi:green:status";
> + gpios = <&r_pio 0 7 GPIO_ACTIVE_HIGH>; /* PL7 */
> + };
> + };
> +
> + reg_vcc5v: vcc5v {
> + /* board wide 5V supply directly from the DC jack */
> + compatible = "regulator-fixed";
> + regulator-name = "vcc-5v";
> + regulator-min-microvolt = <500>;
> + regulator-max-microvolt = <500>;
> + regulator-always-on;
> + };
> +};
all above nodes are common to all h6 opi boards.
> +
> +&cpu0 {
> + cpu-supply = <®_dcdca>;
> +};
> +
> +&ehci0 {
> + status = "okay";
> +};
> +
> +&ehci3 {
> + status = "okay";
> +};
common to all h6 opi boards.
> +
> +&mmc0 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&mmc0_pins>;
> + vmmc-supply = <®_cldo1>;
> + cd-gpios = <&pio 5 6 GPIO_ACTIVE_LOW>; /* PF6 */
> + bus-width = <4>;
> + status = "okay";
> +};
common to all h6 opi boards.
> +
> +&ohci0 {
> + status = "okay";
> +};
> +
> +&ohci3 {
> + status = "okay";
> +};
common to all h6 opi boards.
> +
> +&pio {
> + vcc-pc-supply = <®_bldo2>;
> + vcc-pd-supply = <®_cldo1>;
> +};
> +
> +&r_i2c {
> + status = "okay";
> +
> + axp805: pmic@36 {
> + compatible = "x-powers,axp805", "x-powers,axp806";
> + reg = <0x36>;
> + interrupt-parent = <&r_intc>;
> + interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
> + interrupt-controller;
> + #interrupt-cells = <1>;
> + x-powers,self-working-mode;
> + vina-supply = <®_vcc5v>;
> + vinb-supply = <®_vcc5v>;
> + vinc-supply = <®_vcc5v>;
> + vind-supply = <®_vcc5v>;
> + vine-supply = <®_vcc5v>;
> + aldoin-supply = <®_vcc5v>;
> + bldoin-supply = <®_vcc5v>;
> + cldoin-supply = <®_vcc5v>;
all these supply voltage regulators are common to h6 opi boards.
> +
>
Re: [PATCH v2 05/13] pinctrl: sunxi: Prepare for alternative bias voltage setting methods
Hi,
On Tue, Apr 09, 2019 at 02:24:44AM +0200, meg...@megous.com wrote:
> From: Ondrej Jirman
>
> H6 has a different I/O voltage bias setting method than A80. Prepare
> existing code for using alternative bias voltage setting methods.
>
> Signed-off-by: Ondrej Jirman
> ---
> drivers/pinctrl/sunxi/pinctrl-sun9i-a80.c | 2 +-
> drivers/pinctrl/sunxi/pinctrl-sunxi.c | 41 +--
> drivers/pinctrl/sunxi/pinctrl-sunxi.h | 5 ++-
> 3 files changed, 28 insertions(+), 20 deletions(-)
>
> diff --git a/drivers/pinctrl/sunxi/pinctrl-sun9i-a80.c
> b/drivers/pinctrl/sunxi/pinctrl-sun9i-a80.c
> index da37d594a13d..3aa210079b18 100644
> --- a/drivers/pinctrl/sunxi/pinctrl-sun9i-a80.c
> +++ b/drivers/pinctrl/sunxi/pinctrl-sun9i-a80.c
> @@ -722,7 +722,7 @@ static const struct sunxi_pinctrl_desc
> sun9i_a80_pinctrl_data = {
> .npins = ARRAY_SIZE(sun9i_a80_pins),
> .irq_banks = 5,
> .disable_strict_mode = true,
> - .has_io_bias_cfg = true,
> + .io_bias_cfg_variant = IO_BIAS_CFG_V1,
> };
>
> static int sun9i_a80_pinctrl_probe(struct platform_device *pdev)
> diff --git a/drivers/pinctrl/sunxi/pinctrl-sunxi.c
> b/drivers/pinctrl/sunxi/pinctrl-sunxi.c
> index 8dd25caea2cf..b8dd58ef33b7 100644
> --- a/drivers/pinctrl/sunxi/pinctrl-sunxi.c
> +++ b/drivers/pinctrl/sunxi/pinctrl-sunxi.c
> @@ -610,7 +610,7 @@ static int sunxi_pinctrl_set_io_bias_cfg(struct
> sunxi_pinctrl *pctl,
> u32 val, reg;
> int uV;
>
> - if (!pctl->desc->has_io_bias_cfg)
> + if (!pctl->desc->io_bias_cfg_variant)
> return 0;
>
> uV = regulator_get_voltage(supply);
> @@ -621,23 +621,28 @@ static int sunxi_pinctrl_set_io_bias_cfg(struct
> sunxi_pinctrl *pctl,
> if (uV == 0)
> return 0;
>
> - /* Configured value must be equal or greater to actual voltage */
> - if (uV <= 180)
> - val = 0x0; /* 1.8V */
> - else if (uV <= 250)
> - val = 0x6; /* 2.5V */
> - else if (uV <= 280)
> - val = 0x9; /* 2.8V */
> - else if (uV <= 300)
> - val = 0xA; /* 3.0V */
> - else
> - val = 0xD; /* 3.3V */
> -
> - pin -= pctl->desc->pin_base;
> -
> - reg = readl(pctl->membase + sunxi_grp_config_reg(pin));
> - reg &= ~IO_BIAS_MASK;
> - writel(reg | val, pctl->membase + sunxi_grp_config_reg(pin));
> + if (pctl->desc->io_bias_cfg_variant == IO_BIAS_CFG_V1) {
> + /*
> + * Configured value must be equal or greater to actual
> + * voltage.
> + */
> + if (uV <= 180)
> + val = 0x0; /* 1.8V */
> + else if (uV <= 250)
> + val = 0x6; /* 2.5V */
> + else if (uV <= 280)
> + val = 0x9; /* 2.8V */
> + else if (uV <= 300)
> + val = 0xA; /* 3.0V */
> + else
> + val = 0xD; /* 3.3V */
> +
> + pin -= pctl->desc->pin_base;
> +
> + reg = readl(pctl->membase + sunxi_grp_config_reg(pin));
> + reg &= ~IO_BIAS_MASK;
> + writel(reg | val, pctl->membase + sunxi_grp_config_reg(pin));
> + }
>
> return 0;
> }
> diff --git a/drivers/pinctrl/sunxi/pinctrl-sunxi.h
> b/drivers/pinctrl/sunxi/pinctrl-sunxi.h
> index ee15ab067b5f..642f667e99d2 100644
> --- a/drivers/pinctrl/sunxi/pinctrl-sunxi.h
> +++ b/drivers/pinctrl/sunxi/pinctrl-sunxi.h
> @@ -95,6 +95,9 @@
> #define PINCTRL_SUN7I_A20BIT(7)
> #define PINCTRL_SUN8I_R40BIT(8)
>
> +/* Bias voltage configuration done via Pn_GRP_CONFIG registers. */
> +#define IO_BIAS_CFG_V1 1
> +
Can we turn this into an enum, and give them proper name? Mentionning
an example in the commit would be great too.
Something like:
enum sunxi_desc_bias_voltage {
/* Bias Voltage configuration is done through Pn_GRP_CONFIG registers,
as seen on the A83t */
BIAS_VOLTAGE_GRP_CONFIG,
};
etc.
Thanks!
Maxime
--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/qxl: drop prime import/export callbacks
Hi, > > Should we add something like DRM_PRIME_CAP_SAME_DEVICE? > > Yeah I expect we need some sort of same device only capability, so > that dri3 userspace can work. > > If we just fail importing in these cases what happens? userspace just > gets confused, I know we used to print a backtrace if we hit the mmap > path, but if we didn't do that what happens? Well, we printed a backtrace and returned -EINVAL. So it looked a bit scary due to the backtrace which is usually printed for more serious problems. But we also returned a proper error code. Userspace was not happy. It was wayland (gnome-shell) which ran into it it, and it didn't came up with a working display. cheers, Gerd ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 00/11] drm/meson: Add G12A Support
Hi, On 09/04/2019 10:42, Jerome Brunet wrote: > On Mon, 2019-03-25 at 15:18 +0100, Neil Armstrong wrote: >> The Amlogic G12A SoC offers very close Video Display >> functionnalities with it's older GXBB, GXL & GXM predecessors. >> >> The main differences are : >> - G12A Support now 3 "real" OSD planes with a new Blender module >> - Instead of having a single Scaler for OSD1, G12A has two scaler >> that can be applied to 2 out of the 3 OSD planes or on the outputs >> of the blender module. >> - The HDMI PHY now support RX-SENSE, Dynamic HDR and it's registers are >> now memory mapped instead of using an internal bus. >> - The VPU now support a DSI interface to connect a display, using >> the Synopsys DSI controller and a custom PHY >> >> The complex Blender routing, HDMI RX-SENSE, Dynamic HDR and DSI support >> are not handled in this patchset. >> >> This patchset implements on-par support with the currently support >> GXBB, GXL and GXM SoCs. There is no support delta with this patchset. >> >> patch 10 & 11 implements the bindings found at [1]. >> >> [1] https://lkml.kernel.org/r/20190313141030.5958-1-narmstr...@baylibre.com >> >> Neil Armstrong (11): >> drm/meson: Switch PLL to 5.94GHz base for 297Mhz pixel clock >> drm/meson: Add registers for G12A SoC >> drm/meson: Add G12A Support for VPP setup >> drm/meson: Add G12A Support for VIU setup >> drm/meson: Add G12A support for OSD1 Plane >> drm/meson: Add G12A Support for the Overlay video plane >> drm/meson: Add G12A support for plane handling in CRTC driver >> drm/meson: Add G12A support for CVBS Encoer >> drm/meson: Add G12A Video Clock setup >> drm/meson: Add G12A compatible >> drm/meson: Add G12A support for the DW-HDMI Glue >> >> drivers/gpu/drm/meson/meson_crtc.c | 269 +++- >> drivers/gpu/drm/meson/meson_drv.c | 1 + >> drivers/gpu/drm/meson/meson_drv.h | 4 + >> drivers/gpu/drm/meson/meson_dw_hdmi.c | 163 +++--- >> drivers/gpu/drm/meson/meson_dw_hdmi.h | 32 ++- >> drivers/gpu/drm/meson/meson_overlay.c | 10 +- >> drivers/gpu/drm/meson/meson_plane.c | 15 +- >> drivers/gpu/drm/meson/meson_registers.h | 247 ++ >> drivers/gpu/drm/meson/meson_vclk.c | 123 +-- >> drivers/gpu/drm/meson/meson_venc.c | 11 +- >> drivers/gpu/drm/meson/meson_venc_cvbs.c | 25 ++- >> drivers/gpu/drm/meson/meson_viu.c | 72 ++- >> drivers/gpu/drm/meson/meson_vpp.c | 51 +++-- >> 13 files changed, 880 insertions(+), 143 deletions(-) >> > > on the u200 and sei510 > Tested-by: Jerome Brunet > > I can't pretend to have a deep understanding of this subsystem, but as far as > I can tell, there is nothing crazy in there. With the comments around the use > of constants and defines fixed, you can add > > Reviewed-by: Jerome Brunet > > As a possible future enhancement, it would be nice if you could trim the use > of *_is_compatible() functions. I think it would make the code easier to > follow and review. > Thanks for the overall review, I will do a complete fixup of the constants and defines in a follow-up patchset, since the already-merged code also needs a good cleanup. I'll do a more complete refactoring to get rid of the _is_compatible() stuff in a second time, it needs much more work to handle correctly the 4 SoC families. Neil ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH libdrm 1/8] new syncobj extension v3
v2: drop not implemented IOCTLs and flags
v3: add transfer/signal ioctls
Signed-off-by: Chunming Zhou
Signed-off-by: Christian König
---
include/drm/drm.h | 35 +++
1 file changed, 35 insertions(+)
diff --git a/include/drm/drm.h b/include/drm/drm.h
index 85c685a2..26f51bca 100644
--- a/include/drm/drm.h
+++ b/include/drm/drm.h
@@ -729,8 +729,18 @@ struct drm_syncobj_handle {
__u32 pad;
};
+struct drm_syncobj_transfer {
+__u32 src_handle;
+__u32 dst_handle;
+__u64 src_point;
+__u64 dst_point;
+__u32 flags;
+__u32 pad;
+};
+
#define DRM_SYNCOBJ_WAIT_FLAGS_WAIT_ALL (1 << 0)
#define DRM_SYNCOBJ_WAIT_FLAGS_WAIT_FOR_SUBMIT (1 << 1)
+#define DRM_SYNCOBJ_WAIT_FLAGS_WAIT_AVAILABLE (1 << 2)
struct drm_syncobj_wait {
__u64 handles;
/* absolute timeout */
@@ -741,12 +751,31 @@ struct drm_syncobj_wait {
__u32 pad;
};
+struct drm_syncobj_timeline_wait {
+__u64 handles;
+/* wait on specific timeline point for every handles*/
+__u64 points;
+/* absolute timeout */
+__s64 timeout_nsec;
+__u32 count_handles;
+__u32 flags;
+__u32 first_signaled; /* only valid when not waiting all */
+__u32 pad;
+};
+
struct drm_syncobj_array {
__u64 handles;
__u32 count_handles;
__u32 pad;
};
+struct drm_syncobj_timeline_array {
+__u64 handles;
+__u64 points;
+__u32 count_handles;
+__u32 pad;
+};
+
/* Query current scanout sequence number */
struct drm_crtc_get_sequence {
__u32 crtc_id; /* requested crtc_id */
@@ -903,6 +932,12 @@ extern "C" {
#define DRM_IOCTL_MODE_GET_LEASE DRM_IOWR(0xC8, struct
drm_mode_get_lease)
#define DRM_IOCTL_MODE_REVOKE_LEASEDRM_IOWR(0xC9, struct
drm_mode_revoke_lease)
+#define DRM_IOCTL_SYNCOBJ_TIMELINE_WAIT DRM_IOWR(0xCA, struct
drm_syncobj_timeline_wait)
+#define DRM_IOCTL_SYNCOBJ_QUERY DRM_IOWR(0xCB, struct
drm_syncobj_timeline_array)
+#define DRM_IOCTL_SYNCOBJ_TRANSFER DRM_IOWR(0xCC, struct
drm_syncobj_transfer)
+#define DRM_IOCTL_SYNCOBJ_TIMELINE_SIGNAL DRM_IOWR(0xCD, struct
drm_syncobj_timeline_array)
+
+
/**
* Device specific ioctls should only be in their respective headers
* The device specific ioctl range is from 0x40 to 0x9f.
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH libdrm 6/8] expose timeline signal/export/import interfaces v2
v2: adapt to new one transfer ioctl
Signed-off-by: Chunming Zhou
---
amdgpu/amdgpu-symbol-check | 3 ++
amdgpu/amdgpu.h| 51
amdgpu/amdgpu_cs.c | 68 ++
3 files changed, 122 insertions(+)
diff --git a/amdgpu/amdgpu-symbol-check b/amdgpu/amdgpu-symbol-check
index 67ba3039..0cc54e5e 100755
--- a/amdgpu/amdgpu-symbol-check
+++ b/amdgpu/amdgpu-symbol-check
@@ -51,10 +51,13 @@ amdgpu_cs_submit
amdgpu_cs_submit_raw
amdgpu_cs_submit_raw2
amdgpu_cs_syncobj_export_sync_file
+amdgpu_cs_syncobj_export_sync_file2
amdgpu_cs_syncobj_import_sync_file
+amdgpu_cs_syncobj_import_sync_file2
amdgpu_cs_syncobj_query
amdgpu_cs_syncobj_reset
amdgpu_cs_syncobj_signal
+amdgpu_cs_syncobj_timeline_signal
amdgpu_cs_syncobj_timeline_wait
amdgpu_cs_syncobj_wait
amdgpu_cs_wait_fences
diff --git a/amdgpu/amdgpu.h b/amdgpu/amdgpu.h
index dcf662e9..b5bd3ed9 100644
--- a/amdgpu/amdgpu.h
+++ b/amdgpu/amdgpu.h
@@ -1501,6 +1501,23 @@ int amdgpu_cs_syncobj_reset(amdgpu_device_handle dev,
int amdgpu_cs_syncobj_signal(amdgpu_device_handle dev,
const uint32_t *syncobjs, uint32_t syncobj_count);
+/**
+ * Signal kernel timeline sync objects.
+ *
+ * \param dev - \c [in] device handle
+ * \param syncobjs - \c [in] array of sync object handles
+ * \param points - \c [in] array of timeline points
+ * \param syncobj_count - \c [in] number of handles in syncobjs
+ *
+ * \return 0 on success\n
+ * <0 - Negative POSIX Error code
+ *
+*/
+int amdgpu_cs_syncobj_timeline_signal(amdgpu_device_handle dev,
+ const uint32_t *syncobjs,
+ uint64_t *points,
+ uint32_t syncobj_count);
+
/**
* Wait for one or all sync objects to signal.
*
@@ -1618,7 +1635,41 @@ int
amdgpu_cs_syncobj_export_sync_file(amdgpu_device_handle dev,
int amdgpu_cs_syncobj_import_sync_file(amdgpu_device_handle dev,
uint32_t syncobj,
int sync_file_fd);
+/**
+ * Export kernel timeline sync object to a sync_file.
+ *
+ * \param dev- \c [in] device handle
+ * \param syncobj- \c [in] sync object handle
+ * \param point - \c [in] timeline point
+ * \param flags - \c [in] flags
+ * \param sync_file_fd - \c [out] sync_file file descriptor.
+ *
+ * \return 0 on success\n
+ * <0 - Negative POSIX Error code
+ *
+ */
+int amdgpu_cs_syncobj_export_sync_file2(amdgpu_device_handle dev,
+ uint32_t syncobj,
+ uint64_t point,
+ uint32_t flags,
+ int *sync_file_fd);
+/**
+ * Import kernel timeline sync object from a sync_file.
+ *
+ * \param dev- \c [in] device handle
+ * \param syncobj- \c [in] sync object handle
+ * \param point - \c [in] timeline point
+ * \param sync_file_fd - \c [in] sync_file file descriptor.
+ *
+ * \return 0 on success\n
+ * <0 - Negative POSIX Error code
+ *
+ */
+int amdgpu_cs_syncobj_import_sync_file2(amdgpu_device_handle dev,
+ uint32_t syncobj,
+ uint64_t point,
+ int sync_file_fd);
/**
* Export an amdgpu fence as a handle (syncobj or fd).
*
diff --git a/amdgpu/amdgpu_cs.c b/amdgpu/amdgpu_cs.c
index b8b0d566..1c02d16f 100644
--- a/amdgpu/amdgpu_cs.c
+++ b/amdgpu/amdgpu_cs.c
@@ -649,6 +649,18 @@ drm_public int
amdgpu_cs_syncobj_signal(amdgpu_device_handle dev,
return drmSyncobjSignal(dev->fd, syncobjs, syncobj_count);
}
+drm_public int amdgpu_cs_syncobj_timeline_signal(amdgpu_device_handle dev,
+const uint32_t *syncobjs,
+uint64_t *points,
+uint32_t syncobj_count)
+{
+ if (NULL == dev)
+ return -EINVAL;
+
+ return drmSyncobjTimelineSignal(dev->fd, syncobjs,
+ points, syncobj_count);
+}
+
drm_public int amdgpu_cs_syncobj_wait(amdgpu_device_handle dev,
uint32_t *handles, unsigned num_handles,
int64_t timeout_nsec, unsigned flags,
@@ -724,6 +736,62 @@ drm_public int
amdgpu_cs_syncobj_import_sync_file(amdgpu_device_handle dev,
return drmSyncobjImportSyncFile(dev->fd, syncobj, sync_file_fd);
}
+drm_public int amdgpu_cs_syncobj_export_sync_file2(amdgpu_device_handle dev,
+ uint32_t syncobj,
+ uint64_t point,
+ uint32_t flags,
+
[PATCH libdrm 7/8] wrap transfer interfaces
Signed-off-by: Chunming Zhou
---
amdgpu/amdgpu.h| 22 ++
amdgpu/amdgpu_cs.c | 16
2 files changed, 38 insertions(+)
diff --git a/amdgpu/amdgpu.h b/amdgpu/amdgpu.h
index b5bd3ed9..2350835b 100644
--- a/amdgpu/amdgpu.h
+++ b/amdgpu/amdgpu.h
@@ -1670,6 +1670,28 @@ int
amdgpu_cs_syncobj_import_sync_file2(amdgpu_device_handle dev,
uint32_t syncobj,
uint64_t point,
int sync_file_fd);
+
+/**
+ * transfer between syncbojs.
+ *
+ * \param dev- \c [in] device handle
+ * \param dst_handle - \c [in] sync object handle
+ * \param dst_point - \c [in] timeline point, 0 presents dst is binary
+ * \param src_handle - \c [in] sync object handle
+ * \param src_point - \c [in] timeline point, 0 presents src is binary
+ * \param flags - \c [in] flags
+ *
+ * \return 0 on success\n
+ * <0 - Negative POSIX Error code
+ *
+ */
+int amdgpu_cs_syncobj_transfer(amdgpu_device_handle dev,
+ uint32_t dst_handle,
+ uint64_t dst_point,
+ uint32_t src_handle,
+ uint64_t src_point,
+ uint32_t flags);
+
/**
* Export an amdgpu fence as a handle (syncobj or fd).
*
diff --git a/amdgpu/amdgpu_cs.c b/amdgpu/amdgpu_cs.c
index 1c02d16f..a1c1af55 100644
--- a/amdgpu/amdgpu_cs.c
+++ b/amdgpu/amdgpu_cs.c
@@ -792,6 +792,22 @@ out:
return ret;
}
+drm_public int amdgpu_cs_syncobj_transfer(amdgpu_device_handle dev,
+ uint32_t dst_handle,
+ uint64_t dst_point,
+ uint32_t src_handle,
+ uint64_t src_point,
+ uint32_t flags)
+{
+ if (NULL == dev)
+ return -EINVAL;
+
+ return drmSyncobjTransfer(dev->fd,
+ dst_handle, dst_point,
+ src_handle, src_point,
+ flags);
+}
+
drm_public int amdgpu_cs_submit_raw(amdgpu_device_handle dev,
amdgpu_context_handle context,
amdgpu_bo_list_handle bo_list_handle,
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH libdrm 5/8] add timeline signal/transfer ioctls v2
v2: use one transfer ioctl
Signed-off-by: Chunming Zhou
---
xf86drm.c | 33 +
xf86drm.h | 6 ++
2 files changed, 39 insertions(+)
diff --git a/xf86drm.c b/xf86drm.c
index 66e0c985..d57c4218 100644
--- a/xf86drm.c
+++ b/xf86drm.c
@@ -4280,6 +4280,21 @@ drm_public int drmSyncobjSignal(int fd, const uint32_t
*handles,
return ret;
}
+drm_public int drmSyncobjTimelineSignal(int fd, const uint32_t *handles,
+ uint64_t *points, uint32_t handle_count)
+{
+struct drm_syncobj_timeline_array args;
+int ret;
+
+memclear(args);
+args.handles = (uintptr_t)handles;
+args.points = (uint64_t)(uintptr_t)points;
+args.count_handles = handle_count;
+
+ret = drmIoctl(fd, DRM_IOCTL_SYNCOBJ_TIMELINE_SIGNAL, &args);
+return ret;
+}
+
drm_public int drmSyncobjTimelineWait(int fd, uint32_t *handles, uint64_t
*points,
unsigned num_handles,
int64_t timeout_nsec, unsigned flags,
@@ -4322,4 +4337,22 @@ drm_public int drmSyncobjQuery(int fd, uint32_t
*handles, uint64_t *points,
return 0;
}
+drm_public int drmSyncobjTransfer(int fd,
+ uint32_t dst_handle, uint64_t dst_point,
+ uint32_t src_handle, uint64_t src_point,
+ uint32_t flags)
+{
+struct drm_syncobj_transfer args;
+int ret;
+
+memclear(args);
+args.src_handle = src_handle;
+args.dst_handle = dst_handle;
+args.src_point = src_point;
+args.dst_point = dst_point;
+args.flags = flags;
+
+ret = drmIoctl(fd, DRM_IOCTL_SYNCOBJ_TRANSFER, &args);
+return ret;
+}
diff --git a/xf86drm.h b/xf86drm.h
index 60c7a84f..3fb1d1ca 100644
--- a/xf86drm.h
+++ b/xf86drm.h
@@ -876,12 +876,18 @@ extern int drmSyncobjWait(int fd, uint32_t *handles,
unsigned num_handles,
uint32_t *first_signaled);
extern int drmSyncobjReset(int fd, const uint32_t *handles, uint32_t
handle_count);
extern int drmSyncobjSignal(int fd, const uint32_t *handles, uint32_t
handle_count);
+extern int drmSyncobjTimelineSignal(int fd, const uint32_t *handles,
+ uint64_t *points, uint32_t handle_count);
extern int drmSyncobjTimelineWait(int fd, uint32_t *handles, uint64_t *points,
unsigned num_handles,
int64_t timeout_nsec, unsigned flags,
uint32_t *first_signaled);
extern int drmSyncobjQuery(int fd, uint32_t *handles, uint64_t *points,
uint32_t handle_count);
+extern int drmSyncobjTransfer(int fd,
+ uint32_t dst_handle, uint64_t dst_point,
+ uint32_t src_handle, uint64_t src_point,
+ uint32_t flags);
#if defined(__cplusplus)
}
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH libdrm 8/8] add syncobj timeline tests v3
v2: drop DRM_SYNCOBJ_CREATE_TYPE_TIMELINE, fix timeout calculation,
fix some warnings
v3: add export/import and cpu signal testing cases
Signed-off-by: Chunming Zhou
Signed-off-by: Christian König
---
tests/amdgpu/Makefile.am | 3 +-
tests/amdgpu/amdgpu_test.c | 11 ++
tests/amdgpu/amdgpu_test.h | 21 +++
tests/amdgpu/meson.build | 2 +-
tests/amdgpu/syncobj_tests.c | 290 +++
5 files changed, 325 insertions(+), 2 deletions(-)
create mode 100644 tests/amdgpu/syncobj_tests.c
diff --git a/tests/amdgpu/Makefile.am b/tests/amdgpu/Makefile.am
index 48278848..920882d0 100644
--- a/tests/amdgpu/Makefile.am
+++ b/tests/amdgpu/Makefile.am
@@ -34,4 +34,5 @@ amdgpu_test_SOURCES = \
uve_ib.h \
deadlock_tests.c \
vm_tests.c \
- ras_tests.c
+ ras_tests.c \
+ syncobj_tests.c
diff --git a/tests/amdgpu/amdgpu_test.c b/tests/amdgpu/amdgpu_test.c
index 8fc7a0b9..214c7fce 100644
--- a/tests/amdgpu/amdgpu_test.c
+++ b/tests/amdgpu/amdgpu_test.c
@@ -57,6 +57,7 @@
#define DEADLOCK_TESTS_STR "Deadlock Tests"
#define VM_TESTS_STR "VM Tests"
#define RAS_TESTS_STR "RAS Tests"
+#define SYNCOBJ_TIMELINE_TESTS_STR "SYNCOBJ TIMELINE Tests"
/**
* Open handles for amdgpu devices
@@ -123,6 +124,12 @@ static CU_SuiteInfo suites[] = {
.pCleanupFunc = suite_ras_tests_clean,
.pTests = ras_tests,
},
+ {
+ .pName = SYNCOBJ_TIMELINE_TESTS_STR,
+ .pInitFunc = suite_syncobj_timeline_tests_init,
+ .pCleanupFunc = suite_syncobj_timeline_tests_clean,
+ .pTests = syncobj_timeline_tests,
+ },
CU_SUITE_INFO_NULL,
};
@@ -176,6 +183,10 @@ static Suites_Active_Status suites_active_stat[] = {
.pName = RAS_TESTS_STR,
.pActive = suite_ras_tests_enable,
},
+ {
+ .pName = SYNCOBJ_TIMELINE_TESTS_STR,
+ .pActive = suite_syncobj_timeline_tests_enable,
+ },
};
diff --git a/tests/amdgpu/amdgpu_test.h b/tests/amdgpu/amdgpu_test.h
index bcd0bc7e..36675ea3 100644
--- a/tests/amdgpu/amdgpu_test.h
+++ b/tests/amdgpu/amdgpu_test.h
@@ -216,6 +216,27 @@ CU_BOOL suite_ras_tests_enable(void);
extern CU_TestInfo ras_tests[];
+/**
+ * Initialize syncobj timeline test suite
+ */
+int suite_syncobj_timeline_tests_init();
+
+/**
+ * Deinitialize syncobj timeline test suite
+ */
+int suite_syncobj_timeline_tests_clean();
+
+/**
+ * Decide if the suite is enabled by default or not.
+ */
+CU_BOOL suite_syncobj_timeline_tests_enable(void);
+
+/**
+ * Tests in syncobj timeline test suite
+ */
+extern CU_TestInfo syncobj_timeline_tests[];
+
+
/**
* Helper functions
*/
diff --git a/tests/amdgpu/meson.build b/tests/amdgpu/meson.build
index 95ed9305..1726cb43 100644
--- a/tests/amdgpu/meson.build
+++ b/tests/amdgpu/meson.build
@@ -24,7 +24,7 @@ if dep_cunit.found()
files(
'amdgpu_test.c', 'basic_tests.c', 'bo_tests.c', 'cs_tests.c',
'vce_tests.c', 'uvd_enc_tests.c', 'vcn_tests.c', 'deadlock_tests.c',
- 'vm_tests.c', 'ras_tests.c',
+ 'vm_tests.c', 'ras_tests.c', 'syncobj_tests.c',
),
dependencies : [dep_cunit, dep_threads],
include_directories : [inc_root, inc_drm,
include_directories('../../amdgpu')],
diff --git a/tests/amdgpu/syncobj_tests.c b/tests/amdgpu/syncobj_tests.c
new file mode 100644
index ..a0c627d7
--- /dev/null
+++ b/tests/amdgpu/syncobj_tests.c
@@ -0,0 +1,290 @@
+/*
+ * Copyright 2017 Advanced Micro Devices, Inc.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE COPYRIGHT HOLDER(S) OR AUTHOR(S) BE LIABLE FOR ANY CLAIM, DAMAGES OR
+ * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
+ * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ *
+*/
+
+#include "CUnit/Basic.h"
+
+#include "amdgpu_test.h"
+#include "amdgpu_drm.h"
+#include "amdgpu_internal.h"
+#include
+
+static amdgpu_device_handle device_handle;
+static uint32_t major_version;
+static uint32_t minor_version;
+
+static void a
[PATCH libdrm 3/8] add timeline wait/query ioctl v2
v2: drop export/import
Signed-off-by: Chunming Zhou
---
xf86drm.c | 44
xf86drm.h | 6 ++
2 files changed, 50 insertions(+)
diff --git a/xf86drm.c b/xf86drm.c
index 18ad7c58..66e0c985 100644
--- a/xf86drm.c
+++ b/xf86drm.c
@@ -4279,3 +4279,47 @@ drm_public int drmSyncobjSignal(int fd, const uint32_t
*handles,
ret = drmIoctl(fd, DRM_IOCTL_SYNCOBJ_SIGNAL, &args);
return ret;
}
+
+drm_public int drmSyncobjTimelineWait(int fd, uint32_t *handles, uint64_t
*points,
+ unsigned num_handles,
+ int64_t timeout_nsec, unsigned flags,
+ uint32_t *first_signaled)
+{
+struct drm_syncobj_timeline_wait args;
+int ret;
+
+memclear(args);
+args.handles = (uintptr_t)handles;
+args.points = (uint64_t)(uintptr_t)points;
+args.timeout_nsec = timeout_nsec;
+args.count_handles = num_handles;
+args.flags = flags;
+
+ret = drmIoctl(fd, DRM_IOCTL_SYNCOBJ_TIMELINE_WAIT, &args);
+if (ret < 0)
+return -errno;
+
+if (first_signaled)
+*first_signaled = args.first_signaled;
+return ret;
+}
+
+
+drm_public int drmSyncobjQuery(int fd, uint32_t *handles, uint64_t *points,
+ uint32_t handle_count)
+{
+struct drm_syncobj_timeline_array args;
+int ret;
+
+memclear(args);
+args.handles = (uintptr_t)handles;
+args.points = (uint64_t)(uintptr_t)points;
+args.count_handles = handle_count;
+
+ret = drmIoctl(fd, DRM_IOCTL_SYNCOBJ_QUERY, &args);
+if (ret)
+return ret;
+return 0;
+}
+
+
diff --git a/xf86drm.h b/xf86drm.h
index 887ecc76..60c7a84f 100644
--- a/xf86drm.h
+++ b/xf86drm.h
@@ -876,6 +876,12 @@ extern int drmSyncobjWait(int fd, uint32_t *handles,
unsigned num_handles,
uint32_t *first_signaled);
extern int drmSyncobjReset(int fd, const uint32_t *handles, uint32_t
handle_count);
extern int drmSyncobjSignal(int fd, const uint32_t *handles, uint32_t
handle_count);
+extern int drmSyncobjTimelineWait(int fd, uint32_t *handles, uint64_t *points,
+ unsigned num_handles,
+ int64_t timeout_nsec, unsigned flags,
+ uint32_t *first_signaled);
+extern int drmSyncobjQuery(int fd, uint32_t *handles, uint64_t *points,
+ uint32_t handle_count);
#if defined(__cplusplus)
}
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH libdrm 4/8] wrap syncobj timeline query/wait APIs for amdgpu v3
v2: symbos are stored in lexical order.
v3: drop export/import and extra query indirection
Signed-off-by: Chunming Zhou
Signed-off-by: Christian König
---
amdgpu/amdgpu-symbol-check | 2 ++
amdgpu/amdgpu.h| 39 ++
amdgpu/amdgpu_cs.c | 23 ++
3 files changed, 64 insertions(+)
diff --git a/amdgpu/amdgpu-symbol-check b/amdgpu/amdgpu-symbol-check
index 96a44b40..67ba3039 100755
--- a/amdgpu/amdgpu-symbol-check
+++ b/amdgpu/amdgpu-symbol-check
@@ -52,8 +52,10 @@ amdgpu_cs_submit_raw
amdgpu_cs_submit_raw2
amdgpu_cs_syncobj_export_sync_file
amdgpu_cs_syncobj_import_sync_file
+amdgpu_cs_syncobj_query
amdgpu_cs_syncobj_reset
amdgpu_cs_syncobj_signal
+amdgpu_cs_syncobj_timeline_wait
amdgpu_cs_syncobj_wait
amdgpu_cs_wait_fences
amdgpu_cs_wait_semaphore
diff --git a/amdgpu/amdgpu.h b/amdgpu/amdgpu.h
index d6de3b8d..dcf662e9 100644
--- a/amdgpu/amdgpu.h
+++ b/amdgpu/amdgpu.h
@@ -1521,6 +1521,45 @@ int amdgpu_cs_syncobj_wait(amdgpu_device_handle dev,
int64_t timeout_nsec, unsigned flags,
uint32_t *first_signaled);
+/**
+ * Wait for one or all sync objects on their points to signal.
+ *
+ * \param dev- \c [in] self-explanatory
+ * \param handles - \c [in] array of sync object handles
+ * \param points - \c [in] array of sync points to wait
+ * \param num_handles - \c [in] self-explanatory
+ * \param timeout_nsec - \c [in] self-explanatory
+ * \param flags - \c [in] a bitmask of DRM_SYNCOBJ_WAIT_FLAGS_*
+ * \param first_signaled - \c [in] self-explanatory
+ *
+ * \return 0 on success\n
+ * -ETIME - Timeout
+ * <0 - Negative POSIX Error code
+ *
+ */
+int amdgpu_cs_syncobj_timeline_wait(amdgpu_device_handle dev,
+ uint32_t *handles, uint64_t *points,
+ unsigned num_handles,
+ int64_t timeout_nsec, unsigned flags,
+ uint32_t *first_signaled);
+/**
+ * Query sync objects payloads.
+ *
+ * \param dev- \c [in] self-explanatory
+ * \param handles - \c [in] array of sync object handles
+ * \param points - \c [out] array of sync points returned, which presents
+ * syncobj payload.
+ * \param num_handles - \c [in] self-explanatory
+ *
+ * \return 0 on success\n
+ * -ETIME - Timeout
+ * <0 - Negative POSIX Error code
+ *
+ */
+int amdgpu_cs_syncobj_query(amdgpu_device_handle dev,
+ uint32_t *handles, uint64_t *points,
+ unsigned num_handles);
+
/**
* Export kernel sync object to shareable fd.
*
diff --git a/amdgpu/amdgpu_cs.c b/amdgpu/amdgpu_cs.c
index 5bedf748..b8b0d566 100644
--- a/amdgpu/amdgpu_cs.c
+++ b/amdgpu/amdgpu_cs.c
@@ -661,6 +661,29 @@ drm_public int amdgpu_cs_syncobj_wait(amdgpu_device_handle
dev,
flags, first_signaled);
}
+drm_public int amdgpu_cs_syncobj_timeline_wait(amdgpu_device_handle dev,
+ uint32_t *handles, uint64_t
*points,
+ unsigned num_handles,
+ int64_t timeout_nsec, unsigned
flags,
+ uint32_t *first_signaled)
+{
+ if (NULL == dev)
+ return -EINVAL;
+
+ return drmSyncobjTimelineWait(dev->fd, handles, points, num_handles,
+ timeout_nsec, flags, first_signaled);
+}
+
+drm_public int amdgpu_cs_syncobj_query(amdgpu_device_handle dev,
+ uint32_t *handles, uint64_t *points,
+ unsigned num_handles)
+{
+ if (NULL == dev)
+ return -EINVAL;
+
+ return drmSyncobjQuery(dev->fd, handles, points, num_handles);
+}
+
drm_public int amdgpu_cs_export_syncobj(amdgpu_device_handle dev,
uint32_t handle,
int *shared_fd)
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH libdrm 2/8] addr cs chunk for syncobj timeline
Signed-off-by: Chunming Zhou
---
include/drm/amdgpu_drm.h | 9 +
1 file changed, 9 insertions(+)
diff --git a/include/drm/amdgpu_drm.h b/include/drm/amdgpu_drm.h
index e3a97da4..ab53f2e0 100644
--- a/include/drm/amdgpu_drm.h
+++ b/include/drm/amdgpu_drm.h
@@ -528,6 +528,8 @@ struct drm_amdgpu_gem_va {
#define AMDGPU_CHUNK_ID_SYNCOBJ_OUT 0x05
#define AMDGPU_CHUNK_ID_BO_HANDLES 0x06
#define AMDGPU_CHUNK_ID_SCHEDULED_DEPENDENCIES 0x07
+#define AMDGPU_CHUNK_ID_SYNCOBJ_TIMELINE_WAIT0x08
+#define AMDGPU_CHUNK_ID_SYNCOBJ_TIMELINE_SIGNAL 0x09
struct drm_amdgpu_cs_chunk {
__u32 chunk_id;
@@ -608,6 +610,13 @@ struct drm_amdgpu_cs_chunk_sem {
__u32 handle;
};
+struct drm_amdgpu_cs_chunk_syncobj {
+ __u32 handle;
+ __u32 flags;
+ __u64 point;
+};
+
+
#define AMDGPU_FENCE_TO_HANDLE_GET_SYNCOBJ 0
#define AMDGPU_FENCE_TO_HANDLE_GET_SYNCOBJ_FD 1
#define AMDGPU_FENCE_TO_HANDLE_GET_SYNC_FILE_FD2
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/3] dt-bindings: meson: Add G12A display bindings
On 13/03/2019 15:10, Neil Armstrong wrote: > This patchset adds the G12A specific bindings for the Display VPU > and VPU Power Control. > > The Amlogic Meson G12A Display module is based on the Meson GXM SoC > with an updated Plane Blender, thus VPU architecture and interconnect > is the same. > > Implementation then DT nodes will come in a further patchsets. > > Neil Armstrong (3): > dt-bindings: display: amlogic,meson-vpu: Add G12A compatible and ports > dt-bindings: display: amlogic,meson-dw-hdmi: Add G12A compatible and > ports > dt-bindings: power: amlogic,meson-gx-pwrc: Add G12A compatible > > .../devicetree/bindings/display/amlogic,meson-dw-hdmi.txt | 4 > .../devicetree/bindings/display/amlogic,meson-vpu.txt | 4 > .../devicetree/bindings/power/amlogic,meson-gx-pwrc.txt | 4 +++- > 3 files changed, 11 insertions(+), 1 deletion(-) > Kevin, I applied Patches 1 & 2 to drm-misc-next, can you take Patch 3 along : - https://patchwork.kernel.org/patch/10879285/ - https://patchwork.kernel.org/patch/10879293/ Thanks ! Neil ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110137] drirc adaptive sync, vrr, freesync blacklisting documentation
https://bugs.freedesktop.org/show_bug.cgi?id=110137 --- Comment #2 from gr...@sub.red --- Neither qutebrowser nor QtWebEngineProcess worked. Now I've seen that qtbrowser is built on PyQt5, so the executable name has to be "python3", this works: I'd send in a patch for that, but I think this will block any python3-based app, which is not the goal here. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 07/11] drm/meson: Add G12A support for plane handling in CRTC driver
On 09/04/2019 10:43, Jerome Brunet wrote:
> On Mon, 2019-03-25 at 15:18 +0100, Neil Armstrong wrote:
>> This patch adds support for the new OSD+VD Plane blending module
>> in the CRTC code by adding the G12A code to manage the blending
>> module and setting the right OSD1 & VD1 plane registers.
>>
>> Signed-off-by: Neil Armstrong
>> ---
>> drivers/gpu/drm/meson/meson_crtc.c | 269 +++--
>> drivers/gpu/drm/meson/meson_drv.h | 4 +
>> 2 files changed, 221 insertions(+), 52 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/meson/meson_crtc.c
>> b/drivers/gpu/drm/meson/meson_crtc.c
>> index 6d9311e254ef..5579f8ac3e3f 100644
>> --- a/drivers/gpu/drm/meson/meson_crtc.c
>> +++ b/drivers/gpu/drm/meson/meson_crtc.c
>> @@ -39,12 +39,17 @@
>> #include "meson_viu.h"
>> #include "meson_registers.h"
>>
>> +#define MESON_G12A_VIU_OFFSET 0x5ec0
>> +
>> /* CRTC definition */
>>
>> struct meson_crtc {
>> struct drm_crtc base;
>> struct drm_pending_vblank_event *event;
>> struct meson_drm *priv;
>> +void (*enable_osd1)(struct meson_drm *priv);
>> +void (*enable_vd1)(struct meson_drm *priv);
>> +unsigned int viu_offset;
>> };
>> #define to_meson_crtc(x) container_of(x, struct meson_crtc, base)
>>
>> @@ -80,6 +85,44 @@ static const struct drm_crtc_funcs meson_crtc_funcs = {
>>
>> };
>>
>> +static void meson_g12a_crtc_atomic_enable(struct drm_crtc *crtc,
>> + struct drm_crtc_state *old_state)
>> +{
>> +struct meson_crtc *meson_crtc = to_meson_crtc(crtc);
>> +struct drm_crtc_state *crtc_state = crtc->state;
>> +struct meson_drm *priv = meson_crtc->priv;
>> +
>> +DRM_DEBUG_DRIVER("\n");
>> +
>> +if (!crtc_state) {
>> +DRM_ERROR("Invalid crtc_state\n");
>> +return;
>> +}
>> +
>> +/* VD1 Preblend vertical start/end */
>> +writel(FIELD_PREP(GENMASK(11, 0), 2303),
>
> Could could define this mask somewhere
> I don't know if the 2303 can be explained. I'd nice if it could
It's a width, I'll add a comment.
>
>> + priv->io_base + _REG(VPP_PREBLEND_VD1_V_START_END));
>> +
>> +/* Setup Blender */
>> +writel(crtc_state->mode.hdisplay |
>> + crtc_state->mode.vdisplay << 16,
>> + priv->io_base + _REG(VPP_POSTBLEND_H_SIZE));
>> +
>> +writel_relaxed(0 << 16 |
>
> this 16 shift seems to be used for hdisplay or something. Could
> define/document it a bit
Ack
>
>> +(crtc_state->mode.hdisplay - 1),
>> +priv->io_base + _REG(VPP_OSD1_BLD_H_SCOPE));
>> +writel_relaxed(0 << 16 |
>> +(crtc_state->mode.vdisplay - 1),
>> +priv->io_base + _REG(VPP_OSD1_BLD_V_SCOPE));
>> +writel_relaxed(crtc_state->mode.hdisplay << 16 |
>> +crtc_state->mode.vdisplay,
>> +priv->io_base + _REG(VPP_OUT_H_V_SIZE));
>> +
>> +drm_crtc_vblank_on(crtc);
>> +
>> +priv->viu.osd1_enabled = true;
>> +}
>> +
>> static void meson_crtc_atomic_enable(struct drm_crtc *crtc,
>> struct drm_crtc_state *old_state)
>> {
>> @@ -110,6 +153,31 @@ static void meson_crtc_atomic_enable(struct drm_crtc
>> *crtc,
>> priv->viu.osd1_enabled = true;
>> }
>>
>> +static void meson_g12a_crtc_atomic_disable(struct drm_crtc *crtc,
>> + struct drm_crtc_state *old_state)
>> +{
>> +struct meson_crtc *meson_crtc = to_meson_crtc(crtc);
>> +struct meson_drm *priv = meson_crtc->priv;
>> +
>> +DRM_DEBUG_DRIVER("\n");
>> +
>> +drm_crtc_vblank_off(crtc);
>> +
>> +priv->viu.osd1_enabled = false;
>> +priv->viu.osd1_commit = false;
>> +
>> +priv->viu.vd1_enabled = false;
>> +priv->viu.vd1_commit = false;
>> +
>> +if (crtc->state->event && !crtc->state->active) {
>> +spin_lock_irq(&crtc->dev->event_lock);
>> +drm_crtc_send_vblank_event(crtc, crtc->state->event);
>> +spin_unlock_irq(&crtc->dev->event_lock);
>> +
>> +crtc->state->event = NULL;
>> +}
>> +}
>> +
>> static void meson_crtc_atomic_disable(struct drm_crtc *crtc,
>>struct drm_crtc_state *old_state)
>> {
>> @@ -173,6 +241,53 @@ static const struct drm_crtc_helper_funcs
>> meson_crtc_helper_funcs = {
>> .atomic_disable = meson_crtc_atomic_disable,
>> };
>>
>> +static const struct drm_crtc_helper_funcs meson_g12a_crtc_helper_funcs = {
>> +.atomic_begin = meson_crtc_atomic_begin,
>> +.atomic_flush = meson_crtc_atomic_flush,
>> +.atomic_enable = meson_g12a_crtc_atomic_enable,
>> +.atomic_disable = meson_g12a_crtc_atomic_disable,
>> +};
>> +
>> +static void meson_crtc_enable_osd1(struct meson_drm *priv)
>> +{
>> +writel_bits_relaxed(VPP_OSD1_POSTBLEND, VPP_OSD1_POSTBLEND,
>> +priv->io_base + _REG(VPP_MISC));
>> +}
>> +
>> +static void meson_g12a_crtc_enable_os
Re: [PATCH 08/11] drm/meson: Add G12A support for CVBS Encoer
On 09/04/2019 10:43, Jerome Brunet wrote:
> On Mon, 2019-03-25 at 15:18 +0100, Neil Armstrong wrote:
>> The Meson G12A SoCs uses the exact same CVBS encoder except a simple
>> CVBS DAC register offset and settings delta.
>>
>> Signed-off-by: Neil Armstrong
>> ---
>> drivers/gpu/drm/meson/meson_venc.c | 11 +--
>> drivers/gpu/drm/meson/meson_venc_cvbs.c | 25 ++---
>> 2 files changed, 27 insertions(+), 9 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/meson/meson_venc.c
>> b/drivers/gpu/drm/meson/meson_venc.c
>> index 66d73a932d19..6faca7313339 100644
>> --- a/drivers/gpu/drm/meson/meson_venc.c
>> +++ b/drivers/gpu/drm/meson/meson_venc.c
>> @@ -73,7 +73,9 @@
>> /* HHI Registers */
>> #define HHI_GCLK_MPEG2 0x148 /* 0x52 offset in data sheet */
>> #define HHI_VDAC_CNTL0 0x2F4 /* 0xbd offset in data sheet */
>> +#define HHI_VDAC_CNTL0_G12A 0x2EC /* 0xbd offset in data sheet */
>> #define HHI_VDAC_CNTL1 0x2F8 /* 0xbe offset in data sheet */
>> +#define HHI_VDAC_CNTL1_G12A 0x2F0 /* 0xbe offset in data sheet */
>> #define HHI_HDMI_PHY_CNTL0 0x3a0 /* 0xe8 offset in data sheet */
>>
>> struct meson_cvbs_enci_mode meson_cvbs_enci_pal = {
>> @@ -1675,8 +1677,13 @@ void meson_venc_disable_vsync(struct meson_drm *priv)
>> void meson_venc_init(struct meson_drm *priv)
>> {
>> /* Disable CVBS VDAC */
>> -regmap_write(priv->hhi, HHI_VDAC_CNTL0, 0);
>> -regmap_write(priv->hhi, HHI_VDAC_CNTL1, 8);
>> +if (meson_vpu_is_compatible(priv, "amlogic,meson-g12a-vpu")) {
>> +regmap_write(priv->hhi, HHI_VDAC_CNTL0_G12A, 0);
>> +regmap_write(priv->hhi, HHI_VDAC_CNTL1_G12A, 8);
>> +} else {
>> +regmap_write(priv->hhi, HHI_VDAC_CNTL0, 0);
>> +regmap_write(priv->hhi, HHI_VDAC_CNTL1, 8);
>> +}
>>
>> /* Power Down Dacs */
>> writel_relaxed(0xff, priv->io_base + _REG(VENC_VDAC_SETTING));
>> diff --git a/drivers/gpu/drm/meson/meson_venc_cvbs.c
>> b/drivers/gpu/drm/meson/meson_venc_cvbs.c
>> index d622d817b6df..2c5341c881c4 100644
>> --- a/drivers/gpu/drm/meson/meson_venc_cvbs.c
>> +++ b/drivers/gpu/drm/meson/meson_venc_cvbs.c
>> @@ -37,7 +37,9 @@
>>
>> /* HHI VDAC Registers */
>> #define HHI_VDAC_CNTL0 0x2F4 /* 0xbd offset in data sheet */
>> +#define HHI_VDAC_CNTL0_G12A 0x2EC /* 0xbd offset in data sheet */
>> #define HHI_VDAC_CNTL1 0x2F8 /* 0xbe offset in data sheet */
>> +#define HHI_VDAC_CNTL1_G12A 0x2F0 /* 0xbe offset in data sheet */
>>
>> struct meson_venc_cvbs {
>> struct drm_encoder encoder;
>> @@ -166,8 +168,13 @@ static void meson_venc_cvbs_encoder_disable(struct
>> drm_encoder *encoder)
>> struct meson_drm *priv = meson_venc_cvbs->priv;
>>
>> /* Disable CVBS VDAC */
>> -regmap_write(priv->hhi, HHI_VDAC_CNTL0, 0);
>> -regmap_write(priv->hhi, HHI_VDAC_CNTL1, 8);
>> +if (meson_vpu_is_compatible(priv, "amlogic,meson-g12a-vpu")) {
>> +regmap_write(priv->hhi, HHI_VDAC_CNTL0_G12A, 0);
>> +regmap_write(priv->hhi, HHI_VDAC_CNTL1_G12A, 0);
>> +} else {
>> +regmap_write(priv->hhi, HHI_VDAC_CNTL0, 0);
>> +regmap_write(priv->hhi, HHI_VDAC_CNTL1, 8);
>
> I imagine 8 stands for BIT(3) ? Could you add a define to explain (quickly)
> what it is ?
Ack
>
>> +}
>> }
>>
>> static void meson_venc_cvbs_encoder_enable(struct drm_encoder *encoder)
>> @@ -179,13 +186,17 @@ static void meson_venc_cvbs_encoder_enable(struct
>> drm_encoder *encoder)
>> /* VDAC0 source is not from ATV */
>> writel_bits_relaxed(BIT(5), 0, priv->io_base + _REG(VENC_VDAC_DACSEL0));
>>
>> -if (meson_vpu_is_compatible(priv, "amlogic,meson-gxbb-vpu"))
>> +if (meson_vpu_is_compatible(priv, "amlogic,meson-gxbb-vpu")) {
>> regmap_write(priv->hhi, HHI_VDAC_CNTL0, 1);
>> -else if (meson_vpu_is_compatible(priv, "amlogic,meson-gxm-vpu") ||
>> - meson_vpu_is_compatible(priv, "amlogic,meson-gxl-vpu"))
>> +regmap_write(priv->hhi, HHI_VDAC_CNTL1, 0);
>> +} else if (meson_vpu_is_compatible(priv, "amlogic,meson-gxm-vpu") ||
>> + meson_vpu_is_compatible(priv, "amlogic,meson-gxl-vpu")) {
>> regmap_write(priv->hhi, HHI_VDAC_CNTL0, 0xf0001);
>> -
>> -regmap_write(priv->hhi, HHI_VDAC_CNTL1, 0);
>> +regmap_write(priv->hhi, HHI_VDAC_CNTL1, 0);
>> +} else if (meson_vpu_is_compatible(priv, "amlogic,meson-g12a-vpu")) {
>> +regmap_write(priv->hhi, HHI_VDAC_CNTL0_G12A, 0x906001);
>> +regmap_write(priv->hhi, HHI_VDAC_CNTL1_G12A, 0);
>> +}
>
> Maybe the values above are just magics taken from the vendor kernel, but if
> you can, it would be nice to break them down to help us understand what is
> controlled in these CTNL registers.
It's pretty magic values, but I'll do my best.
>
>> }
>>
>> static void meson_venc_cvbs_encoder_mode_set(struct drm_encoder *encoder,
>
Re: [PATCH 08/11] drm/meson: Add G12A support for CVBS Encoer
On 09/04/2019 10:44, Jerome Brunet wrote: > On Tue, 2019-04-09 at 10:43 +0200, Jerome Brunet wrote: >> On Mon, 2019-03-25 at 15:18 +0100, Neil Armstrong wrote: >>> The Meson G12A SoCs uses the exact same CVBS encoder except a simple >>> CVBS DAC register offset and settings delta. >>> >>> Signed-off-by: Neil Armstrong >>> --- >>> drivers/gpu/drm/meson/meson_venc.c | 11 +-- >>> drivers/gpu/drm/meson/meson_venc_cvbs.c | 25 ++--- >>> 2 files changed, 27 insertions(+), 9 deletions(-) > > ... and there is a typo in the patch title. s/Encoer/Encoder > Thanks for pointing this, I'll fix while applying. Neil ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 04/11] drm/meson: Add G12A Support for VIU setup
On 09/04/2019 10:42, Jerome Brunet wrote:
> On Mon, 2019-03-25 at 15:18 +0100, Neil Armstrong wrote:
>> Amlogic G12A SoC needs a different VIU setup code,
>> handle it.
>>
>> Signed-off-by: Neil Armstrong
>> ---
>> drivers/gpu/drm/meson/meson_viu.c | 72 ---
>> 1 file changed, 67 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/meson/meson_viu.c
>> b/drivers/gpu/drm/meson/meson_viu.c
>> index ac0f3687e09a..0169c98b01c9 100644
>> --- a/drivers/gpu/drm/meson/meson_viu.c
>> +++ b/drivers/gpu/drm/meson/meson_viu.c
>> @@ -90,6 +90,34 @@ static int eotf_bypass_coeff[EOTF_COEFF_SIZE] = {
>> EOTF_COEFF_RIGHTSHIFT /* right shift */
>> };
>>
>> +void meson_viu_set_g12a_osd1_matrix(struct meson_drm *priv, int *m,
>> + bool csc_on)
>> +{
>> +/* VPP WRAP OSD1 matrix */
>> +writel(((m[0] & 0xfff) << 16) | (m[1] & 0xfff),
>> +priv->io_base + _REG(VPP_WRAP_OSD1_MATRIX_PRE_OFFSET0_1));
>> +writel(m[2] & 0xfff,
>> +priv->io_base + _REG(VPP_WRAP_OSD1_MATRIX_PRE_OFFSET2));
>> +writel(((m[3] & 0x1fff) << 16) | (m[4] & 0x1fff),
>> +priv->io_base + _REG(VPP_WRAP_OSD1_MATRIX_COEF00_01));
>> +writel(((m[5] & 0x1fff) << 16) | (m[6] & 0x1fff),
>> +priv->io_base + _REG(VPP_WRAP_OSD1_MATRIX_COEF02_10));
>> +writel(((m[7] & 0x1fff) << 16) | (m[8] & 0x1fff),
>> +priv->io_base + _REG(VPP_WRAP_OSD1_MATRIX_COEF11_12));
>> +writel(((m[9] & 0x1fff) << 16) | (m[10] & 0x1fff),
>> +priv->io_base + _REG(VPP_WRAP_OSD1_MATRIX_COEF20_21));
>> +writel((m[11] & 0x1fff) << 16,
>> +priv->io_base + _REG(VPP_WRAP_OSD1_MATRIX_COEF22));
>> +
>> +writel(((m[18] & 0xfff) << 16) | (m[19] & 0xfff),
>> +priv->io_base + _REG(VPP_WRAP_OSD1_MATRIX_OFFSET0_1));
>
> Can you define some of the masks and shifts above ? possibly the same define
> for all the registers I suppose ... maybe using FIELD_PREP ?
Ack
>
>> +writel(m[20] & 0xfff,
>> +priv->io_base + _REG(VPP_WRAP_OSD1_MATRIX_OFFSET2));
>> +
>> +writel_bits_relaxed(BIT(0), csc_on ? BIT(0) : 0,
>> +priv->io_base + _REG(VPP_WRAP_OSD1_MATRIX_EN_CTRL));
>> +}
>> +
>> void meson_viu_set_osd_matrix(struct meson_drm *priv,
>>enum viu_matrix_sel_e m_select,
>>int *m, bool csc_on)
>> @@ -336,14 +364,24 @@ void meson_viu_init(struct meson_drm *priv)
>> if (meson_vpu_is_compatible(priv, "amlogic,meson-gxm-vpu") ||
>> meson_vpu_is_compatible(priv, "amlogic,meson-gxl-vpu"))
>> meson_viu_load_matrix(priv);
>> +else if (meson_vpu_is_compatible(priv, "amlogic,meson-g12a-vpu"))
>> +meson_viu_set_g12a_osd1_matrix(priv, RGB709_to_YUV709l_coeff,
>> + true);
>>
>> /* Initialize OSD1 fifo control register */
>> reg = BIT(0) | /* Urgent DDR request priority */
>> - (4 << 5) | /* hold_fifo_lines */
>> - (3 << 10) | /* burst length 64 */
>> - (32 << 12) | /* fifo_depth_val: 32*8=256 */
>> - (2 << 22) | /* 4 words in 1 burst */
>> - (2 << 24);
>> + (4 << 5); /* hold_fifo_lines */
>> +if (meson_vpu_is_compatible(priv, "amlogic,meson-g12a-vpu"))
>> +reg |= (1 << 10) | /* burst length 32 */
>> + (32 << 12) | /* fifo_depth_val: 32*8=256 */
>> + (2 << 22) | /* 4 words in 1 burst */
>> + (2 << 24) |
>> + (1 << 31);
>> +else
>> +reg |= (3 << 10) | /* burst length 64 */
>> + (32 << 12) | /* fifo_depth_val: 32*8=256 */
>> + (2 << 22) | /* 4 words in 1 burst */
>> + (2 << 24);
>
> Could you use the BIT() macro and add some defines ?
Ack
>
>> writel_relaxed(reg, priv->io_base + _REG(VIU_OSD1_FIFO_CTRL_STAT));
>> writel_relaxed(reg, priv->io_base + _REG(VIU_OSD2_FIFO_CTRL_STAT));
>>
>> @@ -369,6 +407,30 @@ void meson_viu_init(struct meson_drm *priv)
>> writel_relaxed(0x00FF00C0,
>> priv->io_base + _REG(VD2_IF0_LUMA_FIFO_SIZE));
>>
>> +if (meson_vpu_is_compatible(priv, "amlogic,meson-g12a-vpu")) {
>> +writel_relaxed(4 << 29 |
>> +1 << 27 |
>> +1 << 26 | /* blend_din0 input to blend0 */
>> +1 << 25 | /* blend1_dout to blend2 */
>> +1 << 24 | /* blend1_din3 input to blend1 */
>> +1 << 20 |
>> +0 << 16 |
>> +1,
>> +priv->io_base + _REG(VIU_OSD_BLEND_CTRL));
>> +writel_relaxed(3 << 8 |
>> +1 << 20,
>> +priv->io_base + _REG(OSD1_BLEND_SRC_CTRL));
>> +writel_relaxed(1 << 20,
>> +
Re: [PATCH 06/11] drm/meson: Add G12A Support for the Overlay video plane
On 09/04/2019 10:42, Jerome Brunet wrote:
> On Mon, 2019-03-25 at 15:18 +0100, Neil Armstrong wrote:
>> Amlogic G12A SoC supports the same set of Video Planes, but now
>> are handled by the new OSD plane blender module.
>>
>> This patch uses the same VD1 plane for G12A, using the exact same scaler
>> and VD11 setup registers, except using the new blender register to
>> disable the plane.
>>
>> Signed-off-by: Neil Armstrong
>> ---
>> drivers/gpu/drm/meson/meson_overlay.c | 10 --
>> 1 file changed, 8 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/meson/meson_overlay.c
>> b/drivers/gpu/drm/meson/meson_overlay.c
>> index b54a22e483b9..bdbf925ff3e8 100644
>> --- a/drivers/gpu/drm/meson/meson_overlay.c
>> +++ b/drivers/gpu/drm/meson/meson_overlay.c
>> @@ -516,8 +516,14 @@ static void meson_overlay_atomic_disable(struct
>> drm_plane *plane,
>> priv->viu.vd1_enabled = false;
>>
>> /* Disable VD1 */
>> -writel_bits_relaxed(VPP_VD1_POSTBLEND | VPP_VD1_PREBLEND, 0,
>> -priv->io_base + _REG(VPP_MISC));
>> +if (meson_vpu_is_compatible(priv, "amlogic,meson-g12a-vpu")) {
>> +writel_relaxed(0, priv->io_base + _REG(VD1_BLEND_SRC_CTRL));
>> +writel_relaxed(0, priv->io_base + _REG(VD2_BLEND_SRC_CTRL));
>> +writel_relaxed(0, priv->io_base + _REG(VD1_IF0_GEN_REG +
>> 0x17b0));
>> +writel_relaxed(0, priv->io_base + _REG(VD2_IF0_GEN_REG +
>> 0x17b0));
>
> Is it possible to add a comment explaining this 0x17b0 value ?
It's the same register shift as in crtc, will add a define.
>
>> +} else
>> +writel_bits_relaxed(VPP_VD1_POSTBLEND | VPP_VD1_PREBLEND, 0,
>> +priv->io_base + _REG(VPP_MISC));
>>
>> }
>>
>
>
Will fix in a follow-up patch,
Neil
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 09/11] drm/meson: Add G12A Video Clock setup
On 09/04/2019 10:46, Jerome Brunet wrote:
> On Mon, 2019-03-25 at 15:18 +0100, Neil Armstrong wrote:
>> While switching to the Common Clock Framework is still Work In Progress,
>> this patch adds the corresponding G12A HDMI PLL setup to be on-par
>> with the other SoCs support.
>>
>> The G12A has only a single tweak about the high frequency setup,
>> where the HDMI PLL needs a specific setup to handle correctly the
>> 5.94GHz DCO frequency.
>>
>> Apart that, it handle correctly all the other HDMI frequencies
>> and can achieve even better DMT clock frequency precision with
>> the larger fractional dividier width.
>>
>> Signed-off-by: Neil Armstrong
>> ---
>> drivers/gpu/drm/meson/meson_vclk.c | 119 ++---
>> 1 file changed, 108 insertions(+), 11 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/meson/meson_vclk.c
>> b/drivers/gpu/drm/meson/meson_vclk.c
>> index c15a5a5df633..b39034745444 100644
>> --- a/drivers/gpu/drm/meson/meson_vclk.c
>> +++ b/drivers/gpu/drm/meson/meson_vclk.c
>> @@ -113,9 +113,12 @@
>> #define HHI_HDMI_PLL_CNTL4 0x32C /* 0xcb offset in data sheet */
>> #define HHI_HDMI_PLL_CNTL5 0x330 /* 0xcc offset in data sheet */
>> #define HHI_HDMI_PLL_CNTL6 0x334 /* 0xcd offset in data sheet */
>> +#define HHI_HDMI_PLL_CNTL7 0x338 /* 0xce offset in data sheet */
>>
>> #define HDMI_PLL_RESET BIT(28)
>> +#define HDMI_PLL_RESET_G12A BIT(29)
>> #define HDMI_PLL_LOCK BIT(31)
>> +#define HDMI_PLL_LOCK_G12A (3 << 30)
>
> GENMASK(31, 30) ?
Ack
>
>>
>> #define FREQ_1000_1001(_freq) DIV_ROUND_CLOSEST(_freq * 1000, 1001)
>>
>> @@ -257,6 +260,10 @@ static void meson_venci_cvbs_clock_config(struct
>> meson_drm *priv)
>> regmap_write(priv->hhi, HHI_HDMI_PLL_CNTL5, 0x71486980);
>> regmap_write(priv->hhi, HHI_HDMI_PLL_CNTL6, 0x0e55);
>> regmap_write(priv->hhi, HHI_HDMI_PLL_CNTL, 0x4800023d);
>> +
>> +/* Poll for lock bit */
>> +regmap_read_poll_timeout(priv->hhi, HHI_HDMI_PLL_CNTL, val,
>> + (val & HDMI_PLL_LOCK), 10, 0);
>> } else if (meson_vpu_is_compatible(priv, "amlogic,meson-gxm-vpu") ||
>> meson_vpu_is_compatible(priv, "amlogic,meson-gxl-vpu")) {
>> regmap_write(priv->hhi, HHI_HDMI_PLL_CNTL, 0x427b);
>> @@ -271,11 +278,26 @@ static void meson_venci_cvbs_clock_config(struct
>> meson_drm *priv)
>> HDMI_PLL_RESET, HDMI_PLL_RESET);
>> regmap_update_bits(priv->hhi, HHI_HDMI_PLL_CNTL,
>> HDMI_PLL_RESET, 0);
>> -}
>>
>> -/* Poll for lock bit */
>> -regmap_read_poll_timeout(priv->hhi, HHI_HDMI_PLL_CNTL, val,
>> - (val & HDMI_PLL_LOCK), 10, 0);
>> +/* Poll for lock bit */
>> +regmap_read_poll_timeout(priv->hhi, HHI_HDMI_PLL_CNTL, val,
>> + (val & HDMI_PLL_LOCK), 10, 0);
>> +} else if (meson_vpu_is_compatible(priv, "amlogic,meson-g12a-vpu")) {
>> +regmap_write(priv->hhi, HHI_HDMI_PLL_CNTL, 0x1a0504f7);
>> +regmap_write(priv->hhi, HHI_HDMI_PLL_CNTL2, 0x0001);
>> +regmap_write(priv->hhi, HHI_HDMI_PLL_CNTL3, 0x);
>> +regmap_write(priv->hhi, HHI_HDMI_PLL_CNTL4, 0x6a28dc00);
>> +regmap_write(priv->hhi, HHI_HDMI_PLL_CNTL5, 0x65771290);
>> +regmap_write(priv->hhi, HHI_HDMI_PLL_CNTL6, 0x39272000);
>> +regmap_write(priv->hhi, HHI_HDMI_PLL_CNTL7, 0x5654);
>> +regmap_write(priv->hhi, HHI_HDMI_PLL_CNTL, 0x3a0504f7);
>> +regmap_write(priv->hhi, HHI_HDMI_PLL_CNTL, 0x1a0504f7);
>> +
>> +/* Poll for lock bit */
>> +regmap_read_poll_timeout(priv->hhi, HHI_HDMI_PLL_CNTL, val,
>> +((val & HDMI_PLL_LOCK_G12A) == HDMI_PLL_LOCK_G12A),
>> +10, 0);
>> +}
>>
>> /* Disable VCLK2 */
>> regmap_update_bits(priv->hhi, HHI_VIID_CLK_CNTL, VCLK2_EN, 0);
>> @@ -288,8 +310,13 @@ static void meson_venci_cvbs_clock_config(struct
>> meson_drm *priv)
>> VCLK2_DIV_MASK, (55 - 1));
>>
>> /* select vid_pll for vclk2 */
>> -regmap_update_bits(priv->hhi, HHI_VIID_CLK_CNTL,
>> -VCLK2_SEL_MASK, (4 << VCLK2_SEL_SHIFT));
>> +if (meson_vpu_is_compatible(priv, "amlogic,meson-g12a-vpu"))
>> +regmap_update_bits(priv->hhi, HHI_VIID_CLK_CNTL,
>> +VCLK2_SEL_MASK, (0 << VCLK2_SEL_SHIFT));
>> +else
>> +regmap_update_bits(priv->hhi, HHI_VIID_CLK_CNTL,
>> +VCLK2_SEL_MASK, (4 << VCLK2_SEL_SHIFT));
>> +
>> /* enable vclk2 gate */
>> regmap_update_bits(priv->hhi, HHI_VIID_CLK_CNTL, VCLK2_EN, VCLK2_EN);
>>
>> @@ -476,32 +503,80 @@ void meson_hdmi_pll_set_params(struct meson_drm *priv,
>>
[Bug 110362] Need an option to set HDMI out to Full RGB 4:4:4
https://bugs.freedesktop.org/show_bug.cgi?id=110362 Michel Dänzer changed: What|Removed |Added Assignee|xorg-driver-...@lists.x.org |dri-devel@lists.freedesktop ||.org QA Contact|xorg-t...@lists.x.org | CC||harry.wentl...@amd.com, ||nicholas.kazlaus...@amd.com Component|Driver/AMDgpu |DRM/AMDgpu Product|xorg|DRI --- Comment #1 from Michel Dänzer --- This needs to be supported by the kernel driver (first), reassigning. (In reply to Heiko Lechner from comment #0) > In X.Org log file I find "AMDGPU(0): Supported color encodings: RGB 4:4:4 > YCrCb 4:4:4" so it seems to be possible. That's just Xorg itself printing information from EDID. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH RFC 2/5] drm/bridge: add encoder support to specify bridge input format
Hi Laurent,
On 29/03/2019 11:42, Neil Armstrong wrote:
> This patch adds a new format_set() callback to the bridge ops permitting
> the encoder to specify the new input format and encoding.
Is this something better ? This doesn't violate the layering anymore,
do you have any thoughts about this new API ?
Neil
>
> This allows supporting the very specific HDMI2.0 YUV420 output mode
> when the bridge cannot convert from RGB or YUV444 to YUV420.
>
> In this case, the encode must downsample before the bridge and must
> specify the bridge the new input bus format differs.
>
> This will also help supporting the YUV420 mode where the bridge cannot
> downsample, and also support 10bit, 12bit and 16bit output modes
> when the bridge cannot convert between different bit depths.
>
> Signed-off-by: Neil Armstrong
> ---
> drivers/gpu/drm/drm_bridge.c | 35 +++
> include/drm/drm_bridge.h | 19 +++
> 2 files changed, 54 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
> index 138b2711d389..b2ce2d3d070e 100644
> --- a/drivers/gpu/drm/drm_bridge.c
> +++ b/drivers/gpu/drm/drm_bridge.c
> @@ -307,6 +307,41 @@ void drm_bridge_mode_set(struct drm_bridge *bridge,
> }
> EXPORT_SYMBOL(drm_bridge_mode_set);
>
> +/**
> + * drm_bridge_format_set - setup with proposed input format and encoding for
> + * all bridges in the encoder chain
> + * @bridge: bridge control structure
> + * @input_bus_format: proposed input bus format for the bridge
> + * @input_encoding: proposed input encoding for this bridge
> + *
> + * Calls &drm_bridge_funcs.format_set op for all the bridges in the
> + * encoder chain, starting from the first bridge to the last.
> + *
> + * Note: the bridge passed should be the one closest to the encoder
> + *
> + * RETURNS:
> + * true on success, false if one of the bridge cannot handle the format
> + */
> +bool drm_bridge_format_set(struct drm_bridge *bridge,
> +const u32 input_bus_format,
> +const u32 input_encoding)
> +{
> + bool ret = true;
> +
> + if (!bridge)
> + return true;
> +
> + if (bridge->funcs->format_set)
> + ret = bridge->funcs->format_set(bridge, input_bus_format,
> + input_encoding);
> + if (ret)
> + return ret;
> +
> + return drm_bridge_format_set(bridge->next, input_bus_format,
> + input_encoding);
> +}
> +EXPORT_SYMBOL(drm_bridge_format_set);
> +
> /**
> * drm_bridge_pre_enable - prepares for enabling all
> * bridges in the encoder chain
> diff --git a/include/drm/drm_bridge.h b/include/drm/drm_bridge.h
> index 9da8c93f7976..223253b15763 100644
> --- a/include/drm/drm_bridge.h
> +++ b/include/drm/drm_bridge.h
> @@ -198,6 +198,22 @@ struct drm_bridge_funcs {
> void (*mode_set)(struct drm_bridge *bridge,
>const struct drm_display_mode *mode,
>const struct drm_display_mode *adjusted_mode);
> +
> + /**
> + * @format_set:
> + *
> + * This callback should configure the bridge for the given input bus
> + * format and encoding. It is called after the @format_set callback
> + * for the preceding element in the display pipeline has been called
> + * already. If the bridge is the first element then this would be
> + * &drm_encoder_helper_funcs.format_set. The display pipe (i.e.
> + * clocks and timing signals) is off when this function is called.
> + *
> + * @returns: true in success, false is a bridge refuses the format
> + */
> + bool (*format_set)(struct drm_bridge *bridge,
> +const u32 input_bus_format,
> +const u32 input_encoding);
> /**
>* @pre_enable:
>*
> @@ -312,6 +328,9 @@ void drm_bridge_post_disable(struct drm_bridge *bridge);
> void drm_bridge_mode_set(struct drm_bridge *bridge,
>const struct drm_display_mode *mode,
>const struct drm_display_mode *adjusted_mode);
> +bool drm_bridge_format_set(struct drm_bridge *bridge,
> +const u32 input_bus_format,
> +const u32 input_encoding);
> void drm_bridge_pre_enable(struct drm_bridge *bridge);
> void drm_bridge_enable(struct drm_bridge *bridge);
>
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/gma500: Add CedarView LVDS blacklist
On Tue, Apr 9, 2019 at 8:51 AM Hans de Goede wrote:
>
> Some CedarView VBT-s claim that there is a LVDS panel, while there is none.
> Specifically this happens on the Thecus N2800 / N5550 NAS models.
>
> This commit adds a LVDS blacklist to deal with this and adds an entry for
> the Thecus NAS-es.
Hi Hans,
Sometimes LVDS can be configured in the BIOS on CDV devices. Can you
check that it's not just a bad BIOS configuration first?
Thanks
Patrik
>
> BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1665766
> Signed-off-by: Hans de Goede
> ---
> drivers/gpu/drm/gma500/cdv_intel_lvds.c | 23 +++
> 1 file changed, 23 insertions(+)
>
> diff --git a/drivers/gpu/drm/gma500/cdv_intel_lvds.c
> b/drivers/gpu/drm/gma500/cdv_intel_lvds.c
> index de9531caaca0..268643af114c 100644
> --- a/drivers/gpu/drm/gma500/cdv_intel_lvds.c
> +++ b/drivers/gpu/drm/gma500/cdv_intel_lvds.c
> @@ -572,6 +572,20 @@ static bool lvds_is_present_in_vbt(struct drm_device
> *dev,
> return false;
> }
>
> +static const struct dmi_system_id cdv_intel_lvds_blacklist[] = {
> + {
> + /* Thecus N2800 and N5550 family NAS-es */
> + .matches = {
> + DMI_EXACT_MATCH(DMI_SYS_VENDOR, "Intel Corporation"),
> + DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "Milstead
> Platform"),
> + DMI_EXACT_MATCH(DMI_BOARD_NAME, "Granite Well"),
> + /* BIOS version is CDV_T X64 */
> + DMI_MATCH(DMI_BIOS_VERSION, "CDV_T"),
> + },
> + },
> + {}
> +};
> +
> /**
> * cdv_intel_lvds_init - setup LVDS connectors on this device
> * @dev: drm device
> @@ -594,6 +608,15 @@ void cdv_intel_lvds_init(struct drm_device *dev,
> int pipe;
> u8 pin;
>
> + /*
> +* Check blacklist for machines with BIOSes that list an LVDS panel
> +* without actually having one.
> +*/
> + if (dmi_check_system(cdv_intel_lvds_blacklist)) {
> + dev_info(&dev->pdev->dev, "System is on LVDS blacklist,
> skipping LVDS panel detection\n");
> + return;
> + }
> +
> pin = GMBUS_PORT_PANEL;
> if (!lvds_is_present_in_vbt(dev, &pin)) {
> DRM_DEBUG_KMS("LVDS is not present in VBT\n");
> --
> 2.21.0
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 108919] Parkitect (Unity Game) dispalys artifacts and black screens with Vega hardware
https://bugs.freedesktop.org/show_bug.cgi?id=108919 --- Comment #13 from andrew.m.mcma...@gmail.com --- I thought I'd try this one out as I always loved Bullfrog's Theme Park back on my AMIGA 500+ -- Parkitect 1.3 -- I've captured a more up-to-date trace: (1.8GB) https://drive.google.com/open?id=1DaekuBy9fBdQr4ceqskx_5w2m5BDt_CV > Debian Testing > Linux-drm-fixes-5.1 > Mesa 19.1.0 (4e802089) https://tinyurl.com/mesacommit > Device: AMD Radeon R9 200 Series (TONGA, DRM 3.30.0, 5.1.0-rc1+, LLVM 8.0.0) The game appears to be quite playable now. Ambient occlusion appears to be the main cause of some heavy graphical glitches - which I've shown in my trace by lowering the slider. Alien Isolation is another game that suffers from glitches with HDAO enabled but otherwise works fine with it turned off. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH V10 0/5] make mt7623 clock of hdmi stable
Hi, Wangyan:
This version still has alignment problem, but I've fixed it and for this
series,
Applied to mediatek-drm-fixes-5.1 [1], thanks.
[1]
https://github.com/ckhu-mediatek/linux.git-tags/commits/mediatek-drm-fixes-5.1
Regards,
CK
On Tue, 2019-04-09 at 14:53 +0800, wangyan wang wrote:
> From: Wangyan Wang
>
> V10 adopt maintainer's suggestion.
> Here is the change list between V9 & V10
>
> 1. Align the first character to the right of '(' in
> mtk_hdmi_phy_clk_get_data() of "drm/mediatek: remove flag ..."
> 2. Align the first character to the right of '(' in
> mtk_hdmi_pll_recalc_rate() of "drm/mediatek: make implementation ..."
> 3. Align the first character to the right of '(' in
> mtk_hdmi_pll_round_rate() of "drm/mediatek: no change ..."
> 4. move patch " drm/mediatek: make implementation ..." before
> patch "drm/mediatek: no change parent ..."
> 5. To make MT2701 HDMI stable, TVDPLL should not be adjusted and
> it's the parent clock of HDMI phy, so HDMI phy could not adjust parent
> rate. there are 3 steps to make MT2701 HDMI stable.
> 1). remove flag CLK_SET_RATE_PARENT for mt2701 hdmi phy to not propagate
> rate change to parent in "drm/mediatek: remove flag ...".
> 2). Using new factor for tvdpll in mt2701 to match divider of DPI in
> mt2701 in "drm/mediatek: using new...".
> 3). No change parent rate in round_rate() for mt2701 hdmi phy in
> "drm/mediatek: no change parent...".
>
> 6. Recalculate the rate of this clock, by querying hardware to
> make implementation of recalc_rate() to match the definition.
>
> Wangyan Wang (5):
> drm/mediatek: remove flag CLK_SET_RATE_PARENT for mt2701 hdmi phy
> drm/mediatek: fix the rate and divder of hdmi phy for MT2701
> drm/mediatek: using new factor for tvdpll in MT2701
> drm/mediatek: make implementation of recalc_rate() to match the definition
> drm/mediatek: no change parent rate in round_rate() for mt2701 hdmi phy
>
> 03_27_ck.diff | 91
> drivers/gpu/drm/mediatek/mtk_dpi.c | 8 +--
> drivers/gpu/drm/mediatek/mtk_hdmi_phy.c| 35 ++
> drivers/gpu/drm/mediatek/mtk_hdmi_phy.h| 5 +-
> drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c | 50 --
> drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c | 23 +++
> patch1.diff| 75
> patch_5_4.diff | 95
> ++
> remove_parent_flag.diff| 75
> 9 files changed, 412 insertions(+), 45 deletions(-)
> create mode 100644 03_27_ck.diff
> create mode 100644 patch1.diff
> create mode 100644 patch_5_4.diff
> create mode 100644 remove_parent_flag.diff
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/gma500: Add CedarView LVDS blacklist
Hi,
On 09-04-19 11:47, Patrik Jakobsson wrote:
On Tue, Apr 9, 2019 at 8:51 AM Hans de Goede wrote:
Some CedarView VBT-s claim that there is a LVDS panel, while there is none.
Specifically this happens on the Thecus N2800 / N5550 NAS models.
This commit adds a LVDS blacklist to deal with this and adds an entry for
the Thecus NAS-es.
Hi Hans,
Sometimes LVDS can be configured in the BIOS on CDV devices. Can you
check that it's not just a bad BIOS configuration first?
I've asked the reporter to test, but even if there is a BIOS option it
seems that the BIOS default setting is wrong and we cannot expect every
user to go into the BIOS to fix a wrong BIOS setting.
According to this blogpost, which is about the Linux the device ships with:
https://astroweasel.blogspot.com/2016/02/updating-thecus-n5550-nas-to-report.html
The pre-installed grub config includes 'video=LVDS-1:d' on the kernel
commandline, so this clearly seems to be a case where the system is just
shipping with a broken BIOS or at least with default BIOS settings which
is just as bad.
Regards,
Hans
BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1665766
Signed-off-by: Hans de Goede
---
drivers/gpu/drm/gma500/cdv_intel_lvds.c | 23 +++
1 file changed, 23 insertions(+)
diff --git a/drivers/gpu/drm/gma500/cdv_intel_lvds.c
b/drivers/gpu/drm/gma500/cdv_intel_lvds.c
index de9531caaca0..268643af114c 100644
--- a/drivers/gpu/drm/gma500/cdv_intel_lvds.c
+++ b/drivers/gpu/drm/gma500/cdv_intel_lvds.c
@@ -572,6 +572,20 @@ static bool lvds_is_present_in_vbt(struct drm_device *dev,
return false;
}
+static const struct dmi_system_id cdv_intel_lvds_blacklist[] = {
+ {
+ /* Thecus N2800 and N5550 family NAS-es */
+ .matches = {
+ DMI_EXACT_MATCH(DMI_SYS_VENDOR, "Intel Corporation"),
+ DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "Milstead Platform"),
+ DMI_EXACT_MATCH(DMI_BOARD_NAME, "Granite Well"),
+ /* BIOS version is CDV_T X64 */
+ DMI_MATCH(DMI_BIOS_VERSION, "CDV_T"),
+ },
+ },
+ {}
+};
+
/**
* cdv_intel_lvds_init - setup LVDS connectors on this device
* @dev: drm device
@@ -594,6 +608,15 @@ void cdv_intel_lvds_init(struct drm_device *dev,
int pipe;
u8 pin;
+ /*
+* Check blacklist for machines with BIOSes that list an LVDS panel
+* without actually having one.
+*/
+ if (dmi_check_system(cdv_intel_lvds_blacklist)) {
+ dev_info(&dev->pdev->dev, "System is on LVDS blacklist, skipping
LVDS panel detection\n");
+ return;
+ }
+
pin = GMBUS_PORT_PANEL;
if (!lvds_is_present_in_vbt(dev, &pin)) {
DRM_DEBUG_KMS("LVDS is not present in VBT\n");
--
2.21.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] drm/lima: add missing Kconfig dependency
Modify comments and pushed to drm-misc-next.
Thanks,
Qiang
On Tue, Apr 9, 2019 at 8:36 AM Qiang Yu wrote:
>
> Current implementation does not support MMU-less
> plarforms.
>
> Cc: Randy Dunlap
> Cc: Neil Armstrong
> Fixes: a1d2a6339961 ("drm/lima: driver for ARM Mali4xx GPUs")
> Signed-off-by: Qiang Yu
> ---
> drivers/gpu/drm/lima/Kconfig | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/gpu/drm/lima/Kconfig b/drivers/gpu/drm/lima/Kconfig
> index f11314448093..bb4ddc6bb0a6 100644
> --- a/drivers/gpu/drm/lima/Kconfig
> +++ b/drivers/gpu/drm/lima/Kconfig
> @@ -5,6 +5,9 @@ config DRM_LIMA
> tristate "LIMA (DRM support for ARM Mali 400/450 GPU)"
> depends on DRM
> depends on ARM || ARM64 || COMPILE_TEST
> + depends on MMU
> + depends on COMMON_CLK
> + depends on OF
> select DRM_SCHED
> help
> DRM driver for ARM Mali 400/450 GPUs.
> --
> 2.17.1
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] drm/lima: include used header file explicitly
Pushed to drm-misc-next.
Thanks,
Qiang
On Tue, Apr 9, 2019 at 8:37 AM Qiang Yu wrote:
>
> To prevent build fail on some platform which does
> not have it in the include file chain.
>
> Cc: Neil Armstrong
> Suggested-by: Randy Dunlap
> Fixes: a1d2a6339961 ("drm/lima: driver for ARM Mali4xx GPUs")
> Signed-off-by: Qiang Yu
> ---
> drivers/gpu/drm/lima/lima_gem.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpu/drm/lima/lima_gem.c b/drivers/gpu/drm/lima/lima_gem.c
> index 2d3cf96f6c58..1d69498bc17e 100644
> --- a/drivers/gpu/drm/lima/lima_gem.c
> +++ b/drivers/gpu/drm/lima/lima_gem.c
> @@ -1,6 +1,7 @@
> // SPDX-License-Identifier: GPL-2.0 OR MIT
> /* Copyright 2017-2019 Qiang Yu */
>
> +#include
> #include
> #include
>
> --
> 2.17.1
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH 2/2] drm/ttm: fix start page for huge page check in ttm_put_pages()
> -Original Message-
> From: Christian König [mailto:ckoenig.leichtzumer...@gmail.com]
> Sent: Monday, April 08, 2019 9:13 PM
> To: Zhang, Jerry ; Huang, Ray
> ; amd-...@lists.freedesktop.org; dri-
> de...@lists.freedesktop.org
> Subject: [PATCH 2/2] drm/ttm: fix start page for huge page check in
> ttm_put_pages()
>
> The first page entry is always the same with itself.
>
> Signed-off-by: Christian König
Reviewed-by: Huang Rui
> ---
> drivers/gpu/drm/ttm/ttm_page_alloc.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc.c
> b/drivers/gpu/drm/ttm/ttm_page_alloc.c
> index f77c81db161b..c74147f0cbe3 100644
> --- a/drivers/gpu/drm/ttm/ttm_page_alloc.c
> +++ b/drivers/gpu/drm/ttm/ttm_page_alloc.c
> @@ -732,7 +732,7 @@ static void ttm_put_pages(struct page **pages,
> unsigned npages, int flags, #ifdef CONFIG_TRANSPARENT_HUGEPAGE
> if (!(flags & TTM_PAGE_FLAG_DMA32) &&
> (npages - i) >= HPAGE_PMD_NR) {
> - for (j = 0; j < HPAGE_PMD_NR; ++j)
> + for (j = 1; j < HPAGE_PMD_NR; ++j)
> if (p++ != pages[i + j])
> break;
>
> @@ -767,7 +767,7 @@ static void ttm_put_pages(struct page **pages,
> unsigned npages, int flags,
> if (!p)
> break;
>
> - for (j = 0; j < HPAGE_PMD_NR; ++j)
> + for (j = 1; j < HPAGE_PMD_NR; ++j)
> if (p++ != pages[i + j])
> break;
>
> --
> 2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH 1/2] drm/ttm: fix out-of-bounds read in ttm_put_pages() v2
> -Original Message-
> From: Christian König [mailto:ckoenig.leichtzumer...@gmail.com]
> Sent: Monday, April 08, 2019 9:13 PM
> To: Zhang, Jerry ; Huang, Ray
> ; amd-...@lists.freedesktop.org; dri-
> de...@lists.freedesktop.org
> Subject: [PATCH 1/2] drm/ttm: fix out-of-bounds read in ttm_put_pages() v2
>
> When ttm_put_pages() tries to figure out whether it's dealing with
> transparent hugepages, it just reads past the bounds of the pages array
> without a check.
>
> v2: simplify the test if enough pages are left in the array (Christian).
>
> Signed-off-by: Jann Horn
> Signed-off-by: Christian König
Reviewed-by: Huang Rui
> Fixes: 5c42c64f7d54 ("drm/ttm: fix the fix for huge compound pages")
> Cc: sta...@vger.kernel.org
> ---
> drivers/gpu/drm/ttm/ttm_page_alloc.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc.c
> b/drivers/gpu/drm/ttm/ttm_page_alloc.c
> index f841accc2c00..f77c81db161b 100644
> --- a/drivers/gpu/drm/ttm/ttm_page_alloc.c
> +++ b/drivers/gpu/drm/ttm/ttm_page_alloc.c
> @@ -730,7 +730,8 @@ static void ttm_put_pages(struct page **pages,
> unsigned npages, int flags,
> }
>
> #ifdef CONFIG_TRANSPARENT_HUGEPAGE
> - if (!(flags & TTM_PAGE_FLAG_DMA32)) {
> + if (!(flags & TTM_PAGE_FLAG_DMA32) &&
> + (npages - i) >= HPAGE_PMD_NR) {
> for (j = 0; j < HPAGE_PMD_NR; ++j)
> if (p++ != pages[i + j])
> break;
> @@ -759,7 +760,7 @@ static void ttm_put_pages(struct page **pages,
> unsigned npages, int flags,
> unsigned max_size, n2free;
>
> spin_lock_irqsave(&huge->lock, irq_flags);
> - while (i < npages) {
> + while ((npages - i) >= HPAGE_PMD_NR) {
> struct page *p = pages[i];
> unsigned j;
>
> --
> 2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110249] IGT command line tools load redundant GUI libraries
https://bugs.freedesktop.org/show_bug.cgi?id=110249
--- Comment #7 from Eero Tamminen ---
Following tools still link libigt:
-
for i in intel*; do
echo $i;
readelf -d $i | grep libigt;
done 2>/dev/null | awk '
/^intel/ {
name=$1
}
/NEEDED.*libigt.so/ {
print "-", name
}
'
- intel_audio_dump
- intel_backlight
- intel_display_crc
- intel_display_poller
- intel_dp_compliance
- intel_error_decode
- intel_firmware_decode
- intel_forcewaked
- intel_gem_info
- intel_gpu_frequency
- intel_gpu_time
- intel_gtt
- intel_guc_logger
- intel_gvtg_test
- intel_infoframes
- intel_l3_parity
- intel_lid
- intel_panel_fitter
- intel_perf_counters
- intel_reg
- intel_reg_checker
- intel_residency
- intel_stepping
- intel_vbt_decode
- intel_watermark
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH libdrm] headers: Sync with drm-next
Generated using make headers_install from the drm-next
tree - git://anongit.freedesktop.org/drm/drm
branch - drm-next
commit - 14d2bd53a47a7e1cb3e03d00a6b952734cf90f3f
The changes were as follows :-
core: (drm.h, drm_fourcc.h, drm_mode.h)
- Added 'struct drm_syncobj_transfer', 'struct drm_syncobj_timeline_wait' and
'struct drm_syncobj_timeline_array'
- Added various DRM_IOCTL_SYNCOBJ_ ioctls
- Added some new RGB and YUV formats
- Added 'DRM_FORMAT_MOD_VENDOR_ALLWINNER'
- Added 'SAMSUNG' and Arm's 'AFBC' and 'ALLWINNER' format modifiers
- Added 'struct drm_mode_rect'
i915:
- Added struct 'struct i915_user_extension' and various 'struct
drm_i915_gem_context_'
- Added different modes of per-process Graphics Translation Table
msm:
- Added various get or set GEM buffer info flags
- Added some MSM_SUBMIT_BO_ macros
- Modified 'struct drm_msm_gem_info'
Signed-off-by: Ayan Kumar halder
---
include/drm/drm.h| 36 +++
include/drm/drm_fourcc.h | 136 +++
include/drm/drm_mode.h | 23 -
include/drm/i915_drm.h | 237 ---
include/drm/msm_drm.h| 25 +++--
5 files changed, 415 insertions(+), 42 deletions(-)
diff --git a/include/drm/drm.h b/include/drm/drm.h
index 85c685a..c893f3b 100644
--- a/include/drm/drm.h
+++ b/include/drm/drm.h
@@ -729,8 +729,18 @@ struct drm_syncobj_handle {
__u32 pad;
};
+struct drm_syncobj_transfer {
+ __u32 src_handle;
+ __u32 dst_handle;
+ __u64 src_point;
+ __u64 dst_point;
+ __u32 flags;
+ __u32 pad;
+};
+
#define DRM_SYNCOBJ_WAIT_FLAGS_WAIT_ALL (1 << 0)
#define DRM_SYNCOBJ_WAIT_FLAGS_WAIT_FOR_SUBMIT (1 << 1)
+#define DRM_SYNCOBJ_WAIT_FLAGS_WAIT_AVAILABLE (1 << 2) /* wait for time point
to become available */
struct drm_syncobj_wait {
__u64 handles;
/* absolute timeout */
@@ -741,12 +751,33 @@ struct drm_syncobj_wait {
__u32 pad;
};
+struct drm_syncobj_timeline_wait {
+ __u64 handles;
+ /* wait on specific timeline point for every handles*/
+ __u64 points;
+ /* absolute timeout */
+ __s64 timeout_nsec;
+ __u32 count_handles;
+ __u32 flags;
+ __u32 first_signaled; /* only valid when not waiting all */
+ __u32 pad;
+};
+
+
struct drm_syncobj_array {
__u64 handles;
__u32 count_handles;
__u32 pad;
};
+struct drm_syncobj_timeline_array {
+ __u64 handles;
+ __u64 points;
+ __u32 count_handles;
+ __u32 pad;
+};
+
+
/* Query current scanout sequence number */
struct drm_crtc_get_sequence {
__u32 crtc_id; /* requested crtc_id */
@@ -903,6 +934,11 @@ extern "C" {
#define DRM_IOCTL_MODE_GET_LEASE DRM_IOWR(0xC8, struct
drm_mode_get_lease)
#define DRM_IOCTL_MODE_REVOKE_LEASEDRM_IOWR(0xC9, struct
drm_mode_revoke_lease)
+#define DRM_IOCTL_SYNCOBJ_TIMELINE_WAITDRM_IOWR(0xCA, struct
drm_syncobj_timeline_wait)
+#define DRM_IOCTL_SYNCOBJ_QUERYDRM_IOWR(0xCB, struct
drm_syncobj_timeline_array)
+#define DRM_IOCTL_SYNCOBJ_TRANSFER DRM_IOWR(0xCC, struct
drm_syncobj_transfer)
+#define DRM_IOCTL_SYNCOBJ_TIMELINE_SIGNAL DRM_IOWR(0xCD, struct
drm_syncobj_timeline_array)
+
/**
* Device specific ioctls should only be in their respective headers
* The device specific ioctl range is from 0x40 to 0x9f.
diff --git a/include/drm/drm_fourcc.h b/include/drm/drm_fourcc.h
index 139632b..3feeaa3 100644
--- a/include/drm/drm_fourcc.h
+++ b/include/drm/drm_fourcc.h
@@ -144,6 +144,17 @@ extern "C" {
#define DRM_FORMAT_RGBA1010102 fourcc_code('R', 'A', '3', '0') /* [31:0]
R:G:B:A 10:10:10:2 little endian */
#define DRM_FORMAT_BGRA1010102 fourcc_code('B', 'A', '3', '0') /* [31:0]
B:G:R:A 10:10:10:2 little endian */
+/*
+ * Floating point 64bpp RGB
+ * IEEE 754-2008 binary16 half-precision float
+ * [15:0] sign:exponent:mantissa 1:5:10
+ */
+#define DRM_FORMAT_XRGB16161616F fourcc_code('X', 'R', '4', 'H') /* [63:0]
x:R:G:B 16:16:16:16 little endian */
+#define DRM_FORMAT_XBGR16161616F fourcc_code('X', 'B', '4', 'H') /* [63:0]
x:B:G:R 16:16:16:16 little endian */
+
+#define DRM_FORMAT_ARGB16161616F fourcc_code('A', 'R', '4', 'H') /* [63:0]
A:R:G:B 16:16:16:16 little endian */
+#define DRM_FORMAT_ABGR16161616F fourcc_code('A', 'B', '4', 'H') /* [63:0]
A:B:G:R 16:16:16:16 little endian */
+
/* packed YCbCr */
#define DRM_FORMAT_YUYVfourcc_code('Y', 'U', 'Y', 'V') /*
[31:0] Cr0:Y1:Cb0:Y0 8:8:8:8 little endian */
#define DRM_FORMAT_YVYUfourcc_code('Y', 'V', 'Y', 'U') /*
[31:0] Cb0:Y1:Cr0:Y0 8:8:8:8 little endian */
@@ -151,6 +162,52 @@ extern "C" {
#define DRM_FORMAT_VYUYfourcc_code('V', 'Y', 'U', 'Y') /*
[31:0] Y1:Cb0:Y0:Cr0 8:8:8:8 little endian */
#define DRM_FORMAT_AYUVfourcc_code('A', 'Y', 'U', 'V') /*
[31:0] A:Y:Cb:Cr 8:8:8:8 little endian */
+#define DRM_FORMAT_XYUVfourcc_code('X', 'Y',
Re: [linux-sunxi] [PATCH v2 02/13] arm64: dts: allwinner: h6: Add Orange Pi 3 DTS
On Tue, Apr 09, 2019 at 01:31:57PM +0200, Ondřej Jirman wrote: > Hi Jagan, > > On Tue, Apr 09, 2019 at 02:08:18PM +0530, Jagan Teki wrote: > > Based on the conversation about using common dtsi from this thread[1], > > I'm commenting here to make show the diff directly on the nodes, > > giving comments on each node so-that we can see the diff globally. > > Thanks for the suggestions below. It mostly repeats the differences and > commonalities I already stated in the previous discussion. > > I don't have much to add to what I already said previously, though, because > you > didn't address my concerns there. But I can restate and expand on those > concerns. > > Previously I already agreed it's possible to base orangepi-3.dts on > orangepi.dtsi, and proposed a maintainable way forward, and why to follow it > (to > quote myself): > > Schematics allow for high amount of variability in the power tree (see all > the > NC (not connected) / 0R resistors) in the schematic around AXP805. Every > board > based on this Xunlong design can be subtly different. > > I already suggested a maintainable solution, below. Where base dtsi has > empty > config for regulators and every board based on that just defines it > completely > for itself. > > A few regulators (for CPU/GPU) will most probably have the same meaning on > every derived board, so these can probably be kept in dtsi without causing > too > much annoyance. > > It's unpleasant to have wrong regulator setup defined in an underlying dtsi, > and then trying to override it by removing/adding random properties in the > board dts for the new boards based on that, so that it fits. > > The rest of the current HW descriptions in the sun50i-h6-orangepi.dtsi can > be > shared (as of now). > > My suggestion was this: > > So to base Orange Pi 3 dts on top of existing sun50i-h6-orangepi.dtsi I'd > have > to first move some things out of the base dtsi to the OrangePi Lite2 and One > Plus board dts files, in order to have sun50i-h6-orangepi.dtsi only describe > HW that is *really* shared by these 2 boards and Orange Pi 3. > > If I do that, I'd undefine all the axp805 regulator nodes and move the > configurations to each of the 3 board files. That will probably end up being > the least confusing and most maintainable. See axp81x.dtsi lines 86-144 for > what I mean. > > You seem to be suggesting a solution where every time we add an OrangePi H6 > based board, the person adding it will have to go through the base dtsi and > all > the other boards based on it, status disable or otherwise change regulators in > the base dtsi, patch all the other boards to re-enable it. > > It would be already unpleasant just adding a third board based on this > approach. > And when the fourth board is added, with another small differences in the > regulator use/meanings, the person will be looking at patching 4 dts files > + adding one for his own board. For what benefit, to save some bytes right > now? > > I think maintainability, ease of adding new boards is more important, than > having a dtsi that tries to maximally cover all the commonalities between the > existing boards right now, without regards for the future. That's why > I suggested an approach like in axp81x.dtsi lines 86-144. I agree. Maxime -- Maxime Ripard, Bootlin Embedded Linux and Kernel engineering https://bootlin.com signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Need a pair decrement for fence's refcount if ttm_bo_add_move_fence failed?
Am 09.04.19 um 10:21 schrieb 易林:
>
>
>
>> Am 07.04.19 um 13:44 schrieb 易林:
>>> Hi, all:
>>> when analyzing v5.1 source code, I notice that in
>>> ttm_bo_add_move_fence,
>>> when reservation_object_reserve_shared failed and return ENOMEM,
>>> the fence's refcount increased without a pair decrement even after return
>>> to ttm_bo_add_move_fence's caller ttm_bo_mem_force_space:
>>>
>>> static int ttm_bo_add_move_fence(struct ttm_buffer_object *bo,
>>> struct ttm_mem_type_manager *man,
>>> struct ttm_mem_reg *mem)
>>> {
>>> ..
>>> fence = dma_fence_get(man->move);
>>> spin_unlock(&man->move_lock);
>>>
>>> if (fence) {
>>> reservation_object_add_shared_fence(bo->resv, fence);
>>>
>>> ret = reservation_object_reserve_shared(bo->resv, 1);
>>> if (unlikely(ret))
>>> return ret;
>>>
>>> dma_fence_put(bo->moving);
>>> bo->moving = fence;
>>> }
>>>
>>> return 0;
>>> }
>>>
>>> can this lead to the imbalance of the fence's refcount? though the ENOMEN
>>> almost won't be trigger.
>> Yeah, the fence is leaked in the error path. Feel free to provide a
>> patch to fix this.
>>
>> Otherwise I will provide one in the next merge window.
>>
>> Thanks,
>> Christian.
>>
>>> Best Regards
>>>
>>> Lin Yi
> when I git clone your maintained subsystem from
> 'git://people.freedesktop.org/~agd5f/linux' provided on Maintainer list, why
> all the commits is below 2011?
>
> so where can I get the newest subsystem version?
That URL looks correct to me. Our development branch is
amd-staging-drm-next. No idea why you only see old commits.
See here for example:
https://cgit.freedesktop.org/~agd5f/linux/log/?h=amd-staging-drm-next
Alex updates that one from an internal server every few days.
Regards,
Christian.
>
> Thanks,
> Lin Yi.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 00/15] Share TTM code among framebuffer drivers
Am 09.04.19 um 10:29 schrieb kra...@redhat.com: Hi, The qemu stdvga (bochs driver) has 16 MB vram by default and can be configured to have up to 256 MB. Plenty of room even for multiple 4k framebuffers if needed. So for the bochs driver all the ttm bo migration logic is not needed, it could just store everything in vram. To clarify I assume you mean it doesn't need the migrate each bo logic, but it still needs the when VRAM fills up migrate stuff logic. I think even the "when vram fills up" logic isn't that important. The driver has no acceleration so there is nothing to store beside dumb framebuffers, and the vram size can easily be increased if needed. Yeah, cause in this particular case it is not even real VRAM. In this case VRAM is backed by system memory which in turn is stolen from the host system isn't it? So just have enough for a framebuffer and don't place anything else in there. Regards, Christian. cheers, Gerd ___ 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
[PATCH 2/4] drm: use convert_lines() in xrgb8888_to_rgb565 helpers.
Also add two conversion functions for the swab / not swab cases.
That way we have to check the swab flag only once.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/drm_format_helper.c | 117 +++-
1 file changed, 62 insertions(+), 55 deletions(-)
diff --git a/drivers/gpu/drm/drm_format_helper.c
b/drivers/gpu/drm/drm_format_helper.c
index f32e0173600c..b8d17cd0a9f8 100644
--- a/drivers/gpu/drm/drm_format_helper.c
+++ b/drivers/gpu/drm/drm_format_helper.c
@@ -38,6 +38,46 @@ static struct drm_format_convert convert_swab16 = {
.func = convert_swab16_fn,
};
+static void convert_xrgb_to_rgb565_fn(void *dst, void *src, u32 pixels)
+{
+ u32 *sbuf = src;
+ u16 *dbuf = dst;
+ u32 x;
+
+ for (x = 0; x < pixels; x++) {
+ dbuf[x] = ((sbuf[x] & 0x00F8) >> 8) |
+ ((sbuf[x] & 0xFC00) >> 5) |
+ ((sbuf[x] & 0x00F8) >> 3);
+ }
+}
+
+static struct drm_format_convert convert_xrgb_to_rgb565 = {
+ .dst_cpp = 2,
+ .src_cpp = 4,
+ .func = convert_xrgb_to_rgb565_fn,
+};
+
+static void convert_xrgb_to_rgb565_swab_fn(void *dst, void *src, u32
pixels)
+{
+ u32 *sbuf = src;
+ u16 *dbuf = dst;
+ u16 val16;
+ u32 x;
+
+ for (x = 0; x < pixels; x++) {
+ val16 = ((sbuf[x] & 0x00F8) >> 8) |
+ ((sbuf[x] & 0xFC00) >> 5) |
+ ((sbuf[x] & 0x00F8) >> 3);
+ dbuf[x] = swab16(val16);
+ }
+}
+
+static struct drm_format_convert convert_xrgb_to_rgb565_swap = {
+ .dst_cpp = 2,
+ .src_cpp = 4,
+ .func = convert_xrgb_to_rgb565_swab_fn,
+};
+
static void convert_lines(void *dst, unsigned int dst_pitch,
void *src, unsigned int src_pitch,
unsigned int pixels,
@@ -152,44 +192,6 @@ void drm_fb_swab16(u16 *dst, void *vaddr, struct
drm_framebuffer *fb,
}
EXPORT_SYMBOL(drm_fb_swab16);
-static void drm_fb_xrgb_to_rgb565_lines(void *dst, unsigned int dst_pitch,
- void *src, unsigned int src_pitch,
- unsigned int src_linelength,
- unsigned int lines,
- bool swap)
-{
- unsigned int linepixels = src_linelength / sizeof(u32);
- unsigned int x, y;
- u32 *sbuf;
- u16 *dbuf, val16;
-
- /*
-* The cma memory is write-combined so reads are uncached.
-* Speed up by fetching one line at a time.
-*/
- sbuf = kmalloc(src_linelength, GFP_KERNEL);
- if (!sbuf)
- return;
-
- for (y = 0; y < lines; y++) {
- memcpy(sbuf, src, src_linelength);
- dbuf = dst;
- for (x = 0; x < linepixels; x++) {
- val16 = ((sbuf[x] & 0x00F8) >> 8) |
- ((sbuf[x] & 0xFC00) >> 5) |
- ((sbuf[x] & 0x00F8) >> 3);
- if (swap)
- *dbuf++ = swab16(val16);
- else
- *dbuf++ = val16;
- }
- src += src_pitch;
- dst += dst_pitch;
- }
-
- kfree(sbuf);
-}
-
/**
* drm_fb_xrgb_to_rgb565 - Convert XRGB to RGB565 clip buffer
* @dst: RGB565 destination buffer
@@ -208,15 +210,17 @@ void drm_fb_xrgb_to_rgb565(void *dst, void *vaddr,
struct drm_framebuffer *fb,
struct drm_rect *clip, bool swap)
{
- unsigned int src_offset = (clip->y1 * fb->pitches[0])
- + (clip->x1 * sizeof(u32));
- size_t src_len = (clip->x2 - clip->x1) * sizeof(u32);
- size_t dst_len = (clip->x2 - clip->x1) * sizeof(u16);
+ struct drm_format_convert *conv = swap
+ ? &convert_xrgb_to_rgb565_swap
+ : &convert_xrgb_to_rgb565;
+ unsigned int src_offset =
+ clip_offset(clip, fb->pitches[0], conv->src_cpp);
+ size_t pixels = (clip->x2 - clip->x1);
+ size_t lines = (clip->y2 - clip->y1);
- drm_fb_xrgb_to_rgb565_lines(dst, dst_len,
- vaddr + src_offset, fb->pitches[0],
- src_len, clip->y2 - clip->y1,
- swap);
+ convert_lines(dst, pixels * conv->dst_cpp,
+ vaddr + src_offset, fb->pitches[0],
+ pixels, lines, conv);
}
EXPORT_SYMBOL(drm_fb_xrgb_to_rgb565);
@@ -239,16 +243,19 @@ void drm_fb_xrgb_to_rgb565_dstclip(void *dst,
unsigned int dst_pitch,
void *vaddr, struct drm_framebuffer *fb,
struct drm_rect *clip, bool swa
[PATCH 0/4] drm: fix cirrus build failure on powerpc
Turned out to be a bit more difficuilt than just adding the "asm/io.h" header files. Not all architectures actually have a __io_virt() macro, so cirrus can't depend on that. The drm format helpers have to call memcpy_toio instead. So this little series add support for that. Gerd Hoffmann (4): drm: add generic convert_lines() function for format conversions. drm: use convert_lines() in xrgb_to_rgb565 helpers. drm: use convert_lines() in xrgb_to_rgb565 helpers. drm: add convert_lines_toio() variant, fix cirrus builds on powerpc. include/drm/drm_format_helper.h | 9 +- drivers/gpu/drm/cirrus/cirrus.c | 6 +- drivers/gpu/drm/drm_format_helper.c | 329 +--- 3 files changed, 215 insertions(+), 129 deletions(-) -- 2.18.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/4] drm: use convert_lines() in xrgb8888_to_rgb565 helpers.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/drm_format_helper.c | 66 +
1 file changed, 29 insertions(+), 37 deletions(-)
diff --git a/drivers/gpu/drm/drm_format_helper.c
b/drivers/gpu/drm/drm_format_helper.c
index b8d17cd0a9f8..01d9ea134618 100644
--- a/drivers/gpu/drm/drm_format_helper.c
+++ b/drivers/gpu/drm/drm_format_helper.c
@@ -78,6 +78,25 @@ static struct drm_format_convert
convert_xrgb_to_rgb565_swap = {
.func = convert_xrgb_to_rgb565_swab_fn,
};
+static void convert_xrgb_to_rgb888_fn(void *dst, void *src, u32 pixels)
+{
+ u32 *sbuf = src;
+ u8 *dbuf = dst;
+ u32 x;
+
+ for (x = 0; x < pixels; x++) {
+ *dbuf++ = (sbuf[x] & 0x00FF) >> 0;
+ *dbuf++ = (sbuf[x] & 0xFF00) >> 8;
+ *dbuf++ = (sbuf[x] & 0x00FF) >> 16;
+ }
+}
+
+static struct drm_format_convert convert_xrgb_to_rgb888 = {
+ .dst_cpp = 3,
+ .src_cpp = 4,
+ .func = convert_xrgb_to_rgb888_fn,
+};
+
static void convert_lines(void *dst, unsigned int dst_pitch,
void *src, unsigned int src_pitch,
unsigned int pixels,
@@ -259,35 +278,6 @@ void drm_fb_xrgb_to_rgb565_dstclip(void *dst, unsigned
int dst_pitch,
}
EXPORT_SYMBOL(drm_fb_xrgb_to_rgb565_dstclip);
-static void drm_fb_xrgb_to_rgb888_lines(void *dst, unsigned int dst_pitch,
- void *src, unsigned int src_pitch,
- unsigned int src_linelength,
- unsigned int lines)
-{
- unsigned int linepixels = src_linelength / 3;
- unsigned int x, y;
- u32 *sbuf;
- u8 *dbuf;
-
- sbuf = kmalloc(src_linelength, GFP_KERNEL);
- if (!sbuf)
- return;
-
- for (y = 0; y < lines; y++) {
- memcpy(sbuf, src, src_linelength);
- dbuf = dst;
- for (x = 0; x < linepixels; x++) {
- *dbuf++ = (sbuf[x] & 0x00FF) >> 0;
- *dbuf++ = (sbuf[x] & 0xFF00) >> 8;
- *dbuf++ = (sbuf[x] & 0x00FF) >> 16;
- }
- src += src_pitch;
- dst += dst_pitch;
- }
-
- kfree(sbuf);
-}
-
/**
* drm_fb_xrgb_to_rgb888_dstclip - Convert XRGB to RGB888 clip buffer
* @dst: RGB565 destination buffer
@@ -307,15 +297,17 @@ void drm_fb_xrgb_to_rgb888_dstclip(void *dst,
unsigned int dst_pitch,
void *vaddr, struct drm_framebuffer *fb,
struct drm_rect *clip)
{
- unsigned int src_offset = (clip->y1 * fb->pitches[0])
- + (clip->x1 * sizeof(u32));
- unsigned int dst_offset = (clip->y1 * dst_pitch)
- + (clip->x1 * 3);
- size_t src_len = (clip->x2 - clip->x1) * sizeof(u32);
+ struct drm_format_convert *conv = &convert_xrgb_to_rgb888;
+ unsigned int src_offset =
+ clip_offset(clip, fb->pitches[0], conv->src_cpp);
+ unsigned int dst_offset =
+ clip_offset(clip, dst_pitch, conv->dst_cpp);
+ size_t pixels = (clip->x2 - clip->x1);
+ size_t lines = (clip->y2 - clip->y1);
- drm_fb_xrgb_to_rgb888_lines(dst + dst_offset, dst_pitch,
- vaddr + src_offset, fb->pitches[0],
- src_len, clip->y2 - clip->y1);
+ convert_lines(dst + dst_offset, dst_pitch,
+ vaddr + src_offset, fb->pitches[0],
+ pixels, lines, conv);
}
EXPORT_SYMBOL(drm_fb_xrgb_to_rgb888_dstclip);
--
2.18.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/4] drm: add generic convert_lines() function for format conversions.
Introduce some infrastructure to handle format conversions:
* New struct drm_format_convert containing the cpp for src
and dst with a function pointer to actually convert a
single scanline.
* generic convert_lines() function which uses a struct
drm_format_convert pointer to convert a rectangle.
drm_fb_swab16() has been switched over to the new
convert_lines() function as showcase.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/drm_format_helper.c | 84 +
1 file changed, 63 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/drm_format_helper.c
b/drivers/gpu/drm/drm_format_helper.c
index 00d716f14173..f32e0173600c 100644
--- a/drivers/gpu/drm/drm_format_helper.c
+++ b/drivers/gpu/drm/drm_format_helper.c
@@ -16,6 +16,61 @@
#include
#include
+struct drm_format_convert {
+ u32 dst_cpp;
+ u32 src_cpp;
+ void (*func)(void *dst, void *src, u32 pixels);
+};
+
+static void convert_swab16_fn(void *dst, void *src, u32 pixels)
+{
+ u16 *sbuf = src;
+ u16 *dbuf = dst;
+ u32 x;
+
+ for (x = 0; x < pixels; x++)
+ dbuf[x] = swab16(sbuf[16]);
+}
+
+static struct drm_format_convert convert_swab16 = {
+ .dst_cpp = 2,
+ .src_cpp = 2,
+ .func = convert_swab16_fn,
+};
+
+static void convert_lines(void *dst, unsigned int dst_pitch,
+ void *src, unsigned int src_pitch,
+ unsigned int pixels,
+ unsigned int lines,
+ struct drm_format_convert *conv)
+{
+ u32 src_linelength = pixels * conv->src_cpp;
+ u32 y;
+ void *sbuf;
+
+ /*
+* The cma memory is write-combined so reads are uncached.
+* Speed up by fetching one line at a time.
+*/
+ sbuf = kmalloc(src_linelength, GFP_KERNEL);
+ if (!sbuf)
+ return;
+
+ for (y = 0; y < lines; y++) {
+ memcpy(sbuf, src, src_linelength);
+ conv->func(dst, sbuf, pixels);
+ src += src_pitch;
+ dst += dst_pitch;
+ }
+
+ kfree(sbuf);
+}
+
+static u32 clip_offset(struct drm_rect *clip, u32 pitch, u32 cpp)
+{
+ return (clip->y1 * pitch) + (clip->x1 * cpp);
+}
+
static void drm_fb_memcpy_lines(void *dst, unsigned int dst_pitch,
void *src, unsigned int src_pitch,
unsigned int linelength, unsigned int lines)
@@ -85,28 +140,15 @@ EXPORT_SYMBOL(drm_fb_memcpy_dstclip);
void drm_fb_swab16(u16 *dst, void *vaddr, struct drm_framebuffer *fb,
struct drm_rect *clip)
{
- size_t len = (clip->x2 - clip->x1) * sizeof(u16);
- unsigned int x, y;
- u16 *src, *buf;
+ struct drm_format_convert *conv = &convert_swab16;
+ unsigned int src_offset =
+ clip_offset(clip, fb->pitches[0], conv->src_cpp);
+ size_t pixels = (clip->x2 - clip->x1);
+ size_t lines = (clip->y2 - clip->y1);
- /*
-* The cma memory is write-combined so reads are uncached.
-* Speed up by fetching one line at a time.
-*/
- buf = kmalloc(len, GFP_KERNEL);
- if (!buf)
- return;
-
- for (y = clip->y1; y < clip->y2; y++) {
- src = vaddr + (y * fb->pitches[0]);
- src += clip->x1;
- memcpy(buf, src, len);
- src = buf;
- for (x = clip->x1; x < clip->x2; x++)
- *dst++ = swab16(*src++);
- }
-
- kfree(buf);
+ convert_lines(dst, pixels * conv->dst_cpp,
+ vaddr + src_offset, fb->pitches[0],
+ pixels, lines, conv);
}
EXPORT_SYMBOL(drm_fb_swab16);
--
2.18.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
