Re: Fwd: [PATCH v14 0/2] Add initial support for slimport anx7625
On Wed, Aug 19, 2020 at 02:57:14PM +0800, Hsin-Yi Wang wrote: > I think you missed this email :) > > -- Forwarded message - > From: Sam Ravnborg > Date: Tue, Aug 11, 2020 at 4:35 AM > Subject: Re: [PATCH v14 0/2] Add initial support for slimport anx7625 > To: Xin Ji > Cc: , Laurent Pinchart > , Andrzej Hajda > , Nicolas Boichat , Jernej > Skrabec , Nicolas Boichat > , Pi-Hsun Shih , Jonas > Karlman , David Airlie , Neil > Armstrong , , > , Sheng Pan , > Hsin-Yi Wang , Dan Carpenter > > Hi Sam, I missed this email. > > Hi Xin Ji. > > On Thu, Jul 09, 2020 at 04:31:09PM +0800, Xin Ji wrote: > > Hi all, > > > > The following series add support for the Slimport ANX7625 transmitter, a > > ultra-low power Full-HD 4K MIPI to DP transmitter designed for portable > > device. > > > > > > This is the v14 version, any mistakes, please let me know, I will fix it in > > the next series. > > > > Change history: > > v14: Fix comments from Sam and Nicolas > > - Check flags at drm_bridge_attach > > - Use panel_bridge instead of drm_panel > > - Fix not correct return value > > Sorry for ignoring this for so long time. > The patch applies but no longer builds. > > I could fix it locally but wanted to know if you have a later version to > be applied? > > Sam Hi Sam, there is no new version patch. We have another patch for other project, so we will upstream new patch after this patch has been merged. Thanks, Xin > > > > > > v13: Fix comments from Launrent Pinchart and Rob Herring > > - Picked up Rob's Reviewed-By > > - Add .detect and .get_edid interface in bridge funcs. > > > > v12: Fix comments from Hsin-Yi Wang > > - Rebase the code on kernel 5.7, fix DRM interface not match issue. > > > > v11: Fix comments from Rob Herring > > - Update commit message. > > - Remove unused label. > > > > v10: Fix comments from Rob Herring, Daniel. > > - Fix dt_binding_check warning. > > - Update description. > > > > v9: Fix comments from Sam, Nicolas, Daniel > > - Remove extcon interface. > > - Remove DPI support. > > - Fix dt_binding_check complains. > > - Code clean up and update description. > > > > v8: Fix comments from Nicolas. > > - Fix several coding format. > > - Update description. > > > > v7: > > - Fix critical timing(eg:odd hfp/hbp) in "mode_fixup" interface, > >enhance MIPI RX tolerance by setting register MIPI_DIGITAL_ADJ_1 to 0x3D. > > > > > > Xin Ji (2): > > dt-bindings: drm/bridge: anx7625: MIPI to DP transmitter DT schema > > drm/bridge: anx7625: Add anx7625 MIPI DSI/DPI to DP > > > > .../bindings/display/bridge/analogix,anx7625.yaml | 95 + > > drivers/gpu/drm/bridge/analogix/Kconfig|9 + > > drivers/gpu/drm/bridge/analogix/Makefile |1 + > > drivers/gpu/drm/bridge/analogix/anx7625.c | 1939 > > > > drivers/gpu/drm/bridge/analogix/anx7625.h | 391 > > 5 files changed, 2435 insertions(+) > > create mode 100644 > > Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml > > create mode 100644 drivers/gpu/drm/bridge/analogix/anx7625.c > > create mode 100644 drivers/gpu/drm/bridge/analogix/anx7625.h > > > > -- > > 2.7.4 > > > > ___ > > dri-devel mailing list > > dri-de...@lists.freedesktop.org > > https://lists.freedesktop.org/mailman/listinfo/dri-devel ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[staging:staging-testing] BUILD SUCCESS bc752d2f345bf55d71b3422a6a24890ea03168dc
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git staging-testing branch HEAD: bc752d2f345bf55d71b3422a6a24890ea03168dc staging: hikey9xx: Kconfig: add regulator dependency elapsed time: 722m configs tested: 71 configs skipped: 1 The following configs have been built successfully. More configs may be tested in the coming days. arm defconfig arm64allyesconfig arm64 defconfig arm allyesconfig arm allmodconfig powerpc powernv_defconfig arm pcm027_defconfig armmvebu_v7_defconfig arm pxa168_defconfig powerpc skiroot_defconfig ia64 allmodconfig ia64defconfig ia64 allyesconfig m68k allmodconfig m68kdefconfig m68k allyesconfig nios2 defconfig arc allyesconfig nds32 allnoconfig c6x allyesconfig nds32 defconfig nios2allyesconfig cskydefconfig alpha defconfig alphaallyesconfig xtensa allyesconfig h8300allyesconfig arc defconfig sh allmodconfig parisc defconfig s390 allyesconfig parisc allyesconfig s390defconfig i386 allyesconfig sparcallyesconfig sparc defconfig i386defconfig mips allyesconfig mips allmodconfig powerpc defconfig powerpc allyesconfig powerpc allmodconfig powerpc allnoconfig i386 randconfig-a005-20200818 i386 randconfig-a002-20200818 i386 randconfig-a001-20200818 i386 randconfig-a006-20200818 i386 randconfig-a003-20200818 i386 randconfig-a004-20200818 x86_64 randconfig-a013-20200818 x86_64 randconfig-a016-20200818 x86_64 randconfig-a012-20200818 x86_64 randconfig-a011-20200818 x86_64 randconfig-a014-20200818 x86_64 randconfig-a015-20200818 i386 randconfig-a016-20200818 i386 randconfig-a011-20200818 i386 randconfig-a015-20200818 i386 randconfig-a013-20200818 i386 randconfig-a012-20200818 i386 randconfig-a014-20200818 riscvallyesconfig riscv allnoconfig riscv defconfig riscvallmodconfig x86_64 rhel x86_64 allyesconfig x86_64rhel-7.6-kselftests x86_64 defconfig x86_64 rhel-8.3 x86_64 kexec --- 0-DAY CI Kernel Test Service, Intel Corporation https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 00/16] IOMMU driver for Kirin 960/970
On 2020-08-18 23:02, John Stultz wrote:
On Tue, Aug 18, 2020 at 9:26 AM Robin Murphy wrote:
On 2020-08-18 16:29, Mauro Carvalho Chehab wrote:
Em Tue, 18 Aug 2020 15:47:55 +0100
Basically, the DT binding has this, for IOMMU:
smmu_lpae {
compatible = "hisilicon,smmu-lpae";
};
...
dpe: dpe@e860 {
compatible = "hisilicon,kirin970-dpe";
memory-region = <&drm_dma_reserved>;
...
iommu_info {
start-addr = <0x8000>;
size = <0xbfff8000>;
};
}
This is used by kirin9xx_drm_dss.c in order to enable and use
the iommu:
static int dss_enable_iommu(struct platform_device *pdev, struct
dss_hw_ctx *ctx)
{
struct device *dev = NULL;
dev = &pdev->dev;
/* create iommu domain */
ctx->mmu_domain = iommu_domain_alloc(dev->bus);
if (!ctx->mmu_domain) {
pr_err("iommu_domain_alloc failed!\n");
return -EINVAL;
}
iommu_attach_device(ctx->mmu_domain, dev);
return 0;
}
The only place where the IOMMU domain is used is on this part of the
code(error part simplified here) [1]:
void hisi_dss_smmu_on(struct dss_hw_ctx *ctx)
{
uint64_t fama_phy_pgd_base;
uint32_t phy_pgd_base;
...
fama_phy_pgd_base = iommu_iova_to_phys(ctx->mmu_domain, 0);
phy_pgd_base = (uint32_t)fama_phy_pgd_base;
if (WARN_ON(!phy_pgd_base))
return;
set_reg(smmu_base + SMMU_CB_TTBR0, phy_pgd_base, 32, 0);
}
[1]
https://github.com/mchehab/linux/commit/36da105e719b47bbe9d6cb7e5619b30c7f3eb1bd
In other words, the driver needs to get the physical address of the frame
buffer (mapped via iommu) in order to set some DRM-specific register.
Yeah, the above code is somewhat hackish. I would love to replace
this part by a more standard approach.
OK, so from a quick look at that, my impression is that your display
controller has its own MMU and you don't need to pretend to use the
IOMMU API at all. Just have the DRM driver use io-pgtable directly to
run its own set of ARM_32_LPAE_S1 pagetables - see Panfrost for an
example (but try to ignore the wacky "Mali LPAE" format).
Yea. For the HiKey960, there was originally a similar patch series but
it was refactored out and the (still out of tree) DRM driver I'm
carrying doesn't seem to need it (though looking we still have the
iommu_info subnode in the dts that maybe needs to be cleaned up).
Indeed, I'd assume it's possible to leave the MMU off and just use CMA
buffers instead, but wiring it up properly without the downstream
mis-design should be pretty clean, so maybe that could ultimately be
shared with 960 too (assuming the hardware isn't wildly dissimilar).
I notice there's already a whole load of MMU configuration hard-coded
into the DRM driver - does iommu_info even need to be in the DT, or
could that also be decided directly by the driver? (Most other MMU-aware
DRM drivers seem to hard-code their drm_mm dimensions.) I can't imagine
the *virtual* address space limits need to vary on a per-board basis,
and they could easily be tied to the compatible if they legitimately
differ across SoCs and a simple lowest-common-denominator approach
wouldn't suffice for whatever reason.
Robin.
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 00/16] IOMMU driver for Kirin 960/970
Em Tue, 18 Aug 2020 15:02:54 -0700
John Stultz escreveu:
> On Tue, Aug 18, 2020 at 9:26 AM Robin Murphy wrote:
> > On 2020-08-18 16:29, Mauro Carvalho Chehab wrote:
> > > Em Tue, 18 Aug 2020 15:47:55 +0100
> > > Basically, the DT binding has this, for IOMMU:
> > >
> > >
> > > smmu_lpae {
> > > compatible = "hisilicon,smmu-lpae";
> > > };
> > >
> > > ...
> > > dpe: dpe@e860 {
> > > compatible = "hisilicon,kirin970-dpe";
> > > memory-region = <&drm_dma_reserved>;
> > > ...
> > > iommu_info {
> > > start-addr = <0x8000>;
> > > size = <0xbfff8000>;
> > > };
> > > }
> > >
> > > This is used by kirin9xx_drm_dss.c in order to enable and use
> > > the iommu:
> > >
> > >
> > > static int dss_enable_iommu(struct platform_device *pdev, struct
> > > dss_hw_ctx *ctx)
> > > {
> > > struct device *dev = NULL;
> > >
> > > dev = &pdev->dev;
> > >
> > > /* create iommu domain */
> > > ctx->mmu_domain = iommu_domain_alloc(dev->bus);
> > > if (!ctx->mmu_domain) {
> > > pr_err("iommu_domain_alloc failed!\n");
> > > return -EINVAL;
> > > }
> > >
> > > iommu_attach_device(ctx->mmu_domain, dev);
> > >
> > > return 0;
> > > }
> > >
> > > The only place where the IOMMU domain is used is on this part of the
> > > code(error part simplified here) [1]:
> > >
> > > void hisi_dss_smmu_on(struct dss_hw_ctx *ctx)
> > > {
> > > uint64_t fama_phy_pgd_base;
> > > uint32_t phy_pgd_base;
> > > ...
> > > fama_phy_pgd_base = iommu_iova_to_phys(ctx->mmu_domain, 0);
> > > phy_pgd_base = (uint32_t)fama_phy_pgd_base;
> > > if (WARN_ON(!phy_pgd_base))
> > > return;
> > >
> > > set_reg(smmu_base + SMMU_CB_TTBR0, phy_pgd_base, 32, 0);
> > > }
> > >
> > > [1]
> > > https://github.com/mchehab/linux/commit/36da105e719b47bbe9d6cb7e5619b30c7f3eb1bd
> > >
> > > In other words, the driver needs to get the physical address of the frame
> > > buffer (mapped via iommu) in order to set some DRM-specific register.
> > >
> > > Yeah, the above code is somewhat hackish. I would love to replace
> > > this part by a more standard approach.
> >
> > OK, so from a quick look at that, my impression is that your display
> > controller has its own MMU and you don't need to pretend to use the
> > IOMMU API at all. Just have the DRM driver use io-pgtable directly to
> > run its own set of ARM_32_LPAE_S1 pagetables - see Panfrost for an
> > example (but try to ignore the wacky "Mali LPAE" format).
>
> Yea. For the HiKey960, there was originally a similar patch series but
> it was refactored out and the (still out of tree) DRM driver I'm
> carrying doesn't seem to need it (though looking we still have the
> iommu_info subnode in the dts that maybe needs to be cleaned up).
Funny... while the Hikey 970 DRM driver has such IOMMU code, it
doesn't actually use it!
The driver has a function called hisi_dss_smmu_config() with
sets the registers on a different way in order to use IOMMU
or not, at the hisi_fb_pan_display() function. It can also
use a mode called "afbcd".
Well, this function sets both to false:
bool afbcd = false;
bool mmu_enable = false;
I ended commenting out the code which depends at the iommu
driver and everything is working as before.
So, I'll just forget about this iommu driver, as we can live
without that.
For now, I'll keep the mmu code there commented out, as
it could be useful on a future port for it to use io-pgtable.
-
Robin,
Can the Panfrost driver use io-pgtable while the KMS driver
won't be using it? Or this would cause it to not work?
My end goal here is to be able to test the Panfrost driver ;-)
Thanks,
Mauro
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] block: convert tasklets to use new tasklet_setup() API
> > > > > > > > > > > > > > > > In preparation for unconditionally passing the > > > > > > > > struct tasklet_struct pointer to all tasklet > > > > > > > > callbacks, switch to using the new tasklet_setup() > > > > > > > > and from_tasklet() to pass the tasklet pointer explicitly. > > > > > > > > > > > > > > Who came up with the idea to add a macro 'from_tasklet' that > > > > > > > is just container_of? container_of in the code would be > > > > > > > _much_ more readable, and not leave anyone guessing wtf > > > > > > > from_tasklet is doing. > > > > > > > > > > > > > > I'd fix that up now before everything else goes in... > > > > > > > > > > > > As I mentioned in the other thread, I think this makes things > > > > > > much more readable. It's the same thing that the timer_struct > > > > > > conversion did (added a container_of wrapper) to avoid the > > > > > > ever-repeating use of typeof(), long lines, etc. > > > > > > > > > > But then it should use a generic name, instead of each sub-system > > > > > using some random name that makes people look up exactly what it > > > > > does. I'm not huge fan of the container_of() redundancy, but > > > > > adding private variants of this doesn't seem like the best way > > > > > forward. Let's have a generic helper that does this, and use it > > > > > everywhere. > > > > > > > > I'm open to suggestions, but as things stand, these kinds of > > > > treewide > > > > > > On naming? Implementation is just as it stands, from_tasklet() is > > > totally generic which is why I objected to it. from_member()? Not > > > great with naming... But I can see this going further and then we'll > > > suddenly have tons of these. It's not good for readability. > > > > Since both threads seem to have petered out, let me suggest in > > kernel.h: > > > > #define cast_out(ptr, container, member) \ > > container_of(ptr, typeof(*container), member) > > > > It does what you want, the argument order is the same as container_of > > with the only difference being you name the containing structure > > instead of having to specify its type. > > I like this! Shall I send this to Linus to see if this can land in -rc2 > for use going forward? > Cool, I shall wait for it to be accepted and then spin out V2 with cast_out() -- - Allen ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 00/16] IOMMU driver for Kirin 960/970
On 2020-08-19 11:28, Mauro Carvalho Chehab wrote:
Em Tue, 18 Aug 2020 15:02:54 -0700
John Stultz escreveu:
On Tue, Aug 18, 2020 at 9:26 AM Robin Murphy wrote:
On 2020-08-18 16:29, Mauro Carvalho Chehab wrote:
Em Tue, 18 Aug 2020 15:47:55 +0100
Basically, the DT binding has this, for IOMMU:
smmu_lpae {
compatible = "hisilicon,smmu-lpae";
};
...
dpe: dpe@e860 {
compatible = "hisilicon,kirin970-dpe";
memory-region = <&drm_dma_reserved>;
...
iommu_info {
start-addr = <0x8000>;
size = <0xbfff8000>;
};
}
This is used by kirin9xx_drm_dss.c in order to enable and use
the iommu:
static int dss_enable_iommu(struct platform_device *pdev, struct
dss_hw_ctx *ctx)
{
struct device *dev = NULL;
dev = &pdev->dev;
/* create iommu domain */
ctx->mmu_domain = iommu_domain_alloc(dev->bus);
if (!ctx->mmu_domain) {
pr_err("iommu_domain_alloc failed!\n");
return -EINVAL;
}
iommu_attach_device(ctx->mmu_domain, dev);
return 0;
}
The only place where the IOMMU domain is used is on this part of the
code(error part simplified here) [1]:
void hisi_dss_smmu_on(struct dss_hw_ctx *ctx)
{
uint64_t fama_phy_pgd_base;
uint32_t phy_pgd_base;
...
fama_phy_pgd_base = iommu_iova_to_phys(ctx->mmu_domain, 0);
phy_pgd_base = (uint32_t)fama_phy_pgd_base;
if (WARN_ON(!phy_pgd_base))
return;
set_reg(smmu_base + SMMU_CB_TTBR0, phy_pgd_base, 32, 0);
}
[1]
https://github.com/mchehab/linux/commit/36da105e719b47bbe9d6cb7e5619b30c7f3eb1bd
In other words, the driver needs to get the physical address of the frame
buffer (mapped via iommu) in order to set some DRM-specific register.
Yeah, the above code is somewhat hackish. I would love to replace
this part by a more standard approach.
OK, so from a quick look at that, my impression is that your display
controller has its own MMU and you don't need to pretend to use the
IOMMU API at all. Just have the DRM driver use io-pgtable directly to
run its own set of ARM_32_LPAE_S1 pagetables - see Panfrost for an
example (but try to ignore the wacky "Mali LPAE" format).
Yea. For the HiKey960, there was originally a similar patch series but
it was refactored out and the (still out of tree) DRM driver I'm
carrying doesn't seem to need it (though looking we still have the
iommu_info subnode in the dts that maybe needs to be cleaned up).
Funny... while the Hikey 970 DRM driver has such IOMMU code, it
doesn't actually use it!
The driver has a function called hisi_dss_smmu_config() with
sets the registers on a different way in order to use IOMMU
or not, at the hisi_fb_pan_display() function. It can also
use a mode called "afbcd".
Well, this function sets both to false:
bool afbcd = false;
bool mmu_enable = false;
I ended commenting out the code which depends at the iommu
driver and everything is working as before.
So, I'll just forget about this iommu driver, as we can live
without that.
For now, I'll keep the mmu code there commented out, as
it could be useful on a future port for it to use io-pgtable.
-
Robin,
Can the Panfrost driver use io-pgtable while the KMS driver
won't be using it? Or this would cause it to not work?
My end goal here is to be able to test the Panfrost driver ;-)
Yup, the GPU has its own independent MMU, so Panfrost can import display
buffers regardless of whether they're physically contiguous or not.
Since Mesa master has recently landed AFBC support, there's probably
more immediate benefit in getting that AFBC decoder working before the
display MMU (although ultimately things are likely to work better under
memory pressure if you don't have to rely on CMA, so it should still be
worth coming back to at some point).
Robin.
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 27/49] staging: hikey9xx/gpu: place vblank enable/disable at the right place
Those methods belong to crtc fops
Signed-off-by: Mauro Carvalho Chehab
---
.../staging/hikey9xx/gpu/kirin9xx_drm_dss.c | 21 ++-
1 file changed, 11 insertions(+), 10 deletions(-)
diff --git a/drivers/staging/hikey9xx/gpu/kirin9xx_drm_dss.c
b/drivers/staging/hikey9xx/gpu/kirin9xx_drm_dss.c
index e7907a0b511c..e1f2557a6be1 100644
--- a/drivers/staging/hikey9xx/gpu/kirin9xx_drm_dss.c
+++ b/drivers/staging/hikey9xx/gpu/kirin9xx_drm_dss.c
@@ -391,24 +391,26 @@ static void dss_power_down(struct dss_crtc *acrtc)
ctx->power_on = false;
}
-static int dss_enable_vblank(struct drm_device *dev, unsigned int pipe)
+static int dss_enable_vblank(struct drm_crtc *crtc)
{
- struct kirin_drm_private *priv = dev->dev_private;
- struct dss_crtc *acrtc = to_dss_crtc(priv->crtc[pipe]);
+ struct dss_crtc *acrtc = to_dss_crtc(crtc);
struct dss_hw_ctx *ctx = acrtc->ctx;
- if (!ctx->power_on)
+ DRM_INFO("%s\n", __func__);
+ if (!ctx->power_on) {
+ DRM_INFO("Enabling vblank\n");
(void)dss_power_up(acrtc);
+ }
return 0;
}
-static void dss_disable_vblank(struct drm_device *dev, unsigned int pipe)
+static void dss_disable_vblank(struct drm_crtc *crtc)
{
- struct kirin_drm_private *priv = dev->dev_private;
- struct dss_crtc *acrtc = to_dss_crtc(priv->crtc[pipe]);
+ struct dss_crtc *acrtc = to_dss_crtc(crtc);
struct dss_hw_ctx *ctx = acrtc->ctx;
+ DRM_INFO("%s\n", __func__);
if (!ctx->power_on) {
DRM_ERROR("power is down! vblank disable fail\n");
return;
@@ -545,6 +547,8 @@ static const struct drm_crtc_funcs dss_crtc_funcs = {
.reset = drm_atomic_helper_crtc_reset,
.atomic_duplicate_state = drm_atomic_helper_crtc_duplicate_state,
.atomic_destroy_state = drm_atomic_helper_crtc_destroy_state,
+ .enable_vblank = dss_enable_vblank,
+ .disable_vblank = dss_disable_vblank,
};
static int dss_crtc_init(struct drm_device *dev, struct drm_crtc *crtc,
@@ -928,9 +932,6 @@ static int dss_drm_init(struct drm_device *dev)
disable_irq(ctx->irq);
- dev->driver->enable_vblank = dss_enable_vblank;
- dev->driver->disable_vblank = dss_disable_vblank;
-
return 0;
}
--
2.26.2
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 29/49] staging: hikey9xx/gpu: add a possible implementation for atomic_disable
Currently, the method is empty. However, looking at the driver,
it sounds it shouldn't be hard to implement it.
Signed-off-by: Mauro Carvalho Chehab
---
drivers/staging/hikey9xx/gpu/kirin9xx_drm_dss.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/staging/hikey9xx/gpu/kirin9xx_drm_dss.c
b/drivers/staging/hikey9xx/gpu/kirin9xx_drm_dss.c
index e1f2557a6be1..26212c130b79 100644
--- a/drivers/staging/hikey9xx/gpu/kirin9xx_drm_dss.c
+++ b/drivers/staging/hikey9xx/gpu/kirin9xx_drm_dss.c
@@ -638,7 +638,14 @@ static void dss_plane_atomic_update(struct drm_plane
*plane,
static void dss_plane_atomic_disable(struct drm_plane *plane,
struct drm_plane_state *old_state)
{
- //struct dss_plane *aplane = to_dss_plane(plane);
+ // FIXME: Maybe this?
+#if 0
+ struct dss_plane *aplane = to_dss_plane(plane);
+ struct dss_crtc *acrtc = aplane->acrtc;
+
+ disable_ldi(acrtc);
+ hisifb_mctl_sw_clr(acrtc);
+#endif
}
static const struct drm_plane_helper_funcs dss_plane_helper_funcs = {
--
2.26.2
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 26/49] staging: hikey9xx/gpu: use default GEM_CMA fops
Instead of implementing it at the code, use the default
methods from CMA helper
Signed-off-by: Mauro Carvalho Chehab
---
drivers/staging/hikey9xx/gpu/kirin9xx_drm_drv.c | 14 +-
1 file changed, 1 insertion(+), 13 deletions(-)
diff --git a/drivers/staging/hikey9xx/gpu/kirin9xx_drm_drv.c
b/drivers/staging/hikey9xx/gpu/kirin9xx_drm_drv.c
index cede6ccc2dd5..44f7c15f386a 100644
--- a/drivers/staging/hikey9xx/gpu/kirin9xx_drm_drv.c
+++ b/drivers/staging/hikey9xx/gpu/kirin9xx_drm_drv.c
@@ -141,19 +141,7 @@ static int kirin_drm_kms_init(struct drm_device *dev)
return ret;
}
-static const struct file_operations kirin_drm_fops = {
- .owner = THIS_MODULE,
- .open = drm_open,
- .release= drm_release,
- .unlocked_ioctl = drm_ioctl,
-#ifdef CONFIG_COMPAT
- .compat_ioctl = drm_compat_ioctl,
-#endif
- .poll = drm_poll,
- .read = drm_read,
- .llseek = no_llseek,
- .mmap = drm_gem_cma_mmap,
-};
+DEFINE_DRM_GEM_CMA_FOPS(kirin_drm_fops);
static int kirin_gem_cma_dumb_create(struct drm_file *file,
struct drm_device *dev,
--
2.26.2
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 00/49] DRM driver for Hikey 970
This patch series port the out-of-tree driver for Hikey 970 (which should also support Hikey 960) from the official 96boards tree: https://github.com/96boards-hikey/linux/tree/hikey970-v4.9 Based on his history, this driver seems to be originally written for Kernel 4.4, and was later ported to Kernel 4.9. The original driver used to depend on ION (from Kernel 4.4) and had its own implementation for FB dev API. As I need to preserve the original history (with has patches from both HiSilicon and from Linaro), I'm starting from the original patch applied there. The remaining patches are incremental, and port this driver to work with upstream Kernel. This driver doesn't depend on any firmware or on any special userspace code. It works as-is with both X11 and Wayland. Yet, I'm submitting it via staging due to the following reasons: - It depends on the LDO3 power supply, which is provided by a regulator driver that it is currently on staging; - Due to legal reasons, I need to preserve the authorship of each one responsbile for each patch. So, I need to start from the original patch from Kernel 4.4; - There are still some problems I need to figure out how to solve: - The adv7535 can't get EDID data. Maybe it is a timing issue, but it requires more research to be sure about how to solve it; - The driver only accept resolutions on a defined list, as there's a known bug that this driver may have troubles with random resolutions. Probably due to a bug at the pixel clock settings; - Sometimes (at least with 1080p), it generates LDI underflow errors, which in turn causes the DRM to stop working. That happens for example when using gdm on Wayland and gnome on X11; - Probably related to the previous issue, when the monitor suspends due to DPMS, it doesn't return back to life. So, IMO, the best is to keep it on staging for a while, until those remaining bugs gets solved. I added this series, together with the regulator driver and a few other patches (including a hack to fix a Kernel 5.8 regression at WiFi ) at: https://gitlab.freedesktop.org/mchehab_kernel/hikey-970/-/commits/master Chen Feng (1): staging: hikey9xx: Add hisilicon DRM driver for hikey960/970 John Stultz (1): staging: hikey9xx/gpu: port it to work with Kernel v4.9 Liwei Cai (2): staging: hikey9xx/gpu: solve tearing issue of display staging: hikey9xx/gpu: resolve the performance issue by interrupt mechanism Mauro Carvalho Chehab (38): staging: hikey9xx/gpu: get rid of adv7535 fork staging: hikey9xx/gpu: rename the Kirin9xx namespace staging: hikey9xx/gpu: get rid of kirin9xx_fbdev.c staging: hikey9xx/gpu: get rid of some ifdefs staging: hikey9xx/gpu: rename the config option for Kirin970 staging: hikey9xx/gpu: change the includes to reflect upstream staging: hikey9xx/gpu: port driver to upstream kAPIs staging: hikey9xx/gpu: add a copy of set_reg() function there staging: hikey9xx/gpu: get rid of ION headers staging: hikey9xx/gpu: add support for using a reserved CMA memory staging: hikey9xx/gpu: cleanup encoder attach logic staging: hikey9xx/gpu: Change the logic which sets the burst mode staging: hikey9xx/gpu: fix the DRM setting logic staging: hikey9xx/gpu: do some code cleanups staging: hikey9xx/gpu: use default GEM_CMA fops staging: hikey9xx/gpu: place vblank enable/disable at the right place staging: hikey9xx/gpu: remove an uneeded hack staging: hikey9xx/gpu: add a possible implementation for atomic_disable staging: hikey9xx/gpu: register connector staging: hikey9xx/gpu: fix driver name staging: hikey9xx/gpu: get rid of iommu_format staging: hikey9xx/gpu: re-work the mode validation code staging: hikey9xx/gpu: add support for enable/disable ldo3 regulator staging: hikey9xx/gpu: add SPMI headers staging: hikey9xx/gpu: solve most coding style issues staging: hikey9xx/gpu: don't use iommu code staging: hikey9xx/gpu: add kirin9xx driver to the building system staging: hikey9xx/gpu: get rid of typedefs staging: hikey9xx/gpu: get rid of input/output macros staging: hikey9xx/gpu: get rid of some unused data staging: hikey9xx/gpu: place common definitions at kirin9xx_dpe.h staging: hikey9xx/gpu: get rid of DRM_HISI_KIRIN970 dts: hisilicon: hi3670.dtsi: add I2C settings dts: hikey970-pinctrl.dtsi: add missing pinctrl settings dt: hisilicon: add support for the PMIC found on Hikey 970 dts: add support for Hikey 970 DRM staging: hikey9xx/gpu: drop kirin9xx_pwm dt: display: Add binds for the DPE and DSI controller for Kirin 960/970 Xiubin Zhang (7): staging: hikey9xx/gpu: add support to hikey970 HDMI and panel staging: hikey9xx/gpu: Solve SR Cannot Display Problems. staging: hikey9xx/gpu: Solve HDMI compatibility Problem. staging: hikey9xx/gpu: Support MIPI DSI 3 lanes for hikey970. staging: hikey9xx/gpu: Solve SR test reset problem for hikey970. staging: hikey9xx/gpu: add debug
[PATCH 25/49] staging: hikey9xx/gpu: do some code cleanups
- Get rid of a global var meant to store one of its priv
structs;
- Change the name of the driver, in order to not be confused with
the kirin6220;
- Remove some unneeded ifdef;
- use drm_of.h helper.
Signed-off-by: Mauro Carvalho Chehab
---
.../staging/hikey9xx/gpu/kirin9xx_drm_drv.c | 81 +++
1 file changed, 30 insertions(+), 51 deletions(-)
diff --git a/drivers/staging/hikey9xx/gpu/kirin9xx_drm_drv.c
b/drivers/staging/hikey9xx/gpu/kirin9xx_drm_drv.c
index fee686760c78..cede6ccc2dd5 100644
--- a/drivers/staging/hikey9xx/gpu/kirin9xx_drm_drv.c
+++ b/drivers/staging/hikey9xx/gpu/kirin9xx_drm_drv.c
@@ -25,20 +25,22 @@
#include
#include
#include
+#include
#include
#include
#include "kirin9xx_drm_drv.h"
-static struct kirin_dc_ops *dc_ops;
-
static int kirin_drm_kms_cleanup(struct drm_device *dev)
{
struct kirin_drm_private *priv = dev->dev_private;
+ static struct kirin_dc_ops const *dc_ops;
if (priv->fbdev)
priv->fbdev = NULL;
+ dc_ops = of_device_get_match_data(dev->dev);
+
drm_kms_helper_poll_fini(dev);
dc_ops->cleanup(dev);
drm_mode_config_cleanup(dev);
@@ -78,6 +80,7 @@ static void kirin_drm_mode_config_init(struct drm_device *dev)
static int kirin_drm_kms_init(struct drm_device *dev)
{
struct kirin_drm_private *priv = dev->dev_private;
+ static struct kirin_dc_ops const *dc_ops;
int ret;
priv = devm_kzalloc(dev->dev, sizeof(*priv), GFP_KERNEL);
@@ -92,6 +95,7 @@ static int kirin_drm_kms_init(struct drm_device *dev)
kirin_drm_mode_config_init(dev);
/* display controller init */
+ dc_ops = of_device_get_match_data(dev->dev);
ret = dc_ops->init(dev);
if (ret)
goto err_mode_config_cleanup;
@@ -209,27 +213,17 @@ static struct drm_driver kirin_drm_driver = {
.gem_prime_vunmap = drm_gem_cma_prime_vunmap,
.gem_prime_mmap = drm_gem_cma_prime_mmap,
- .name = "kirin",
- .desc = "Hisilicon Kirin SoCs' DRM Driver",
+ .name = "kirin9xx",
+ .desc = "Hisilicon Kirin9xx SoCs' DRM Driver",
.date = "20170309",
.major = 1,
.minor = 0,
};
-#ifdef CONFIG_OF
-/* NOTE: the CONFIG_OF case duplicates the same code as exynos or imx
- * (or probably any other).. so probably some room for some helpers
- */
static int compare_of(struct device *dev, void *data)
{
return dev->of_node == data;
}
-#else
-static int compare_dev(struct device *dev, void *data)
-{
- return dev == data;
-}
-#endif
static int kirin_drm_bind(struct device *dev)
{
@@ -288,57 +282,30 @@ static const struct component_master_ops kirin_drm_ops = {
.unbind = kirin_drm_unbind,
};
-static struct device_node *kirin_get_remote_node(struct device_node *np)
-{
- struct device_node *endpoint, *remote;
-
- /* get the first endpoint, in our case only one remote node
-* is connected to display controller.
-*/
- endpoint = of_graph_get_next_endpoint(np, NULL);
- if (!endpoint) {
- DRM_ERROR("no valid endpoint node\n");
- return ERR_PTR(-ENODEV);
- }
- of_node_put(endpoint);
-
- remote = of_graph_get_remote_port_parent(endpoint);
- if (!remote) {
- DRM_ERROR("no valid remote node\n");
- return ERR_PTR(-ENODEV);
- }
- of_node_put(remote);
-
- if (!of_device_is_available(remote)) {
- DRM_ERROR("not available for remote node\n");
- return ERR_PTR(-ENODEV);
- }
-
- return remote;
-}
-
static int kirin_drm_platform_probe(struct platform_device *pdev)
{
struct device *dev = &pdev->dev;
struct device_node *np = dev->of_node;
struct component_match *match = NULL;
struct device_node *remote;
+ static struct kirin_dc_ops const *dc_ops;
int ret;
- dc_ops = (struct kirin_dc_ops *)of_device_get_match_data(dev);
+ dc_ops = of_device_get_match_data(dev);
if (!dc_ops) {
DRM_ERROR("failed to get dt id data\n");
return -EINVAL;
}
DRM_INFO("the device node is %s\n", np->name);
- remote = kirin_get_remote_node(np);
- if (IS_ERR(remote))
- return PTR_ERR(remote);
+ remote = of_graph_get_remote_node(np, 0, 0);
+ if (!remote)
+ return -ENODEV;
DRM_INFO("the device remote node is %s\n", remote->name);
- component_match_add(dev, &match, compare_of, remote);
+ drm_of_component_match_add(dev, &match, compare_of, remote);
+ of_node_put(remote);
if (ret)
DRM_ERROR("cma device init failed!");
@@ -347,13 +314,20 @@ static int kirin_drm_platform_probe(struct
platform_devi
[PATCH 24/49] staging: hikey9xx/gpu: fix the DRM setting logic
The logich which sets the MIPI parameters is currently wrong:
it is using a value stored at cur_client, with actually points
to the active location, and not to the one that it is about
to be initialized.
The entire logic sounds buggy, but for now let's just keep
following it, by adding an extra var that will tell what was
the latest attached encoder.
Signed-off-by: Mauro Carvalho Chehab
---
.../hikey9xx/gpu/kirin9xx_dw_drm_dsi.c| 38 +--
1 file changed, 19 insertions(+), 19 deletions(-)
diff --git a/drivers/staging/hikey9xx/gpu/kirin9xx_dw_drm_dsi.c
b/drivers/staging/hikey9xx/gpu/kirin9xx_dw_drm_dsi.c
index ffc8b8e61062..39ec39a6a69b 100644
--- a/drivers/staging/hikey9xx/gpu/kirin9xx_dw_drm_dsi.c
+++ b/drivers/staging/hikey9xx/gpu/kirin9xx_dw_drm_dsi.c
@@ -241,7 +241,7 @@ struct dw_dsi {
unsigned long mode_flags;
struct gpio_desc *gpio_mux;
struct dw_dsi_client client[OUT_MAX];
- enum dsi_output_client cur_client;
+ enum dsi_output_client cur_client, attached_client;
bool enable;
};
@@ -330,13 +330,12 @@ EXPORT_SYMBOL(dsi_set_output_client);
#if defined (CONFIG_DRM_HISI_KIRIN970)
static void get_dsi_dphy_ctrl(struct dw_dsi *dsi,
- struct mipi_phy_params
*phy_ctrl)
+ struct mipi_phy_params *phy_ctrl, u32 id)
{
struct mipi_panel_info *mipi = NULL;
struct drm_display_mode *mode = NULL;
u32 dphy_req_kHz;
int bpp;
- u32 id = 0;
u32 ui = 0;
u32 m_pll = 0;
u32 n_pll = 0;
@@ -364,7 +363,6 @@ static void get_dsi_dphy_ctrl(struct dw_dsi *dsi,
WARN_ON(!phy_ctrl);
WARN_ON(!dsi);
- id = dsi->cur_client;
mode = &dsi->cur_mode;
mipi = &dsi->mipi;
@@ -562,13 +560,12 @@ static void get_dsi_dphy_ctrl(struct dw_dsi *dsi,
}
#else
static void get_dsi_phy_ctrl(struct dw_dsi *dsi,
- struct mipi_phy_params
*phy_ctrl)
+struct mipi_phy_params *phy_ctrl, u32 id)
{
struct mipi_panel_info *mipi = NULL;
struct drm_display_mode *mode = NULL;
u32 dphy_req_kHz;
int bpp;
- u32 id = 0;
u32 ui = 0;
u32 m_pll = 0;
u32 n_pll = 0;
@@ -602,7 +599,6 @@ static void get_dsi_phy_ctrl(struct dw_dsi *dsi,
WARN_ON(!phy_ctrl);
WARN_ON(!dsi);
- id = dsi->cur_client;
mode = &dsi->cur_mode;
mipi = &dsi->mipi;
@@ -949,13 +945,15 @@ static void dsi_phy_tst_set(void __iomem *base, u32 reg,
u32 val)
writel(0x00, base + MIPIDSI_PHY_TST_CTRL0_OFFSET);
}
-static void mipi_config_dphy_spec1v2_parameter(struct dw_dsi *dsi, char
__iomem *mipi_dsi_base)
+static void mipi_config_dphy_spec1v2_parameter(struct dw_dsi *dsi,
+ char __iomem *mipi_dsi_base,
+ u32 id)
{
uint32_t i;
uint32_t addr = 0;
u32 lanes;
- lanes = dsi->client[dsi->cur_client].lanes - 1;
+ lanes = dsi->client[id].lanes - 1;
for (i = 0; i <= (lanes + 1); i++) {
//Lane Transmission Property
addr = MIPIDSI_PHY_TST_LANE_TRANSMISSION_PROPERTY + (i << 5);
@@ -1027,13 +1025,13 @@ static void mipi_config_dphy_spec1v2_parameter(struct
dw_dsi *dsi, char __iomem
}
}
-static void dsi_mipi_init(struct dw_dsi *dsi, char __iomem *mipi_dsi_base)
+static void dsi_mipi_init(struct dw_dsi *dsi, char __iomem *mipi_dsi_base,
+ u32 id)
{
u32 hline_time = 0;
u32 hsa_time = 0;
u32 hbp_time = 0;
u64 pixel_clk = 0;
- u32 id = 0;
unsigned long dw_jiffies = 0;
u32 tmp = 0;
bool is_ready = false;
@@ -1048,8 +1046,6 @@ static void dsi_mipi_init(struct dw_dsi *dsi, char
__iomem *mipi_dsi_base)
WARN_ON(!dsi);
WARN_ON(!mipi_dsi_base);
- id = dsi->cur_client;
-
DRM_INFO("dsi_mipi_init, id=%d\n", id);
@@ -1063,9 +1059,9 @@ static void dsi_mipi_init(struct dw_dsi *dsi, char
__iomem *mipi_dsi_base)
memset(&dsi->phy, 0, sizeof(struct mipi_phy_params));
#if defined (CONFIG_DRM_HISI_KIRIN970)
- get_dsi_dphy_ctrl(dsi, &dsi->phy);
+ get_dsi_dphy_ctrl(dsi, &dsi->phy, id);
#else
- get_dsi_phy_ctrl(dsi, &dsi->phy);
+ get_dsi_phy_ctrl(dsi, &dsi->phy, id);
#endif
rect.x = 0;
@@ -1113,7 +1109,7 @@ static void dsi_mipi_init(struct dw_dsi *dsi, char
__iomem *mipi_dsi_base)
dsi_phy_tst_set(mipi_dsi_base, 0x004B, 0x1);
//set dphy spec parameter
- mipi_config_dphy_spec1v2_parameter(dsi, mipi_dsi_base);
+ mipi_config_dphy_spec1v2_parameter(dsi, mipi_dsi_base, id);
#else
/* physical configuration PLL I*/
dsi_phy_tst_set(mipi_dsi_base, 0x14,
@@ -1363,12 +1359,13 @@ static void dsi_encoder_disable(s
[PATCH 11/49] staging: hikey9xx/gpu: Add support 10.1 inch special HDMI displays.
From: Xiubin Zhang
Adjust pixel clock for compatibility with 10.1 inch special displays.
Signed-off-by: Xiubin Zhang
Signed-off-by: Mauro Carvalho Chehab
---
drivers/staging/hikey9xx/gpu/kirin_drm_dss.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/staging/hikey9xx/gpu/kirin_drm_dss.c
b/drivers/staging/hikey9xx/gpu/kirin_drm_dss.c
index 11d847e2da3d..693f5499c8d0 100644
--- a/drivers/staging/hikey9xx/gpu/kirin_drm_dss.c
+++ b/drivers/staging/hikey9xx/gpu/kirin_drm_dss.c
@@ -270,6 +270,10 @@ static void dss_ldi_set_mode(struct dss_crtc *acrtc)
else
clk_Hz = mode->clock * 1000UL;
+ /* Adjust pixel clock for compatibility with 10.1 inch special
displays. */
+ if (mode->clock == 148500 && mode->width_mm == 532 &&
mode->height_mm == 299)
+ clk_Hz = 152000 * 1000UL;
+
DRM_INFO("HDMI real need clock = %llu \n", clk_Hz);
hdmi_pxl_ppll7_init(ctx, clk_Hz);
adj_mode->clock = clk_Hz / 1000;
--
2.26.2
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 15/49] staging: hikey9xx/gpu: get rid of some ifdefs
There are some #ifdefs there for non-existing CONFIG_ options
(nor even at the downstream code).
Let's get rid of those. It can be re-added later if ever needed.
Signed-off-by: Mauro Carvalho Chehab
---
.../hikey9xx/gpu/kirin9xx_drm_dpe_utils.c | 36 ---
.../hikey9xx/gpu/kirin9xx_drm_dpe_utils.h | 4 ---
.../hikey9xx/gpu/kirin9xx_drm_overlay_utils.c | 14
3 files changed, 54 deletions(-)
diff --git a/drivers/staging/hikey9xx/gpu/kirin9xx_drm_dpe_utils.c
b/drivers/staging/hikey9xx/gpu/kirin9xx_drm_dpe_utils.c
index 887c5d609ab6..8aa43619c888 100644
--- a/drivers/staging/hikey9xx/gpu/kirin9xx_drm_dpe_utils.c
+++ b/drivers/staging/hikey9xx/gpu/kirin9xx_drm_dpe_utils.c
@@ -275,17 +275,8 @@ void init_ldi(struct dss_crtc *acrtc)
/*ldi_data_gate(ctx, true);*/
-#ifdef CONFIG_HISI_FB_LDI_COLORBAR_USED
- /* colorbar width*/
- set_reg(ldi_base + LDI_CTRL, DSS_WIDTH(0x3c), 7, 6);
- /* colorbar ort*/
- set_reg(ldi_base + LDI_WORK_MODE, 0x0, 1, 1);
- /* colorbar enable*/
- set_reg(ldi_base + LDI_WORK_MODE, 0x0, 1, 0);
-#else
/* normal*/
set_reg(ldi_base + LDI_WORK_MODE, 0x1, 1, 0);
-#endif
/* ldi disable*/
set_reg(ldi_base + LDI_CTRL, 0x0, 1, 0);
@@ -493,33 +484,6 @@ void init_dpp(struct dss_crtc *acrtc)
(DSS_HEIGHT(mode->vdisplay) << 16) | DSS_WIDTH(mode->hdisplay));
outp32(dpp_base + DPP_IMG_SIZE_AFT_SR,
(DSS_HEIGHT(mode->vdisplay) << 16) | DSS_WIDTH(mode->hdisplay));
-
-#ifdef CONFIG_HISI_FB_DPP_COLORBAR_USED
- #if defined (CONFIG_HISI_FB_970)
- outp32(dpp_base + DPP_CLRBAR_CTRL, (0x30 << 24) | (0 << 1) | 0x1);
- set_reg(dpp_base + DPP_CLRBAR_1ST_CLR, 0x3FF0, 30, 0); //Red
- set_reg(dpp_base + DPP_CLRBAR_2ND_CLR, 0x000FFC00, 30, 0); //Green
- set_reg(dpp_base + DPP_CLRBAR_3RD_CLR, 0x03FF, 30, 0); //Blue
- #else
- void __iomem *mctl_base;
- outp32(dpp_base + DPP_CLRBAR_CTRL, (0x30 << 24) | (0 << 1) | 0x1);
- set_reg(dpp_base + DPP_CLRBAR_1ST_CLR, 0xFF, 8, 16);
- set_reg(dpp_base + DPP_CLRBAR_2ND_CLR, 0xFF, 8, 8);
- set_reg(dpp_base + DPP_CLRBAR_3RD_CLR, 0xFF, 8, 0);
-
- mctl_base = ctx->base +
- g_dss_module_ovl_base[DSS_OVL0][MODULE_MCTL_BASE];
-
- set_reg(mctl_base + MCTL_CTL_MUTEX, 0x1, 1, 0);
- set_reg(mctl_base + MCTL_CTL_EN, 0x1, 32, 0);
- set_reg(mctl_base + MCTL_CTL_TOP, 0x2, 32, 0); /*auto mode*/
- set_reg(mctl_base + MCTL_CTL_DBG, 0xB13A00, 32, 0);
-
- set_reg(mctl_base + MCTL_CTL_MUTEX_ITF, 0x1, 2, 0);
- set_reg(mctl_sys_base + MCTL_OV0_FLUSH_EN, 0x8, 4, 0);
- set_reg(mctl_base + MCTL_CTL_MUTEX, 0x0, 1, 0);
- #endif
-#endif
}
void enable_ldi(struct dss_crtc *acrtc)
diff --git a/drivers/staging/hikey9xx/gpu/kirin9xx_drm_dpe_utils.h
b/drivers/staging/hikey9xx/gpu/kirin9xx_drm_dpe_utils.h
index b0bcc5d7a0c1..5ef5c6c6edbb 100644
--- a/drivers/staging/hikey9xx/gpu/kirin9xx_drm_dpe_utils.h
+++ b/drivers/staging/hikey9xx/gpu/kirin9xx_drm_dpe_utils.h
@@ -21,10 +21,6 @@
#endif
#include "kirin_drm_drv.h"
-/*#define CONFIG_HISI_FB_OV_BASE_USED*/
-/*#define CONFIG_HISI_FB_DPP_COLORBAR_USED*/
-/*#define CONFIG_HISI_FB_LDI_COLORBAR_USED*/
-
void set_reg(char __iomem *addr, uint32_t val, uint8_t bw, uint8_t bs);
uint32_t set_bits32(uint32_t old_val, uint32_t val, uint8_t bw, uint8_t bs);
diff --git a/drivers/staging/hikey9xx/gpu/kirin9xx_drm_overlay_utils.c
b/drivers/staging/hikey9xx/gpu/kirin9xx_drm_overlay_utils.c
index a1f58c5f7239..6246316d81b0 100644
--- a/drivers/staging/hikey9xx/gpu/kirin9xx_drm_overlay_utils.c
+++ b/drivers/staging/hikey9xx/gpu/kirin9xx_drm_overlay_utils.c
@@ -1211,14 +1211,8 @@ int hisi_dss_ovl_base_config(struct dss_hw_ctx *ctx, u32
xres, u32 yres)
set_reg(ovl0_base + OVL_SIZE, (xres - 1) |
((yres - 1) << 16), 32, 0);
-#ifdef CONFIG_HISI_FB_OV_BASE_USED
- DRM_INFO("CONFIG_HISI_FB_OV_BASE_USED !!. \n");
- set_reg(ovl0_base + OV_BG_COLOR_RGB, 0x3FF0, 32, 0);
- set_reg(ovl0_base + OV_BG_COLOR_A, 0x3FF, 32, 0);
-#else
set_reg(ovl0_base + OV_BG_COLOR_RGB, 0x, 32, 0);
set_reg(ovl0_base + OV_BG_COLOR_A, 0x, 32, 0);
-#endif
set_reg(ovl0_base + OV_DST_STARTPOS, 0x0, 32, 0);
set_reg(ovl0_base + OV_DST_ENDPOS, (xres - 1) |
((yres - 1) << 16), 32, 0);
@@ -1228,11 +1222,7 @@ int hisi_dss_ovl_base_config(struct dss_hw_ctx *ctx, u32
xres, u32 yres)
set_reg(ovl0_base + OVL6_REG_DEFAULT, 0x1, 32, 0);
set_reg(ovl0_base + OVL6_REG_DEFAULT, 0x0, 32, 0);
set_reg(ovl0_base + OVL_SIZE, (xres - 1) | ((yres - 1) << 16),
32, 0);
-#ifdef CONFIG_HISI_FB_OV_BASE_USED
- set_reg(ovl0_base + OVL_BG_COLOR, 0x, 32, 0);
-#else
set_reg(ovl0_ba
[PATCH 41/49] staging: hikey9xx/gpu: get rid of some unused data
There are some things inside struct dss_hw_ctx that are unused.
Get rid of them.
Signed-off-by: Mauro Carvalho Chehab
---
drivers/staging/hikey9xx/gpu/kirin960_dpe_reg.h | 2 --
drivers/staging/hikey9xx/gpu/kirin970_dpe_reg.h | 3 ---
drivers/staging/hikey9xx/gpu/kirin9xx_drm_dss.c | 2 --
3 files changed, 7 deletions(-)
diff --git a/drivers/staging/hikey9xx/gpu/kirin960_dpe_reg.h
b/drivers/staging/hikey9xx/gpu/kirin960_dpe_reg.h
index cd248bf15503..ae4eaae14429 100644
--- a/drivers/staging/hikey9xx/gpu/kirin960_dpe_reg.h
+++ b/drivers/staging/hikey9xx/gpu/kirin960_dpe_reg.h
@@ -3081,8 +3081,6 @@ struct dss_hw_ctx {
ktime_t vsync_timestamp_prev;
struct iommu_domain *mmu_domain;
- struct ion_client *ion_client;
- struct ion_handle *ion_handle;
char __iomem *screen_base;
unsigned long smem_start;
unsigned long screen_size;
diff --git a/drivers/staging/hikey9xx/gpu/kirin970_dpe_reg.h
b/drivers/staging/hikey9xx/gpu/kirin970_dpe_reg.h
index aeae3720c889..4751b8b6423c 100644
--- a/drivers/staging/hikey9xx/gpu/kirin970_dpe_reg.h
+++ b/drivers/staging/hikey9xx/gpu/kirin970_dpe_reg.h
@@ -4068,12 +4068,9 @@ struct dss_hw_ctx {
ktime_t vsync_timestamp_prev;
struct iommu_domain *mmu_domain;
- struct ion_client *ion_client;
- struct ion_handle *ion_handle;
char __iomem *screen_base;
unsigned long smem_start;
unsigned long screen_size;
- struct dss_smmu smmu;
};
struct dss_clk_rate {
diff --git a/drivers/staging/hikey9xx/gpu/kirin9xx_drm_dss.c
b/drivers/staging/hikey9xx/gpu/kirin9xx_drm_dss.c
index 292e14d2edf5..6792ac6fa8dc 100644
--- a/drivers/staging/hikey9xx/gpu/kirin9xx_drm_dss.c
+++ b/drivers/staging/hikey9xx/gpu/kirin9xx_drm_dss.c
@@ -976,8 +976,6 @@ static int dss_drm_init(struct drm_device *dev)
if (ret)
return ret;
- ctx->ion_client = NULL;
- ctx->ion_handle = NULL;
ctx->screen_base = 0;
ctx->screen_size = 0;
ctx->smem_start = 0;
--
2.26.2
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 13/49] staging: hikey9xx/gpu: rename the Kirin9xx namespace
There's already a driver with the same namespace
for an older Kirin chipset. Rename this one, in order
to make it clearer that this is the driver for
Kirin 960/970.
Signed-off-by: Mauro Carvalho Chehab
---
.../staging/hikey9xx/gpu/{kirin_dpe_reg.h => kirin9xx_dpe_reg.h} | 0
.../gpu/{kirin_drm_dpe_utils.c => kirin9xx_drm_dpe_utils.c} | 0
.../gpu/{kirin_drm_dpe_utils.h => kirin9xx_drm_dpe_utils.h} | 0
.../staging/hikey9xx/gpu/{kirin_drm_drv.c => kirin9xx_drm_drv.c} | 0
.../staging/hikey9xx/gpu/{kirin_drm_drv.h => kirin9xx_drm_drv.h} | 0
.../staging/hikey9xx/gpu/{kirin_drm_dss.c => kirin9xx_drm_dss.c} | 0
.../{kirin_drm_overlay_utils.c => kirin9xx_drm_overlay_utils.c} | 0
.../staging/hikey9xx/gpu/{dw_drm_dsi.c => kirin9xx_dw_drm_dsi.c} | 0
.../staging/hikey9xx/gpu/{dw_dsi_reg.h => kirin9xx_dw_dsi_reg.h} | 0
drivers/staging/hikey9xx/gpu/{kirin_fb.c => kirin9xx_fb.c}| 0
.../hikey9xx/gpu/{kirin_fb_panel.h => kirin9xx_fb_panel.h}| 0
drivers/staging/hikey9xx/gpu/{kirin_fbdev.c => kirin9xx_fbdev.c} | 0
drivers/staging/hikey9xx/gpu/{kirin_pwm.c => kirin9xx_pwm.c} | 0
13 files changed, 0 insertions(+), 0 deletions(-)
rename drivers/staging/hikey9xx/gpu/{kirin_dpe_reg.h => kirin9xx_dpe_reg.h}
(100%)
rename drivers/staging/hikey9xx/gpu/{kirin_drm_dpe_utils.c =>
kirin9xx_drm_dpe_utils.c} (100%)
rename drivers/staging/hikey9xx/gpu/{kirin_drm_dpe_utils.h =>
kirin9xx_drm_dpe_utils.h} (100%)
rename drivers/staging/hikey9xx/gpu/{kirin_drm_drv.c => kirin9xx_drm_drv.c}
(100%)
rename drivers/staging/hikey9xx/gpu/{kirin_drm_drv.h => kirin9xx_drm_drv.h}
(100%)
rename drivers/staging/hikey9xx/gpu/{kirin_drm_dss.c => kirin9xx_drm_dss.c}
(100%)
rename drivers/staging/hikey9xx/gpu/{kirin_drm_overlay_utils.c =>
kirin9xx_drm_overlay_utils.c} (100%)
rename drivers/staging/hikey9xx/gpu/{dw_drm_dsi.c => kirin9xx_dw_drm_dsi.c}
(100%)
rename drivers/staging/hikey9xx/gpu/{dw_dsi_reg.h => kirin9xx_dw_dsi_reg.h}
(100%)
rename drivers/staging/hikey9xx/gpu/{kirin_fb.c => kirin9xx_fb.c} (100%)
rename drivers/staging/hikey9xx/gpu/{kirin_fb_panel.h => kirin9xx_fb_panel.h}
(100%)
rename drivers/staging/hikey9xx/gpu/{kirin_fbdev.c => kirin9xx_fbdev.c} (100%)
rename drivers/staging/hikey9xx/gpu/{kirin_pwm.c => kirin9xx_pwm.c} (100%)
diff --git a/drivers/staging/hikey9xx/gpu/kirin_dpe_reg.h
b/drivers/staging/hikey9xx/gpu/kirin9xx_dpe_reg.h
similarity index 100%
rename from drivers/staging/hikey9xx/gpu/kirin_dpe_reg.h
rename to drivers/staging/hikey9xx/gpu/kirin9xx_dpe_reg.h
diff --git a/drivers/staging/hikey9xx/gpu/kirin_drm_dpe_utils.c
b/drivers/staging/hikey9xx/gpu/kirin9xx_drm_dpe_utils.c
similarity index 100%
rename from drivers/staging/hikey9xx/gpu/kirin_drm_dpe_utils.c
rename to drivers/staging/hikey9xx/gpu/kirin9xx_drm_dpe_utils.c
diff --git a/drivers/staging/hikey9xx/gpu/kirin_drm_dpe_utils.h
b/drivers/staging/hikey9xx/gpu/kirin9xx_drm_dpe_utils.h
similarity index 100%
rename from drivers/staging/hikey9xx/gpu/kirin_drm_dpe_utils.h
rename to drivers/staging/hikey9xx/gpu/kirin9xx_drm_dpe_utils.h
diff --git a/drivers/staging/hikey9xx/gpu/kirin_drm_drv.c
b/drivers/staging/hikey9xx/gpu/kirin9xx_drm_drv.c
similarity index 100%
rename from drivers/staging/hikey9xx/gpu/kirin_drm_drv.c
rename to drivers/staging/hikey9xx/gpu/kirin9xx_drm_drv.c
diff --git a/drivers/staging/hikey9xx/gpu/kirin_drm_drv.h
b/drivers/staging/hikey9xx/gpu/kirin9xx_drm_drv.h
similarity index 100%
rename from drivers/staging/hikey9xx/gpu/kirin_drm_drv.h
rename to drivers/staging/hikey9xx/gpu/kirin9xx_drm_drv.h
diff --git a/drivers/staging/hikey9xx/gpu/kirin_drm_dss.c
b/drivers/staging/hikey9xx/gpu/kirin9xx_drm_dss.c
similarity index 100%
rename from drivers/staging/hikey9xx/gpu/kirin_drm_dss.c
rename to drivers/staging/hikey9xx/gpu/kirin9xx_drm_dss.c
diff --git a/drivers/staging/hikey9xx/gpu/kirin_drm_overlay_utils.c
b/drivers/staging/hikey9xx/gpu/kirin9xx_drm_overlay_utils.c
similarity index 100%
rename from drivers/staging/hikey9xx/gpu/kirin_drm_overlay_utils.c
rename to drivers/staging/hikey9xx/gpu/kirin9xx_drm_overlay_utils.c
diff --git a/drivers/staging/hikey9xx/gpu/dw_drm_dsi.c
b/drivers/staging/hikey9xx/gpu/kirin9xx_dw_drm_dsi.c
similarity index 100%
rename from drivers/staging/hikey9xx/gpu/dw_drm_dsi.c
rename to drivers/staging/hikey9xx/gpu/kirin9xx_dw_drm_dsi.c
diff --git a/drivers/staging/hikey9xx/gpu/dw_dsi_reg.h
b/drivers/staging/hikey9xx/gpu/kirin9xx_dw_dsi_reg.h
similarity index 100%
rename from drivers/staging/hikey9xx/gpu/dw_dsi_reg.h
rename to drivers/staging/hikey9xx/gpu/kirin9xx_dw_dsi_reg.h
diff --git a/drivers/staging/hikey9xx/gpu/kirin_fb.c
b/drivers/staging/hikey9xx/gpu/kirin9xx_fb.c
similarity index 100%
rename from drivers/staging/hikey9xx/gpu/kirin_fb.c
rename to drivers/staging/hikey9xx/gpu/kirin9xx_fb.c
diff --git a/drivers/staging/hikey9xx/gpu/kirin_fb_panel.h
b/drivers/staging/hikey9xx/gpu/kirin9xx_fb_panel.h
similarity index 100%
rename from drivers/staging/h
[PATCH 21/49] staging: hikey9xx/gpu: add support for using a reserved CMA memory
Allocate the framebuffer memory via CMA, as otherwise the
drm driver may not work properly with X11.
Part of the changes here were based on a patch originally
authored by:
alik
The original version can be found at:
https://github.com/Bigcountry907/linux/commit/046e29834ef1c523c73614747377d3660eec3964
Signed-off-by: Mauro Carvalho Chehab
---
.../staging/hikey9xx/gpu/kirin9xx_drm_drv.c | 36 ++-
.../staging/hikey9xx/gpu/kirin9xx_drm_drv.h | 4 +--
.../hikey9xx/gpu/kirin9xx_drm_overlay_utils.c | 16 ++---
3 files changed, 13 insertions(+), 43 deletions(-)
diff --git a/drivers/staging/hikey9xx/gpu/kirin9xx_drm_drv.c
b/drivers/staging/hikey9xx/gpu/kirin9xx_drm_drv.c
index 49f591da1cf7..fee686760c78 100644
--- a/drivers/staging/hikey9xx/gpu/kirin9xx_drm_drv.c
+++ b/drivers/staging/hikey9xx/gpu/kirin9xx_drm_drv.c
@@ -21,6 +21,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -29,13 +30,6 @@
#include "kirin9xx_drm_drv.h"
-#ifdef CONFIG_DRM_FBDEV_EMULATION
-static bool fbdev = true;
-MODULE_PARM_DESC(fbdev, "Enable fbdev compat layer");
-module_param(fbdev, bool, 0600);
-#endif
-
-
static struct kirin_dc_ops *dc_ops;
static int kirin_drm_kms_cleanup(struct drm_device *dev)
@@ -60,22 +54,7 @@ static void kirin_fbdev_output_poll_changed(struct
drm_device *dev)
dsi_set_output_client(dev);
-#ifdef CMA_BUFFER_USED
- if (priv->fbdev) {
- DRM_INFO("hotplug_event!!\n");
- drm_fbdev_cma_hotplug_event(priv->fbdev);
- } else {
- DRM_INFO("cma_init!!\n");
- priv->fbdev = drm_fbdev_cma_init(dev, 32,
- dev->mode_config.num_crtc,
- dev->mode_config.num_connector);
- if (IS_ERR(priv->fbdev))
- priv->fbdev = NULL;
- }
-#else
- if (priv->fbdev)
- drm_fb_helper_hotplug_event(priv->fbdev);
-#endif
+ drm_fb_helper_hotplug_event(priv->fbdev);
}
static const struct drm_mode_config_funcs kirin_drm_mode_config_funcs = {
@@ -98,7 +77,7 @@ static void kirin_drm_mode_config_init(struct drm_device *dev)
static int kirin_drm_kms_init(struct drm_device *dev)
{
- struct kirin_drm_private *priv;
+ struct kirin_drm_private *priv = dev->dev_private;
int ret;
priv = devm_kzalloc(dev->dev, sizeof(*priv), GFP_KERNEL);
@@ -256,6 +235,7 @@ static int kirin_drm_bind(struct device *dev)
{
struct drm_driver *driver = &kirin_drm_driver;
struct drm_device *drm_dev;
+ struct kirin_drm_private *priv;
int ret;
drm_dev = drm_dev_alloc(driver, dev);
@@ -270,6 +250,9 @@ static int kirin_drm_bind(struct device *dev)
if (ret)
goto err_kms_cleanup;
+ drm_fbdev_generic_setup(drm_dev, 32);
+ priv = drm_dev->dev_private;
+
/* connectors should be registered after drm device register */
ret = kirin_drm_connectors_register(drm_dev);
if (ret)
@@ -340,6 +323,7 @@ static int kirin_drm_platform_probe(struct platform_device
*pdev)
struct device_node *np = dev->of_node;
struct component_match *match = NULL;
struct device_node *remote;
+ int ret;
dc_ops = (struct kirin_dc_ops *)of_device_get_match_data(dev);
if (!dc_ops) {
@@ -356,9 +340,9 @@ static int kirin_drm_platform_probe(struct platform_device
*pdev)
component_match_add(dev, &match, compare_of, remote);
+ if (ret)
+ DRM_ERROR("cma device init failed!");
return component_master_add_with_match(dev, &kirin_drm_ops, match);
-
- return 0;
}
static int kirin_drm_platform_remove(struct platform_device *pdev)
diff --git a/drivers/staging/hikey9xx/gpu/kirin9xx_drm_drv.h
b/drivers/staging/hikey9xx/gpu/kirin9xx_drm_drv.h
index b704f025d64b..261259cb8f5f 100644
--- a/drivers/staging/hikey9xx/gpu/kirin9xx_drm_drv.h
+++ b/drivers/staging/hikey9xx/gpu/kirin9xx_drm_drv.h
@@ -13,6 +13,7 @@
#include
#include
+#include
#include
#include
@@ -21,8 +22,6 @@
#define MAX_CRTC 2
-#define to_kirin_fbdev(x) container_of(x, struct kirin_fbdev, fb_helper)
-
/* display controller init/cleanup ops */
struct kirin_dc_ops {
int (*init)(struct drm_device *dev);
@@ -32,7 +31,6 @@ struct kirin_dc_ops {
};
struct kirin_drm_private {
- struct drm_fb_helper *fb_helper;
struct drm_fb_helper *fbdev;
struct drm_crtc *crtc[MAX_CRTC];
};
diff --git a/drivers/staging/hikey9xx/gpu/kirin9xx_drm_overlay_utils.c
b/drivers/staging/hikey9xx/gpu/kirin9xx_drm_overlay_utils.c
index 8be5865b615c..2b9672a3d057 100644
--- a/drivers/staging/hikey9xx/gpu/kirin9xx_drm_overlay_utils.c
+++ b/drivers/staging/hikey9xx/gpu/kirin9xx_drm_overlay_utils.c
@@ -1517,15 +1517,10 @@ void hisi_fb_pan_display(struct drm_plane *plane)
struct dss_crtc *acrtc = aplane->acrtc;
str
[PATCH 17/49] staging: hikey9xx/gpu: change the includes to reflect upstream
The includes there reflect a downstream version back on v4.4
times. change them to reflect the current upstream and to
avoid the need of using a -I flag at the Makefile.
Signed-off-by: Mauro Carvalho Chehab
---
...{kirin9xx_dpe_reg.h => kirin960_dpe_reg.h} | 3 +++
.../staging/hikey9xx/gpu/kirin970_dpe_reg.h | 3 +++
.../hikey9xx/gpu/kirin9xx_drm_dpe_utils.c | 6 +++---
.../hikey9xx/gpu/kirin9xx_drm_dpe_utils.h | 4 ++--
.../staging/hikey9xx/gpu/kirin9xx_drm_drv.c | 11 ++
.../staging/hikey9xx/gpu/kirin9xx_drm_drv.h | 10 +-
.../staging/hikey9xx/gpu/kirin9xx_drm_dss.c | 20 ++-
.../hikey9xx/gpu/kirin9xx_drm_overlay_utils.c | 15 +++---
.../hikey9xx/gpu/kirin9xx_dw_drm_dsi.c| 2 ++
drivers/staging/hikey9xx/gpu/kirin9xx_pwm.c | 12 ++-
10 files changed, 51 insertions(+), 35 deletions(-)
rename drivers/staging/hikey9xx/gpu/{kirin9xx_dpe_reg.h => kirin960_dpe_reg.h}
(99%)
diff --git a/drivers/staging/hikey9xx/gpu/kirin9xx_dpe_reg.h
b/drivers/staging/hikey9xx/gpu/kirin960_dpe_reg.h
similarity index 99%
rename from drivers/staging/hikey9xx/gpu/kirin9xx_dpe_reg.h
rename to drivers/staging/hikey9xx/gpu/kirin960_dpe_reg.h
index 282ba9b55e43..995ab8f7c9f4 100644
--- a/drivers/staging/hikey9xx/gpu/kirin9xx_dpe_reg.h
+++ b/drivers/staging/hikey9xx/gpu/kirin960_dpe_reg.h
@@ -24,6 +24,9 @@
#include
#include
+#include
+#include
+
#include
#include
diff --git a/drivers/staging/hikey9xx/gpu/kirin970_dpe_reg.h
b/drivers/staging/hikey9xx/gpu/kirin970_dpe_reg.h
index 59e43722de56..ece49b99dca7 100644
--- a/drivers/staging/hikey9xx/gpu/kirin970_dpe_reg.h
+++ b/drivers/staging/hikey9xx/gpu/kirin970_dpe_reg.h
@@ -24,6 +24,9 @@
#include
#include
+#include
+#include
+
#include
#include
diff --git a/drivers/staging/hikey9xx/gpu/kirin9xx_drm_dpe_utils.c
b/drivers/staging/hikey9xx/gpu/kirin9xx_drm_dpe_utils.c
index fe8372838bb3..a15c335da026 100644
--- a/drivers/staging/hikey9xx/gpu/kirin9xx_drm_dpe_utils.c
+++ b/drivers/staging/hikey9xx/gpu/kirin9xx_drm_dpe_utils.c
@@ -10,10 +10,10 @@
* GNU General Public License for more details.
*
*/
-#include
+#include
+#include
-#include "drm_mipi_dsi.h"
-#include "kirin_drm_dpe_utils.h"
+#include "kirin9xx_drm_dpe_utils.h"
int g_debug_set_reg_val = 0;
diff --git a/drivers/staging/hikey9xx/gpu/kirin9xx_drm_dpe_utils.h
b/drivers/staging/hikey9xx/gpu/kirin9xx_drm_dpe_utils.h
index 89aaf6691f1d..0c5681d0a5ac 100644
--- a/drivers/staging/hikey9xx/gpu/kirin9xx_drm_dpe_utils.h
+++ b/drivers/staging/hikey9xx/gpu/kirin9xx_drm_dpe_utils.h
@@ -17,9 +17,9 @@
#if defined (CONFIG_DRM_HISI_KIRIN970)
#include "kirin970_dpe_reg.h"
#else
-#include "kirin_dpe_reg.h"
+#include "kirin960_dpe_reg.h"
#endif
-#include "kirin_drm_drv.h"
+#include "kirin9xx_drm_drv.h"
void set_reg(char __iomem *addr, uint32_t val, uint8_t bw, uint8_t bs);
uint32_t set_bits32(uint32_t old_val, uint32_t val, uint8_t bw, uint8_t bs);
diff --git a/drivers/staging/hikey9xx/gpu/kirin9xx_drm_drv.c
b/drivers/staging/hikey9xx/gpu/kirin9xx_drm_drv.c
index f5b05b26bc18..616fa7ca9c77 100644
--- a/drivers/staging/hikey9xx/gpu/kirin9xx_drm_drv.c
+++ b/drivers/staging/hikey9xx/gpu/kirin9xx_drm_drv.c
@@ -18,13 +18,16 @@
#include
#include
-#include
-#include
-#include
#include
#include
+#include
+#include
+#include
+#include
+#include
+#include
-#include "kirin_drm_drv.h"
+#include "kirin9xx_drm_drv.h"
#ifdef CONFIG_DRM_FBDEV_EMULATION
static bool fbdev = true;
diff --git a/drivers/staging/hikey9xx/gpu/kirin9xx_drm_drv.h
b/drivers/staging/hikey9xx/gpu/kirin9xx_drm_drv.h
index 18a7478fee10..15ef96840e9f 100644
--- a/drivers/staging/hikey9xx/gpu/kirin9xx_drm_drv.h
+++ b/drivers/staging/hikey9xx/gpu/kirin9xx_drm_drv.h
@@ -11,18 +11,18 @@
#ifndef __KIRIN_DRM_DRV_H__
#define __KIRIN_DRM_DRV_H__
-#include
+#include
+#include
+#include
+#include
+
#include
#include
#include
#include
-#include "drm_crtc.h"
-#include "drm_fb_helper.h"
-
#define MAX_CRTC 2
-//#define CMA_BUFFER_USED
#define to_kirin_fbdev(x) container_of(x, struct kirin_fbdev, fb_helper)
/* display controller init/cleanup ops */
diff --git a/drivers/staging/hikey9xx/gpu/kirin9xx_drm_dss.c
b/drivers/staging/hikey9xx/gpu/kirin9xx_drm_dss.c
index b4c1bb8288de..fd0ccbaebd3f 100644
--- a/drivers/staging/hikey9xx/gpu/kirin9xx_drm_dss.c
+++ b/drivers/staging/hikey9xx/gpu/kirin9xx_drm_dss.c
@@ -25,22 +25,24 @@
#include
#include
-#include
-#include
-#include
#include
#include
-#include
-#include
+#include
+#include
+#include
#include
+#include
+#include
+#include
+#include
+#include
-#include "kirin_drm_drv.h"
-
-#include "kirin_drm_dpe_utils.h"
+#include "kirin9xx_drm_drv.h"
+#include "kirin9xx_drm_dpe_utils.h"
#if defined (CONFIG_DRM_HISI_KIRIN970)
#include "kirin970_dpe_reg.h"
#else
-#include "kirin_dpe_reg.h"
+#include "kirin960_dpe_reg.h"
#endif
//#define DSS_POWER_UP_O
[PATCH 37/49] staging: hikey9xx/gpu: don't use iommu code
While this driver apparently supports both IOMMU and no-IOMMU
access, it always enable the IOMMU via some code, at the
downstream version.
Apparently, the downstream iommu is there just to get the
physical address of the logical IOMMU address. Based on
the downstream code, it sounds that the IOMMU would be an
specific one for the GPU.
Anyway, right now, the driver is set to not use the IOMMU
at all. So, let's comment out the code which allocates
IOMMU pages, and the code that would try to use it to
setup a register, as, without the IOMMU, this would cause
an OOPS.
Signed-off-by: Mauro Carvalho Chehab
---
drivers/staging/hikey9xx/gpu/kirin9xx_drm_dss.c | 12 ++--
.../hikey9xx/gpu/kirin9xx_drm_overlay_utils.c| 10 ++
2 files changed, 20 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/hikey9xx/gpu/kirin9xx_drm_dss.c
b/drivers/staging/hikey9xx/gpu/kirin9xx_drm_dss.c
index e3bb0a32dddf..546da775f2fb 100644
--- a/drivers/staging/hikey9xx/gpu/kirin9xx_drm_dss.c
+++ b/drivers/staging/hikey9xx/gpu/kirin9xx_drm_dss.c
@@ -769,6 +769,14 @@ static int dss_plane_init(struct drm_device *dev, struct
dss_plane *aplane,
static int dss_enable_iommu(struct platform_device *pdev, struct dss_hw_ctx
*ctx)
{
+#if 0
+/*
+ * FIXME:
+ *
+ * Right now, the IOMMU support is actually disabled. See the caller of
+ * hisi_dss_smmu_config(). Yet, if we end enabling it, this should be
+ * ported to use io-pgtable directly.
+ */
struct device *dev = NULL;
dev = &pdev->dev;
@@ -781,7 +789,7 @@ static int dss_enable_iommu(struct platform_device *pdev,
struct dss_hw_ctx *ctx
}
iommu_attach_device(ctx->mmu_domain, dev);
-
+#endif
return 0;
}
@@ -934,7 +942,7 @@ static int dss_dts_parse(struct platform_device *pdev,
struct dss_hw_ctx *ctx)
DSS_MAX_PXL0_CLK_144M,
(uint64_t)clk_get_rate(ctx->dss_pxl0_clk));
}
- /* regulator enable */
+ /* enable IOMMU */
dss_enable_iommu(pdev, ctx);
return 0;
diff --git a/drivers/staging/hikey9xx/gpu/kirin9xx_drm_overlay_utils.c
b/drivers/staging/hikey9xx/gpu/kirin9xx_drm_overlay_utils.c
index 9113937478f5..6b6774b8d903 100644
--- a/drivers/staging/hikey9xx/gpu/kirin9xx_drm_overlay_utils.c
+++ b/drivers/staging/hikey9xx/gpu/kirin9xx_drm_overlay_utils.c
@@ -1333,8 +1333,17 @@ static void hisi_dss_mif_on(struct dss_hw_ctx *ctx)
set_reg(dss_base + MIF_CH11_OFFSET + MIF_CTRL0, 0x1, 1, 0);
}
+
void hisi_dss_smmu_on(struct dss_hw_ctx *ctx)
{
+#if 0
+/*
+ * FIXME:
+ *
+ * Right now, the IOMMU support is actually disabled. See the caller of
+ * hisi_dss_smmu_config(). Yet, if we end enabling it, this should be
+ * ported to use io-pgtable directly.
+ */
void __iomem *smmu_base;
struct iommu_domain_data *domain_data = NULL;
u32 phy_pgd_base = 0;
@@ -1374,6 +1383,7 @@ void hisi_dss_smmu_on(struct dss_hw_ctx *ctx)
phy_pgd_base = (uint32_t)(domain_data->phy_pgd_base);
DRM_DEBUG("fama_phy_pgd_base = %llu, phy_pgd_base =0x%x \n",
fama_phy_pgd_base, phy_pgd_base);
set_reg(smmu_base + SMMU_CB_TTBR0, phy_pgd_base, 32, 0);
+#endif
}
void hisifb_dss_on(struct dss_hw_ctx *ctx)
--
2.26.2
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 31/49] staging: hikey9xx/gpu: fix driver name
Signed-off-by: Mauro Carvalho Chehab
---
drivers/staging/hikey9xx/gpu/kirin9xx_dw_drm_dsi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/hikey9xx/gpu/kirin9xx_dw_drm_dsi.c
b/drivers/staging/hikey9xx/gpu/kirin9xx_dw_drm_dsi.c
index 09d035038c1a..99be8dfe05e6 100644
--- a/drivers/staging/hikey9xx/gpu/kirin9xx_dw_drm_dsi.c
+++ b/drivers/staging/hikey9xx/gpu/kirin9xx_dw_drm_dsi.c
@@ -2074,7 +2074,7 @@ static struct platform_driver dsi_driver = {
.probe = dsi_probe,
.remove = dsi_remove,
.driver = {
- .name = "dw-dsi",
+ .name = "kirin9xx-dw-dsi",
.of_match_table = dsi_of_match,
},
};
--
2.26.2
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 08/49] staging: hikey9xx/gpu: Support MIPI DSI 3 lanes for hikey970.
From: Xiubin Zhang
Modfiy mipi dsi lanes to improve HDMI compatibility.
Signed-off-by: Xiubin Zhang
Signed-off-by: Liuyao An
Signed-off-by: Mauro Carvalho Chehab
---
drivers/staging/hikey9xx/gpu/dw_drm_dsi.c | 24 ---
drivers/staging/hikey9xx/gpu/hdmi/adv7535.c | 4
.../staging/hikey9xx/gpu/kirin970_dpe_reg.h | 1 +
3 files changed, 16 insertions(+), 13 deletions(-)
diff --git a/drivers/staging/hikey9xx/gpu/dw_drm_dsi.c
b/drivers/staging/hikey9xx/gpu/dw_drm_dsi.c
index e87363ab7373..2ba94fa15d0f 100644
--- a/drivers/staging/hikey9xx/gpu/dw_drm_dsi.c
+++ b/drivers/staging/hikey9xx/gpu/dw_drm_dsi.c
@@ -359,7 +359,10 @@ static void get_dsi_dphy_ctrl(struct dw_dsi *dsi,
if (bpp < 0)
return;
- dsi->client[id].lanes = 4;
+ if (mode->clock > 8)
+ dsi->client[id].lanes = 4;
+ else
+ dsi->client[id].lanes = 3;
if (dsi->client[id].phy_clock)
dphy_req_kHz = dsi->client[id].phy_clock;
@@ -935,8 +938,7 @@ static void mipi_config_dphy_spec1v2_parameter(struct
dw_dsi *dsi, char __iomem
u32 lanes;
lanes = dsi->client[dsi->cur_client].lanes - 1;
-
- for (i = 0; i <= (lanes+1); i++) {
+ for (i = 0; i <= (lanes + 1); i++) {
//Lane Transmission Property
addr = MIPIDSI_PHY_TST_LANE_TRANSMISSION_PROPERTY + (i << 5);
dsi_phy_tst_set(mipi_dsi_base, addr, 0x43);
@@ -960,10 +962,12 @@ static void mipi_config_dphy_spec1v2_parameter(struct
dw_dsi *dsi, char __iomem
//clock lane timing ctrl - t_hs_trial
dsi_phy_tst_set(mipi_dsi_base, MIPIDSI_PHY_TST_CLK_TRAIL,
DSS_REDUCE(dsi->phy.clk_t_hs_trial));
- for (i = 0; i <= (lanes + 1); i++) {
- if (i == 2) {
+ for (i = 0; i <= 4; i++) {
+ if (lanes == 2 && i == 1) /*init mipi dsi 3 lanes shoud skip
lane3*/
+ i++;
+
+ if (i == 2) /* skip clock lane*/
i++; //addr: lane0:0x60; lane1:0x80; lane2:0xC0;
lane3:0xE0
- }
//data lane pre_delay
addr = MIPIDSI_PHY_TST_DATA_PRE_DELAY + (i << 5);
@@ -1019,6 +1023,9 @@ static void dsi_mipi_init(struct dw_dsi *dsi, char
__iomem *mipi_dsi_base)
dss_rect_t rect;
u32 cmp_stopstate_val = 0;
u32 lanes;
+#if !defined (CONFIG_HISI_FB_970)
+ int i = 0;
+#endif
WARN_ON(!dsi);
WARN_ON(!mipi_dsi_base);
@@ -1132,7 +1139,7 @@ static void dsi_mipi_init(struct dw_dsi *dsi, char
__iomem *mipi_dsi_base)
/* clock lane timing ctrl - t_hs_trial*/
dsi_phy_tst_set(mipi_dsi_base, 0x25, dsi->phy.clk_t_hs_trial);
- for (int i = 0; i <= lanes; i++) {
+ for (i = 0; i <= lanes; i++) {
/* data lane pre_delay*/
tmp = 0x30 + (i << 4);
dsi_phy_tst_set(mipi_dsi_base, tmp,
DSS_REDUCE(dsi->phy.data_pre_delay));
@@ -1361,10 +1368,9 @@ static int mipi_dsi_on_sub1(struct dw_dsi *dsi, char
__iomem *mipi_dsi_base)
static int mipi_dsi_on_sub2(struct dw_dsi *dsi, char __iomem *mipi_dsi_base)
{
+ u64 pctrl_dphytx_stopcnt = 0;
WARN_ON(!mipi_dsi_base);
- u64 pctrl_dphytx_stopcnt;
- pctrl_dphytx_stopcnt = 0;
/* switch to video mode */
set_reg(mipi_dsi_base + MIPIDSI_MODE_CFG_OFFSET, 0x0, 1, 0);
diff --git a/drivers/staging/hikey9xx/gpu/hdmi/adv7535.c
b/drivers/staging/hikey9xx/gpu/hdmi/adv7535.c
index 0343b2cd4c45..a21a8f8b917e 100644
--- a/drivers/staging/hikey9xx/gpu/hdmi/adv7535.c
+++ b/drivers/staging/hikey9xx/gpu/hdmi/adv7535.c
@@ -939,14 +939,10 @@ static void adv7511_mode_set(struct adv7511 *adv7511,
struct mipi_dsi_device *dsi = adv7511->dsi;
int lanes, ret;
-#if defined(CONFIG_HISI_FB_970)
- lanes = 4;
-#else
if (adj_mode->clock > 8)
lanes = 4;
else
lanes = 3;
-#endif
if (lanes != dsi->lanes) {
mipi_dsi_detach(dsi);
diff --git a/drivers/staging/hikey9xx/gpu/kirin970_dpe_reg.h
b/drivers/staging/hikey9xx/gpu/kirin970_dpe_reg.h
index 867266073bc0..5c2ddcf01b26 100644
--- a/drivers/staging/hikey9xx/gpu/kirin970_dpe_reg.h
+++ b/drivers/staging/hikey9xx/gpu/kirin970_dpe_reg.h
@@ -449,6 +449,7 @@ enum dss_chn_module {
MODULE_SCL_LUT,
MODULE_ARSR2P,
MODULE_ARSR2P_LUT,
+ MODULE_POST_CLIP_ES,
MODULE_POST_CLIP,
MODULE_PCSC,
MODULE_CSC,
--
2.26.2
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 23/49] staging: hikey9xx/gpu: Change the logic which sets the burst mode
The logic there is more complex than it needs. It also places
the device with a wrong setting if the flags are missed.
This currently happens on Kirin970 for HDMI, as there's a bug
at the part of the driver which selects between PANEL or
OUTPUT at encoder init code.
Signed-off-by: Mauro Carvalho Chehab
---
.../hikey9xx/gpu/kirin9xx_dw_drm_dsi.c| 34 +++
1 file changed, 20 insertions(+), 14 deletions(-)
diff --git a/drivers/staging/hikey9xx/gpu/kirin9xx_dw_drm_dsi.c
b/drivers/staging/hikey9xx/gpu/kirin9xx_dw_drm_dsi.c
index e904943d9f9e..ffc8b8e61062 100644
--- a/drivers/staging/hikey9xx/gpu/kirin9xx_dw_drm_dsi.c
+++ b/drivers/staging/hikey9xx/gpu/kirin9xx_dw_drm_dsi.c
@@ -902,26 +902,28 @@ static void dw_dsi_set_mode(struct dw_dsi *dsi, enum
dsi_work_mode mode)
writel(POWERUP, base + PWR_UP);
}
-static void dsi_set_burst_mode(void __iomem *base, unsigned long flags)
+static void dsi_set_burst_mode(void __iomem *base, unsigned long burst_flags)
{
+ unsigned long flags;
u32 val;
- u32 mode_mask = MIPI_DSI_MODE_VIDEO | MIPI_DSI_MODE_VIDEO_BURST |
- MIPI_DSI_MODE_VIDEO_SYNC_PULSE;
- u32 non_burst_sync_pulse = MIPI_DSI_MODE_VIDEO |
- MIPI_DSI_MODE_VIDEO_SYNC_PULSE;
- u32 non_burst_sync_event = MIPI_DSI_MODE_VIDEO;
- /*
-* choose video mode type
-*/
- if ((flags & mode_mask) == non_burst_sync_pulse)
+ flags = burst_flags;
+ flags &= MIPI_DSI_MODE_VIDEO |
+MIPI_DSI_MODE_VIDEO_BURST |
+MIPI_DSI_MODE_VIDEO_SYNC_PULSE;
+
+ if (!(flags & MIPI_DSI_MODE_VIDEO)) {
+ DRM_WARN("MIPI_DSI_MODE_VIDEO was not set! Using
DSI_NON_BURST_SYNC_PULSES");
val = DSI_NON_BURST_SYNC_PULSES;
- else if ((flags & mode_mask) == non_burst_sync_event)
- val = DSI_NON_BURST_SYNC_EVENTS;
- else
+ } else if (flags & MIPI_DSI_MODE_VIDEO_BURST) {
val = DSI_BURST_SYNC_PULSES_1;
+ } else if (flags & MIPI_DSI_MODE_VIDEO_SYNC_PULSE) {
+ val = DSI_NON_BURST_SYNC_PULSES;
+ } else {
+ val = DSI_NON_BURST_SYNC_EVENTS;
+ }
- DRM_INFO("burst_mode = 0x%x (DSI_NON_BURST_SYNC_PULSES => 0)", val);
+ DRM_INFO("burst_mode = 0x%x (flags: 0x%04lx)", val, burst_flags);
set_reg(base + MIPIDSI_VID_MODE_CFG_OFFSET, val, 2, 0);
}
@@ -1047,6 +1049,10 @@ static void dsi_mipi_init(struct dw_dsi *dsi, char
__iomem *mipi_dsi_base)
WARN_ON(!mipi_dsi_base);
id = dsi->cur_client;
+
+ DRM_INFO("dsi_mipi_init, id=%d\n", id);
+
+
mipi = &dsi->mipi;
if (mipi->max_tx_esc_clk == 0) {
--
2.26.2
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 33/49] staging: hikey9xx/gpu: re-work the mode validation code
Do some cleanups at the mode validation code. Right now, there
is a known issue with this driver which makes it to set up
some invalid modes, depending on the display.
We don't know yet what the issue is, so, instead, let's add
a table with the modes which are known to work.
Signed-off-by: Mauro Carvalho Chehab
---
.../staging/hikey9xx/gpu/kirin9xx_drm_dss.c | 274 +++---
.../hikey9xx/gpu/kirin9xx_dw_drm_dsi.c| 34 +++
2 files changed, 211 insertions(+), 97 deletions(-)
diff --git a/drivers/staging/hikey9xx/gpu/kirin9xx_drm_dss.c
b/drivers/staging/hikey9xx/gpu/kirin9xx_drm_dss.c
index 26212c130b79..0844bf372ca8 100644
--- a/drivers/staging/hikey9xx/gpu/kirin9xx_drm_dss.c
+++ b/drivers/staging/hikey9xx/gpu/kirin9xx_drm_dss.c
@@ -103,8 +103,9 @@ u32 dss_get_format(u32 pixel_format)
}
/***
-**
-*/
+ **
+ */
+
int hdmi_ceil(uint64_t a, uint64_t b)
{
if (b == 0)
@@ -117,99 +118,108 @@ int hdmi_ceil(uint64_t a, uint64_t b)
}
}
-int hdmi_pxl_ppll7_init(struct dss_hw_ctx *ctx, uint64_t pixel_clock)
+int hdmi_pxl_ppll7_init(struct dss_hw_ctx *ctx, u64 pixel_clock)
{
- uint64_t refdiv, fbdiv, frac, postdiv1, postdiv2;
- uint64_t vco_min_freq_output = KIRIN970_VCO_MIN_FREQ_OUPUT;
- uint64_t sys_clock_fref = KIRIN970_SYS_19M2;
- uint64_t ppll7_freq_divider;
- uint64_t vco_freq_output;
- uint64_t frac_range = 0x100;/*2^24*/
- uint64_t pixel_clock_ori;
- uint64_t pixel_clock_cur;
- uint32_t ppll7ctrl0;
- uint32_t ppll7ctrl1;
- uint32_t ppll7ctrl0_val;
- uint32_t ppll7ctrl1_val;
- int i, ret;
+ u64 vco_min_freq_output = KIRIN970_VCO_MIN_FREQ_OUPUT;
+ u64 refdiv, fbdiv, frac, postdiv1 = 0, postdiv2 = 0;
+ u64 dss_pxl0_clk = 7 * 14400UL;
+ u64 sys_clock_fref = KIRIN970_SYS_19M2;
+ u64 ppll7_freq_divider;
+ u64 vco_freq_output;
+ u64 frac_range = 0x100;/*2^24*/
+ u64 pixel_clock_ori;
+ u64 pixel_clock_cur;
+ u32 ppll7ctrl0;
+ u32 ppll7ctrl1;
+ u32 ppll7ctrl0_val;
+ u32 ppll7ctrl1_val;
int ceil_temp;
- int freq_divider_list[22] = {1, 2, 3, 4, 5, 6, 7, 8, 9, 10,
- 12, 14, 15, 16, 20, 21, 24,
- 25, 30, 36, 42, 49};
-
- int postdiv1_list[22] = {1, 2, 3, 4, 5, 6, 7, 4, 3, 5,
- 4, 7, 5, 4, 5, 7, 6, 5, 6, 6,
- 7, 7};
-
- int postdiv2_list[22] = {1, 1, 1, 1, 1, 1, 1, 2, 3, 2,
+ int i, ret;
+ const int freq_divider_list[22] = {
+ 1, 2, 3, 4, 5, 6, 7, 8,
+ 9, 10, 12, 14, 15, 16, 20, 21,
+ 24, 25, 30, 36, 42, 49
+ };
+ const int postdiv1_list[22] = {
+ 1, 2, 3, 4, 5, 6, 7, 4, 3, 5,
+ 4, 7, 5, 4, 5, 7, 6, 5, 6, 6,
+ 7, 7
+ };
+ const int postdiv2_list[22] = {
+ 1, 1, 1, 1, 1, 1, 1, 2, 3, 2,
3, 2, 3, 4, 4, 3, 4, 5, 5, 6,
- 6, 7};
- ret = 0;
- postdiv1 = 0;
- postdiv2 = 0;
- if (pixel_clock == 0)
- return -EINVAL;
+ 6, 7
+ };
- if (ctx == NULL) {
- DRM_ERROR("NULL Pointer\n");
+ if (!pixel_clock) {
+ DRM_ERROR("Pixel clock can't be zero!\n");
return -EINVAL;
}
pixel_clock_ori = pixel_clock;
+ pixel_clock_cur = pixel_clock_ori;
- if (pixel_clock_ori <= 25500)
- pixel_clock_cur = pixel_clock * 7;
- else if (pixel_clock_ori <= 41500)
- pixel_clock_cur = pixel_clock * 5;
- else if (pixel_clock_ori <= 59400)
- pixel_clock_cur = pixel_clock * 3;
- else {
- DRM_ERROR("Clock don't support!!\n");
+ if (pixel_clock_ori <= 25500) {
+ pixel_clock_cur *= 7;
+ dss_pxl0_clk /= 7;
+ } else if (pixel_clock_ori <= 41500) {
+ pixel_clock_cur *= 5;
+ dss_pxl0_clk /= 5;
+ } else if (pixel_clock_ori <= 59400) {
+ pixel_clock_cur *= 3;
+ dss_pxl0_clk /= 3;
+ } else {
+ DRM_ERROR("Clock not supported!\n");
return -EINVAL;
}
pixel_clock_cur = pixel_clock_cur / 1000;
ceil_temp = hdmi_ceil(vco_min_freq_output, pixel_clock_cur);
- if (ceil_temp < 0)
+ if (ceil_temp < 0) {
+ DRM_ERROR("pixel_clock_cur can't be zero!\n");
return -EINVAL;
+ }
- ppll7_freq_divider = (uint64_t)ceil_temp;
+ ppll7_freq_divider = (u64)ceil_temp;
- for (i = 0; i < 22; i++) {
+ for (i = 0; i < ARRAY_SIZE(freq_divider_list); i++) {
if (freq_divider_list[i] >= ppll7_freq_divider) {
ppll7_freq_divide
[PATCH 28/49] staging: hikey9xx/gpu: remove an uneeded hack
At least on current upstream Kernels, forcing an event parse during init time isn't needed anymore. Signed-off-by: Mauro Carvalho Chehab --- drivers/staging/hikey9xx/gpu/kirin9xx_drm_drv.c | 5 - 1 file changed, 5 deletions(-) diff --git a/drivers/staging/hikey9xx/gpu/kirin9xx_drm_drv.c b/drivers/staging/hikey9xx/gpu/kirin9xx_drm_drv.c index 44f7c15f386a..3d1b5f738a7f 100644 --- a/drivers/staging/hikey9xx/gpu/kirin9xx_drm_drv.c +++ b/drivers/staging/hikey9xx/gpu/kirin9xx_drm_drv.c @@ -122,11 +122,6 @@ static int kirin_drm_kms_init(struct drm_device *dev) /* init kms poll for handling hpd */ drm_kms_helper_poll_init(dev); -#if 1 - /* force detection after connectors init */ - (void)drm_helper_hpd_irq_event(dev); -#endif - return 0; err_unbind_all: -- 2.26.2 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 09/49] staging: hikey9xx/gpu: Solve SR test reset problem for hikey970.
From: Xiubin Zhang
Add HDMI/DSS power on&off in the SR flow.
Signed-off-by: Xiubin Zhang
Signed-off-by: Mauro Carvalho Chehab
---
drivers/staging/hikey9xx/gpu/Makefile | 1 -
drivers/staging/hikey9xx/gpu/dw_drm_dsi.c | 10 +--
.../staging/hikey9xx/gpu/kirin970_dpe_reg.h | 9 ++-
drivers/staging/hikey9xx/gpu/kirin_dpe_reg.h | 4 +-
.../hikey9xx/gpu/kirin_drm_dpe_utils.c| 80 ++-
.../hikey9xx/gpu/kirin_drm_dpe_utils.h| 4 +
drivers/staging/hikey9xx/gpu/kirin_drm_dss.c | 34 +++-
.../hikey9xx/gpu/kirin_drm_overlay_utils.c| 3 -
8 files changed, 85 insertions(+), 60 deletions(-)
diff --git a/drivers/staging/hikey9xx/gpu/Makefile
b/drivers/staging/hikey9xx/gpu/Makefile
index 5d7cf738a7d6..a5e008365a57 100644
--- a/drivers/staging/hikey9xx/gpu/Makefile
+++ b/drivers/staging/hikey9xx/gpu/Makefile
@@ -1,6 +1,5 @@
EXTRA_CFLAGS += \
-Iinclude/drm
-
kirin-drm-y := kirin_fbdev.o \
kirin_fb.o \
kirin_drm_drv.o \
diff --git a/drivers/staging/hikey9xx/gpu/dw_drm_dsi.c
b/drivers/staging/hikey9xx/gpu/dw_drm_dsi.c
index 2ba94fa15d0f..4fef154cd701 100644
--- a/drivers/staging/hikey9xx/gpu/dw_drm_dsi.c
+++ b/drivers/staging/hikey9xx/gpu/dw_drm_dsi.c
@@ -2046,11 +2046,8 @@ static int dsi_suspend(struct platform_device *pdev,
pm_message_t state)
struct dsi_data *ddata = dev_get_drvdata(dev);
struct dw_dsi *dsi = &ddata->dsi;
- DRM_INFO("+. pdev->name is %s, pm_message is %d \n", pdev->name,
state.event);
-
dsi_encoder_disable(&dsi->encoder);
-
- DRM_INFO("-. \n");
+ drm_bridge_post_disable(dsi->encoder.bridge);
return 0;
}
@@ -2061,12 +2058,9 @@ static int dsi_resume(struct platform_device *pdev)
struct dsi_data *ddata = dev_get_drvdata(dev);
struct dw_dsi *dsi = &ddata->dsi;
- DRM_INFO("+. pdev->name is %s \n", pdev->name);
-
+ drm_bridge_pre_enable(dsi->encoder.bridge);
dsi_encoder_enable(&dsi->encoder);
- DRM_INFO("-. \n");
-
return 0;
}
diff --git a/drivers/staging/hikey9xx/gpu/kirin970_dpe_reg.h
b/drivers/staging/hikey9xx/gpu/kirin970_dpe_reg.h
index 5c2ddcf01b26..59e43722de56 100644
--- a/drivers/staging/hikey9xx/gpu/kirin970_dpe_reg.h
+++ b/drivers/staging/hikey9xx/gpu/kirin970_dpe_reg.h
@@ -43,6 +43,7 @@
/* vcc name */
#define REGULATOR_PDP_NAME "regulator_dsssubsys"
#define REGULATOR_MMBUF"regulator_mmbuf"
+#define REGULATOR_MEDIA_NAME "regulator_media_subsys"
/***
**
@@ -220,8 +221,8 @@ typedef struct drm_dss_layer {
/*dss clk power off */
#define DEFAULT_DSS_CORE_CLK_RATE_POWER_OFF(27700UL)
-#define DEFAULT_DSS_PXL0_CLK_RATE_POWER_OFF(27700UL)
-#define DEFAULT_DSS_MMBUF_CLK_RATE_POWER_OFF (23800UL)
+#define DEFAULT_DSS_PXL0_CLK_RATE_POWER_OFF(23800UL)
+#define DEFAULT_DSS_MMBUF_CLK_RATE_POWER_OFF (20800UL)
#define DEFAULT_DSS_PXL1_CLK_RATE_POWER_OFF(23800UL)
#define DEFAULT_PCLK_DSS_RATE (11400UL)
@@ -4085,8 +4086,8 @@ struct dss_hw_ctx {
struct dss_clk_rate *dss_clk;
struct regulator *dpe_regulator;
- struct regulator_bulk_data *mmbuf_regulator;
- struct regulator_bulk_data *media_subsys_regulator;
+ struct regulator *mmbuf_regulator;
+ struct regulator *mediacrg_regulator;
bool power_on;
int irq;
diff --git a/drivers/staging/hikey9xx/gpu/kirin_dpe_reg.h
b/drivers/staging/hikey9xx/gpu/kirin_dpe_reg.h
index cdf2f1d22e5e..282ba9b55e43 100644
--- a/drivers/staging/hikey9xx/gpu/kirin_dpe_reg.h
+++ b/drivers/staging/hikey9xx/gpu/kirin_dpe_reg.h
@@ -3073,8 +3073,8 @@ struct dss_hw_ctx {
struct dss_clk_rate *dss_clk;
struct regulator *dpe_regulator;
- struct regulator_bulk_data *mmbuf_regulator;
- struct regulator_bulk_data *media_subsys_regulator;
+ struct regulator *mmbuf_regulator;
+ struct regulator *mediacrg_regulator;
bool power_on;
int irq;
diff --git a/drivers/staging/hikey9xx/gpu/kirin_drm_dpe_utils.c
b/drivers/staging/hikey9xx/gpu/kirin_drm_dpe_utils.c
index d891ee17f48d..887c5d609ab6 100644
--- a/drivers/staging/hikey9xx/gpu/kirin_drm_dpe_utils.c
+++ b/drivers/staging/hikey9xx/gpu/kirin_drm_dpe_utils.c
@@ -1009,7 +1009,7 @@ int dpe_regulator_enable(struct dss_hw_ctx *ctx)
return -EINVAL;
}
- ret = regulator_enable(ctx->dpe_regulator);
+ //ret = regulator_enable(ctx->dpe_regulator);
if (ret) {
DRM_ERROR(" dpe regulator_enable failed, error=%d!\n", ret);
return -EINVAL;
@@ -1024,31 +1024,57 @@ int dpe_regulator_disable(struct dss_hw_ctx *ctx)
{
int ret = 0;
- DRM_INFO("+. \n");
if (NULL == ctx) {
DRM_ERROR("NULL ptr.\n");
return -EINVAL;
}
#if def
[PATCH 38/49] staging: hikey9xx/gpu: add kirin9xx driver to the building system
Now that everything is in place, add the driver to the building system. Signed-off-by: Mauro Carvalho Chehab --- drivers/staging/hikey9xx/Kconfig | 3 ++ drivers/staging/hikey9xx/Makefile | 1 + drivers/staging/hikey9xx/gpu/Kconfig | 52 ++- drivers/staging/hikey9xx/gpu/Makefile | 21 --- 4 files changed, 22 insertions(+), 55 deletions(-) diff --git a/drivers/staging/hikey9xx/Kconfig b/drivers/staging/hikey9xx/Kconfig index 0e97b5b9a56a..b2ce886e1c4e 100644 --- a/drivers/staging/hikey9xx/Kconfig +++ b/drivers/staging/hikey9xx/Kconfig @@ -36,3 +36,6 @@ config REGULATOR_HI6421V600 This driver provides support for the voltage regulators on HiSilicon Hi6421v600 PMU / Codec IC. This is used on Kirin 3670 boards, like HiKey 970. + +# DRM/KMS driver +source "drivers/staging/hikey9xx/gpu/Kconfig" diff --git a/drivers/staging/hikey9xx/Makefile b/drivers/staging/hikey9xx/Makefile index 9371dcc3d35b..1a848d398ab6 100644 --- a/drivers/staging/hikey9xx/Makefile +++ b/drivers/staging/hikey9xx/Makefile @@ -3,3 +3,4 @@ obj-$(CONFIG_SPMI_HISI3670)+= hisi-spmi-controller.o obj-$(CONFIG_MFD_HI6421_SPMI) += hi6421-spmi-pmic.o obj-$(CONFIG_REGULATOR_HI6421V600) += hi6421v600-regulator.o +obj-y += gpu/ diff --git a/drivers/staging/hikey9xx/gpu/Kconfig b/drivers/staging/hikey9xx/gpu/Kconfig index 5533ee624f29..957da13bcf81 100644 --- a/drivers/staging/hikey9xx/gpu/Kconfig +++ b/drivers/staging/hikey9xx/gpu/Kconfig @@ -1,52 +1,22 @@ -config DRM_HISI_KIRIN - tristate "DRM Support for Hisilicon Kirin series SoCs Platform" +config DRM_HISI_KIRIN9XX + tristate "DRM Support for Hisilicon Kirin9xx series SoCs Platform" depends on DRM && OF && ARM64 select DRM_KMS_HELPER select DRM_GEM_CMA_HELPER select DRM_KMS_CMA_HELPER - select HISI_KIRIN_DW_DSI - help - Choose this option if you have a hisilicon Kirin chipsets(hi6220). - If M is selected the module will be called kirin-drm. - -config DRM_KIRIN_960 - tristate "DRM Support for Hisilicon Kirin960 series SoCs Platform" - depends on DRM && OF && ARM64 - select DRM_KMS_HELPER - select DRM_GEM_CMA_HELPER - select DRM_KMS_CMA_HELPER - select HISI_KIRIN_DW_DSI - help - Choose this option if you have a hisilicon Kirin chipsets(kirin960). - If M is selected the module will be called kirin-drm. - -config HISI_KIRIN_DW_DSI - tristate "HiSilicon Kirin specific extensions for Synopsys DW MIPI DSI" - depends on DRM_HISI_KIRIN || DRM_KIRIN_960 select DRM_MIPI_DSI - select DRM_PANEL help -This selects support for HiSilicon Kirin SoC specific extensions for -the Synopsys DesignWare DSI driver. If you want to enable MIPI DSI on -hi6220 based SoC, you should selet this option. + Choose this option if you have a HiSilicon Kirin960 or Kirin970. + If M is selected the module will be called kirin9xx-drm. -config DRM_PANEL_HIKEY960_NTE300NTS - tristate "Hikey960 NTE300NTS video mode panel" - depends on OF - depends on DRM_MIPI_DSI - help - Say Y here if you want to enable LCD panel driver for Hikey960 boadr. - Current support panel: NTE300NTS(1920X1200) - -config HISI_FB_970 - tristate "DRM Support for Hisilicon Kirin970 series SoCs Platform" - depends on DRM && OF && ARM64 +config DRM_HISI_KIRIN970 + bool "Enable support for Hisilicon Kirin970" depends on DRM_MIPI_DSI + depends on DRM_HISI_KIRIN9XX help Choose this option if you have a hisilicon Kirin chipsets(kirin970). - If M is selected the module will be called kirin-drm. -config HDMI_ADV7511_AUDIO - tristate "HDMI Support ADV7511 audio" - help - Choose this option to support HDMI ADV7511 audio. +config DRM_HISI_KIRIN9XX_DSI + tristate + depends on DRM_HISI_KIRIN9XX + default y diff --git a/drivers/staging/hikey9xx/gpu/Makefile b/drivers/staging/hikey9xx/gpu/Makefile index a5e008365a57..9df7894ccb42 100644 --- a/drivers/staging/hikey9xx/gpu/Makefile +++ b/drivers/staging/hikey9xx/gpu/Makefile @@ -1,15 +1,8 @@ -EXTRA_CFLAGS += \ - -Iinclude/drm -kirin-drm-y := kirin_fbdev.o \ - kirin_fb.o \ - kirin_drm_drv.o \ - kirin_drm_dss.o \ - kirin_drm_dpe_utils.o \ - kirin_drm_overlay_utils.o \ - kirin_pwm.o \ - hdmi/adv7535.o \ +# SPDX-License-Identifier: GPL-2.0-only +kirin9xx-drm-y := kirin9xx_drm_drv.o \ + kirin9xx_drm_dss.o \ + kirin9xx_drm_dpe_utils.o \ + kirin9xx_drm_overlay_utils.o - -obj-$(CONFIG_HDMI_ADV7511_AUDIO) += hdmi/adv7535_audio.o -obj-$(CONFIG_DRM_KIRIN_960) += kirin-drm.o -obj-$(CONFIG_HISI_KIRIN
[PATCH 32/49] staging: hikey9xx/gpu: get rid of iommu_format
Those aren't needed anymore.
Signed-off-by: Mauro Carvalho Chehab
---
drivers/staging/hikey9xx/gpu/kirin960_dpe_reg.h | 1 -
drivers/staging/hikey9xx/gpu/kirin970_dpe_reg.h | 1 -
drivers/staging/hikey9xx/gpu/kirin9xx_drm_drv.h | 2 --
3 files changed, 4 deletions(-)
diff --git a/drivers/staging/hikey9xx/gpu/kirin960_dpe_reg.h
b/drivers/staging/hikey9xx/gpu/kirin960_dpe_reg.h
index a0f7732063a3..7b9da796a671 100644
--- a/drivers/staging/hikey9xx/gpu/kirin960_dpe_reg.h
+++ b/drivers/staging/hikey9xx/gpu/kirin960_dpe_reg.h
@@ -3087,7 +3087,6 @@ struct dss_hw_ctx {
struct iommu_domain *mmu_domain;
struct ion_client *ion_client;
struct ion_handle *ion_handle;
- struct iommu_map_format iommu_format;
char __iomem *screen_base;
unsigned long smem_start;
unsigned long screen_size;
diff --git a/drivers/staging/hikey9xx/gpu/kirin970_dpe_reg.h
b/drivers/staging/hikey9xx/gpu/kirin970_dpe_reg.h
index 84293d2d462e..9c1b62831733 100644
--- a/drivers/staging/hikey9xx/gpu/kirin970_dpe_reg.h
+++ b/drivers/staging/hikey9xx/gpu/kirin970_dpe_reg.h
@@ -4100,7 +4100,6 @@ struct dss_hw_ctx {
struct iommu_domain *mmu_domain;
struct ion_client *ion_client;
struct ion_handle *ion_handle;
- struct iommu_map_format iommu_format;
char __iomem *screen_base;
unsigned long smem_start;
unsigned long screen_size;
diff --git a/drivers/staging/hikey9xx/gpu/kirin9xx_drm_drv.h
b/drivers/staging/hikey9xx/gpu/kirin9xx_drm_drv.h
index 261259cb8f5f..54b4ddc2fe42 100644
--- a/drivers/staging/hikey9xx/gpu/kirin9xx_drm_drv.h
+++ b/drivers/staging/hikey9xx/gpu/kirin9xx_drm_drv.h
@@ -18,7 +18,6 @@
#include
#include
-#include
#define MAX_CRTC 2
@@ -41,7 +40,6 @@ struct kirin_fbdev {
struct ion_client *ion_client;
struct ion_handle *ion_handle;
- struct iommu_map_format iommu_format;
void *screen_base;
unsigned long smem_start;
unsigned long screen_size;
--
2.26.2
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 02/49] staging: hikey9xx/gpu: port it to work with Kernel v4.9
From: John Stultz
Update the driver to work with v4.9 kernels
Signed-off-by: John Stultz
Signed-off-by: Mauro Carvalho Chehab
---
drivers/staging/hikey9xx/gpu/dw_drm_dsi.c | 4 +-
drivers/staging/hikey9xx/gpu/kirin_dpe_reg.h | 1 +
drivers/staging/hikey9xx/gpu/kirin_drm_drv.c | 3 +-
drivers/staging/hikey9xx/gpu/kirin_drm_drv.h | 1 +
drivers/staging/hikey9xx/gpu/kirin_drm_dss.c | 46 ---
.../hikey9xx/gpu/kirin_drm_overlay_utils.c| 7 ++-
6 files changed, 30 insertions(+), 32 deletions(-)
diff --git a/drivers/staging/hikey9xx/gpu/dw_drm_dsi.c
b/drivers/staging/hikey9xx/gpu/dw_drm_dsi.c
index 1d1d4f49609c..9871b375416b 100644
--- a/drivers/staging/hikey9xx/gpu/dw_drm_dsi.c
+++ b/drivers/staging/hikey9xx/gpu/dw_drm_dsi.c
@@ -1079,7 +1079,7 @@ static int dw_drm_encoder_init(struct device *dev,
encoder->possible_crtcs = crtc_mask;
ret = drm_encoder_init(drm_dev, encoder, &dw_encoder_funcs,
- DRM_MODE_ENCODER_DSI);
+ DRM_MODE_ENCODER_DSI, NULL);
if (ret) {
DRM_ERROR("failed to init dsi encoder\n");
return ret;
@@ -1104,7 +1104,7 @@ static int dsi_host_attach(struct mipi_dsi_host *host,
dsi->client[id].lanes = mdsi->lanes;
dsi->client[id].format = mdsi->format;
dsi->client[id].mode_flags = mdsi->mode_flags;
- dsi->client[id].phy_clock = mdsi->phy_clock;
+ dsi->client[id].phy_clock = 0;
DRM_INFO("host attach, client name=[%s], id=%d\n", mdsi->name, id);
diff --git a/drivers/staging/hikey9xx/gpu/kirin_dpe_reg.h
b/drivers/staging/hikey9xx/gpu/kirin_dpe_reg.h
index 61af8ef81878..9fad9ef942bd 100644
--- a/drivers/staging/hikey9xx/gpu/kirin_dpe_reg.h
+++ b/drivers/staging/hikey9xx/gpu/kirin_dpe_reg.h
@@ -18,6 +18,7 @@
#include
#include
#include
+#include
#include
#include
diff --git a/drivers/staging/hikey9xx/gpu/kirin_drm_drv.c
b/drivers/staging/hikey9xx/gpu/kirin_drm_drv.c
index edb690062f64..ffa0cd792bf1 100644
--- a/drivers/staging/hikey9xx/gpu/kirin_drm_drv.c
+++ b/drivers/staging/hikey9xx/gpu/kirin_drm_drv.c
@@ -200,9 +200,8 @@ static int kirin_drm_connectors_register(struct drm_device
*dev)
static struct drm_driver kirin_drm_driver = {
.driver_features= DRIVER_GEM | DRIVER_MODESET | DRIVER_PRIME |
- DRIVER_ATOMIC | DRIVER_HAVE_IRQ |
DRIVER_RENDER,
+ DRIVER_ATOMIC | DRIVER_RENDER,
.fops = &kirin_drm_fops,
- .set_busid = drm_platform_set_busid,
.gem_free_object= drm_gem_cma_free_object,
.gem_vm_ops = &drm_gem_cma_vm_ops,
diff --git a/drivers/staging/hikey9xx/gpu/kirin_drm_drv.h
b/drivers/staging/hikey9xx/gpu/kirin_drm_drv.h
index b361f5f69932..2f842ad36ae9 100644
--- a/drivers/staging/hikey9xx/gpu/kirin_drm_drv.h
+++ b/drivers/staging/hikey9xx/gpu/kirin_drm_drv.h
@@ -12,6 +12,7 @@
#define __KIRIN_DRM_DRV_H__
#include
+#include
#include
#include
#include
diff --git a/drivers/staging/hikey9xx/gpu/kirin_drm_dss.c
b/drivers/staging/hikey9xx/gpu/kirin_drm_dss.c
index 2a92372d0c81..c47d860f4697 100644
--- a/drivers/staging/hikey9xx/gpu/kirin_drm_dss.c
+++ b/drivers/staging/hikey9xx/gpu/kirin_drm_dss.c
@@ -213,6 +213,7 @@ static void dss_disable_vblank(struct drm_device *dev,
unsigned int pipe)
static irqreturn_t dss_irq_handler(int irq, void *data)
{
struct dss_crtc *acrtc = data;
+ struct drm_crtc *crtc = &acrtc->base;
struct dss_hw_ctx *ctx = acrtc->ctx;
void __iomem *dss_base = ctx->base;
@@ -241,8 +242,10 @@ static irqreturn_t dss_irq_handler(int irq, void *data)
wake_up_interruptible_all(&ctx->vactive0_start_wq);
}
- if (isr_s2 & BIT_VSYNC)
+ if (isr_s2 & BIT_VSYNC) {
ctx->vsync_timestamp = ktime_get();
+ drm_crtc_handle_vblank(crtc);
+ }
if (isr_s2 & BIT_LDI_UNFLOW) {
mask = inp32(dss_base + DSS_LDI0_OFFSET + LDI_CPU_ITF_INT_MSK);
@@ -271,6 +274,7 @@ static void dss_crtc_enable(struct drm_crtc *crtc)
}
acrtc->enable = true;
+ drm_crtc_vblank_on(crtc);
}
static void dss_crtc_disable(struct drm_crtc *crtc)
@@ -282,13 +286,7 @@ static void dss_crtc_disable(struct drm_crtc *crtc)
/*dss_power_down(acrtc);*/
acrtc->enable = false;
-}
-
-static int dss_crtc_atomic_check(struct drm_crtc *crtc,
-struct drm_crtc_state *state)
-{
- /* do nothing */
- return 0;
+ drm_crtc_vblank_off(crtc);
}
static void dss_crtc_mode_set_nofb(struct drm_crtc *crtc)
@@ -315,13 +313,24 @@ static void dss_crtc_atomic_flush(struct drm_crtc *crtc,
struct drm_crtc_state *old_state)
{
+ struct drm_pending_vblank_event *event = crtc->state->event;
+
+ if (event
[PATCH 18/49] staging: hikey9xx/gpu: port driver to upstream kAPIs
There were several changes at the upstream kAPIs since
Kernel 4.4. Update the driver for it to build with the
upstream Kernel.
Signed-off-by: Mauro Carvalho Chehab
---
.../staging/hikey9xx/gpu/kirin9xx_drm_drv.c | 28 +++---
.../staging/hikey9xx/gpu/kirin9xx_drm_dss.c | 26 +++---
.../hikey9xx/gpu/kirin9xx_drm_overlay_utils.c | 6 +-
.../hikey9xx/gpu/kirin9xx_dw_drm_dsi.c| 86 ++-
4 files changed, 57 insertions(+), 89 deletions(-)
diff --git a/drivers/staging/hikey9xx/gpu/kirin9xx_drm_drv.c
b/drivers/staging/hikey9xx/gpu/kirin9xx_drm_drv.c
index 616fa7ca9c77..49f591da1cf7 100644
--- a/drivers/staging/hikey9xx/gpu/kirin9xx_drm_drv.c
+++ b/drivers/staging/hikey9xx/gpu/kirin9xx_drm_drv.c
@@ -46,7 +46,6 @@ static int kirin_drm_kms_cleanup(struct drm_device *dev)
priv->fbdev = NULL;
drm_kms_helper_poll_fini(dev);
- drm_vblank_cleanup(dev);
dc_ops->cleanup(dev);
drm_mode_config_cleanup(dev);
devm_kfree(dev->dev, priv);
@@ -80,7 +79,7 @@ static void kirin_fbdev_output_poll_changed(struct drm_device
*dev)
}
static const struct drm_mode_config_funcs kirin_drm_mode_config_funcs = {
- .fb_create = drm_fb_cma_create,
+ .fb_create = drm_gem_fb_create,
.output_poll_changed = kirin_fbdev_output_poll_changed,
.atomic_check = drm_atomic_helper_check,
.atomic_commit = drm_atomic_helper_commit,
@@ -182,12 +181,14 @@ static int kirin_gem_cma_dumb_create(struct drm_file
*file,
static int kirin_drm_connectors_register(struct drm_device *dev)
{
- struct drm_connector *connector;
+ struct drm_connector_list_iter conn_iter;
struct drm_connector *failed_connector;
+ struct drm_connector *connector;
int ret;
mutex_lock(&dev->mode_config.mutex);
- drm_for_each_connector(connector, dev) {
+ drm_connector_list_iter_begin(dev, &conn_iter);
+ drm_for_each_connector_iter(connector, &conn_iter) {
ret = drm_connector_register(connector);
if (ret) {
failed_connector = connector;
@@ -199,7 +200,8 @@ static int kirin_drm_connectors_register(struct drm_device
*dev)
return 0;
err:
- drm_for_each_connector(connector, dev) {
+ drm_connector_list_iter_begin(dev, &conn_iter);
+ drm_for_each_connector_iter(connector, &conn_iter) {
if (failed_connector == connector)
break;
drm_connector_unregister(connector);
@@ -210,15 +212,13 @@ static int kirin_drm_connectors_register(struct
drm_device *dev)
}
static struct drm_driver kirin_drm_driver = {
- .driver_features= DRIVER_GEM | DRIVER_MODESET | DRIVER_PRIME |
+ .driver_features= DRIVER_GEM | DRIVER_MODESET |
DRIVER_ATOMIC | DRIVER_RENDER,
.fops = &kirin_drm_fops,
.gem_free_object= drm_gem_cma_free_object,
.gem_vm_ops = &drm_gem_cma_vm_ops,
.dumb_create= kirin_gem_cma_dumb_create,
- .dumb_map_offset= drm_gem_cma_dumb_map_offset,
- .dumb_destroy = drm_gem_dumb_destroy,
.prime_handle_to_fd = drm_gem_prime_handle_to_fd,
.prime_fd_to_handle = drm_gem_prime_fd_to_handle,
@@ -258,14 +258,10 @@ static int kirin_drm_bind(struct device *dev)
struct drm_device *drm_dev;
int ret;
- //drm_platform_init(&kirin_drm_driver, to_platform_device(dev));
-
drm_dev = drm_dev_alloc(driver, dev);
if (!drm_dev)
return -ENOMEM;
- drm_dev->platformdev = to_platform_device(dev);
-
ret = kirin_drm_kms_init(drm_dev);
if (ret)
goto err_drm_dev_unref;
@@ -290,14 +286,18 @@ static int kirin_drm_bind(struct device *dev)
err_kms_cleanup:
kirin_drm_kms_cleanup(drm_dev);
err_drm_dev_unref:
- drm_dev_unref(drm_dev);
+ drm_dev_put(drm_dev);
return ret;
}
static void kirin_drm_unbind(struct device *dev)
{
- drm_put_dev(dev_get_drvdata(dev));
+ struct drm_device *drm_dev = dev_get_drvdata(dev);
+
+ drm_dev_unregister(drm_dev);
+ kirin_drm_kms_cleanup(drm_dev);
+ drm_dev_put(drm_dev);
}
static const struct component_master_ops kirin_drm_ops = {
diff --git a/drivers/staging/hikey9xx/gpu/kirin9xx_drm_dss.c
b/drivers/staging/hikey9xx/gpu/kirin9xx_drm_dss.c
index fd0ccbaebd3f..e7907a0b511c 100644
--- a/drivers/staging/hikey9xx/gpu/kirin9xx_drm_dss.c
+++ b/drivers/staging/hikey9xx/gpu/kirin9xx_drm_dss.c
@@ -458,7 +458,8 @@ static irqreturn_t dss_irq_handler(int irq, void *data)
return IRQ_HANDLED;
}
-static void dss_crtc_enable(struct drm_crtc *crtc)
+static void dss_crtc_enable(struct drm_crtc *crtc,
+ struct drm_crtc_state *old_state)
{
struct dss_crtc *acrtc = to_dss_crtc(crtc);
struct
[PATCH 07/49] staging: hikey9xx/gpu: Solve HDMI compatibility Problem.
From: Xiubin Zhang
Modfiy pix_clk and dsi lanes to improve HDMI compatibility for hikey970.
Signed-off-by: Xiubin Zhang
Signed-off-by: Mauro Carvalho Chehab
---
drivers/staging/hikey9xx/gpu/dw_drm_dsi.c | 53 ++-
drivers/staging/hikey9xx/gpu/hdmi/adv7535.c | 9 +-
.../hikey9xx/gpu/kirin_drm_dpe_utils.c| 133 ++
.../hikey9xx/gpu/kirin_drm_dpe_utils.h| 2 +-
drivers/staging/hikey9xx/gpu/kirin_drm_drv.c | 7 -
drivers/staging/hikey9xx/gpu/kirin_drm_dss.c | 17 +--
.../hikey9xx/gpu/kirin_drm_overlay_utils.c| 3 -
drivers/staging/hikey9xx/gpu/kirin_fb_panel.h | 5 -
drivers/staging/hikey9xx/gpu/kirin_fbdev.c| 10 +-
9 files changed, 41 insertions(+), 198 deletions(-)
diff --git a/drivers/staging/hikey9xx/gpu/dw_drm_dsi.c
b/drivers/staging/hikey9xx/gpu/dw_drm_dsi.c
index e69f4a9bca58..e87363ab7373 100644
--- a/drivers/staging/hikey9xx/gpu/dw_drm_dsi.c
+++ b/drivers/staging/hikey9xx/gpu/dw_drm_dsi.c
@@ -312,6 +312,7 @@ void dsi_set_output_client(struct drm_device *dev)
}
EXPORT_SYMBOL(dsi_set_output_client);
+#if defined (CONFIG_HISI_FB_970)
static void get_dsi_dphy_ctrl(struct dw_dsi *dsi,
struct mipi_phy_params
*phy_ctrl)
{
@@ -357,10 +358,8 @@ static void get_dsi_dphy_ctrl(struct dw_dsi *dsi,
bpp = mipi_dsi_pixel_format_to_bpp(dsi->client[id].format);
if (bpp < 0)
return;
- if (mode->clock > 8)
- dsi->client[id].lanes = 4;
- else
- dsi->client[id].lanes = 3;
+
+ dsi->client[id].lanes = 4;
if (dsi->client[id].phy_clock)
dphy_req_kHz = dsi->client[id].phy_clock;
@@ -387,33 +386,7 @@ static void get_dsi_dphy_ctrl(struct dw_dsi *dsi,
m_n_int = lane_clock * vco_div * 100UL / DEFAULT_MIPI_CLK_RATE;
m_n_fract = ((lane_clock * vco_div * 100UL * 1000UL /
DEFAULT_MIPI_CLK_RATE) % 1000) * 10 / 1000;
- if (m_n_int % 2 == 0) {
- if (m_n_fract * 6 >= 50) {
- n_pll = 2;
- m_pll = (m_n_int + 1) * n_pll;
- } else if (m_n_fract * 6 >= 30) {
- n_pll = 3;
- m_pll = m_n_int * n_pll + 2;
- } else {
- n_pll = 1;
- m_pll = m_n_int * n_pll;
- }
- } else {
- if (m_n_fract * 6 >= 50) {
- n_pll = 1;
- m_pll = (m_n_int + 1) * n_pll;
- } else if (m_n_fract * 6 >= 30) {
- n_pll = 1;
- m_pll = (m_n_int + 1) * n_pll;
- } else if (m_n_fract * 6 >= 10) {
- n_pll = 3;
- m_pll = m_n_int * n_pll + 1;
- } else {
- n_pll = 2;
- m_pll = m_n_int * n_pll;
- }
- }
- //n_pll = 2;
+ n_pll = 2;
m_pll = (u32)(lane_clock * vco_div * n_pll * 100UL /
DEFAULT_MIPI_CLK_RATE);
@@ -568,7 +541,7 @@ static void get_dsi_dphy_ctrl(struct dw_dsi *dsi,
phy_ctrl->data_lane_hs2lp_time,
phy_ctrl->phy_stop_wait_time);
}
-
+#else
static void get_dsi_phy_ctrl(struct dw_dsi *dsi,
struct mipi_phy_params
*phy_ctrl)
{
@@ -887,7 +860,7 @@ static void get_dsi_phy_ctrl(struct dw_dsi *dsi,
phy_ctrl->data_t_hs_trial,
phy_ctrl->data_t_ta_go,
phy_ctrl->data_t_ta_get);
- DRM_INFO("clk_lane_lp2hs_time=%u\n"
+ DRM_DEBUG("clk_lane_lp2hs_time=%u\n"
"clk_lane_hs2lp_time=%u\n"
"data_lane_lp2hs_time=%u\n"
"data_lane_hs2lp_time=%u\n"
@@ -898,6 +871,7 @@ static void get_dsi_phy_ctrl(struct dw_dsi *dsi,
phy_ctrl->data_lane_hs2lp_time,
phy_ctrl->phy_stop_wait_time);
}
+#endif
static void dw_dsi_set_mode(struct dw_dsi *dsi, enum dsi_work_mode mode)
{
@@ -962,13 +936,11 @@ static void mipi_config_dphy_spec1v2_parameter(struct
dw_dsi *dsi, char __iomem
lanes = dsi->client[dsi->cur_client].lanes - 1;
-#if defined (CONFIG_HISI_FB_970)
- for (i = 0; i <= lanes; i++) {
+ for (i = 0; i <= (lanes+1); i++) {
//Lane Transmission Property
addr = MIPIDSI_PHY_TST_LANE_TRANSMISSION_PROPERTY + (i << 5);
dsi_phy_tst_set(mipi_dsi_base, addr, 0x43);
}
-#endif
//pre_delay of clock lane request setting
dsi_phy_tst_set(mipi_dsi_base, MIPIDSI_PHY_TST_CLK_PRE_DELAY,
DSS_REDUCE(dsi->phy.clk_pre_delay));
@@ -988,7 +960,7 @@ static void mipi_config_dphy_spec1v2_parameter(struct
dw_dsi *dsi, char __iomem
//clock lane timing ctrl - t_hs_trial
dsi_phy_tst_set(mipi_dsi_base, MIPIDSI_PHY_TST_CLK_TRAIL,
DSS_REDUCE(dsi->phy.clk_t_hs_trial));
- f
[PATCH 30/49] staging: hikey9xx/gpu: register connector
call drm_connector_register() when initializing the connector.
Signed-off-by: Mauro Carvalho Chehab
---
drivers/staging/hikey9xx/gpu/kirin9xx_dw_drm_dsi.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/staging/hikey9xx/gpu/kirin9xx_dw_drm_dsi.c
b/drivers/staging/hikey9xx/gpu/kirin9xx_dw_drm_dsi.c
index 39ec39a6a69b..09d035038c1a 100644
--- a/drivers/staging/hikey9xx/gpu/kirin9xx_dw_drm_dsi.c
+++ b/drivers/staging/hikey9xx/gpu/kirin9xx_dw_drm_dsi.c
@@ -1786,6 +1786,8 @@ static int dsi_connector_init(struct drm_device *dev,
struct dw_dsi *dsi)
if (ret)
return ret;
+ drm_connector_register(&dsi->connector);
+
DRM_INFO("connector init\n");
return 0;
}
--
2.26.2
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 16/49] staging: hikey9xx/gpu: rename the config option for Kirin970
Use the same standard as used on other Hisilicon DRM
config vars for kirin9xx.
Signed-off-by: Mauro Carvalho Chehab
---
.../staging/hikey9xx/gpu/kirin9xx_drm_dpe_utils.c| 2 +-
.../staging/hikey9xx/gpu/kirin9xx_drm_dpe_utils.h| 2 +-
drivers/staging/hikey9xx/gpu/kirin9xx_drm_dss.c | 12 ++--
.../hikey9xx/gpu/kirin9xx_drm_overlay_utils.c| 2 +-
4 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/staging/hikey9xx/gpu/kirin9xx_drm_dpe_utils.c
b/drivers/staging/hikey9xx/gpu/kirin9xx_drm_dpe_utils.c
index 8aa43619c888..fe8372838bb3 100644
--- a/drivers/staging/hikey9xx/gpu/kirin9xx_drm_dpe_utils.c
+++ b/drivers/staging/hikey9xx/gpu/kirin9xx_drm_dpe_utils.c
@@ -993,7 +993,7 @@ int dpe_regulator_disable(struct dss_hw_ctx *ctx)
return -EINVAL;
}
- #if defined (CONFIG_HISI_FB_970)
+ #if defined (CONFIG_DRM_HISI_KIRIN970)
dpe_set_pixel_clk_rate_on_pll0(ctx);
dpe_set_common_clk_rate_on_pll0(ctx);
#endif
diff --git a/drivers/staging/hikey9xx/gpu/kirin9xx_drm_dpe_utils.h
b/drivers/staging/hikey9xx/gpu/kirin9xx_drm_dpe_utils.h
index 5ef5c6c6edbb..89aaf6691f1d 100644
--- a/drivers/staging/hikey9xx/gpu/kirin9xx_drm_dpe_utils.h
+++ b/drivers/staging/hikey9xx/gpu/kirin9xx_drm_dpe_utils.h
@@ -14,7 +14,7 @@
#ifndef KIRIN_DRM_DPE_UTILS_H
#define KIRIN_DRM_DPE_UTILS_H
-#if defined (CONFIG_HISI_FB_970)
+#if defined (CONFIG_DRM_HISI_KIRIN970)
#include "kirin970_dpe_reg.h"
#else
#include "kirin_dpe_reg.h"
diff --git a/drivers/staging/hikey9xx/gpu/kirin9xx_drm_dss.c
b/drivers/staging/hikey9xx/gpu/kirin9xx_drm_dss.c
index 693f5499c8d0..b4c1bb8288de 100644
--- a/drivers/staging/hikey9xx/gpu/kirin9xx_drm_dss.c
+++ b/drivers/staging/hikey9xx/gpu/kirin9xx_drm_dss.c
@@ -37,7 +37,7 @@
#include "kirin_drm_drv.h"
#include "kirin_drm_dpe_utils.h"
-#if defined (CONFIG_HISI_FB_970)
+#if defined (CONFIG_DRM_HISI_KIRIN970)
#include "kirin970_dpe_reg.h"
#else
#include "kirin_dpe_reg.h"
@@ -45,7 +45,7 @@
//#define DSS_POWER_UP_ON_UEFI
-#if defined (CONFIG_HISI_FB_970)
+#if defined (CONFIG_DRM_HISI_KIRIN970)
#define DTS_COMP_DSS_NAME "hisilicon,kirin970-dpe"
#else
#define DTS_COMP_DSS_NAME "hisilicon,hi3660-dpe"
@@ -310,7 +310,7 @@ static int dss_power_up(struct dss_crtc *acrtc)
struct dss_hw_ctx *ctx = acrtc->ctx;
int ret = 0;
-#if defined (CONFIG_HISI_FB_970)
+#if defined (CONFIG_DRM_HISI_KIRIN970)
mediacrg_regulator_enable(ctx);
dpe_common_clk_enable(ctx);
dpe_inner_clk_enable(ctx);
@@ -706,7 +706,7 @@ static int dss_dts_parse(struct platform_device *pdev,
struct dss_hw_ctx *ctx)
return -ENXIO;
}
-#if defined (CONFIG_HISI_FB_970)
+#if defined (CONFIG_DRM_HISI_KIRIN970)
ret = of_property_read_u32(np, "dss_version_tag", &dss_version_tag);
if (ret) {
DRM_ERROR("failed to get dss_version_tag.\n");
@@ -756,7 +756,7 @@ static int dss_dts_parse(struct platform_device *pdev,
struct dss_hw_ctx *ctx)
return -ENXIO;
}
-#if defined (CONFIG_HISI_FB_970)
+#if defined (CONFIG_DRM_HISI_KIRIN970)
ctx->pmctrl_base = of_iomap(np, 5);
if (!(ctx->pmctrl_base)) {
DRM_ERROR ("failed to get dss pmctrl_base resource.\n");
@@ -780,7 +780,7 @@ static int dss_dts_parse(struct platform_device *pdev,
struct dss_hw_ctx *ctx)
DRM_INFO("dss irq = %d. \n", ctx->irq);
#ifndef DSS_POWER_UP_ON_UEFI
-#if defined (CONFIG_HISI_FB_970)
+#if defined (CONFIG_DRM_HISI_KIRIN970)
ctx->dpe_regulator = devm_regulator_get(dev, REGULATOR_PDP_NAME);
if (!ctx->dpe_regulator) {
DRM_ERROR("failed to get dpe_regulator resource! ret=%d.\n",
ret);
diff --git a/drivers/staging/hikey9xx/gpu/kirin9xx_drm_overlay_utils.c
b/drivers/staging/hikey9xx/gpu/kirin9xx_drm_overlay_utils.c
index 6246316d81b0..342a7f6fc964 100644
--- a/drivers/staging/hikey9xx/gpu/kirin9xx_drm_overlay_utils.c
+++ b/drivers/staging/hikey9xx/gpu/kirin9xx_drm_overlay_utils.c
@@ -30,7 +30,7 @@
static int mid_array[DSS_CHN_MAX_DEFINE] = {0xb, 0xa, 0x9, 0x8, 0x7, 0x6, 0x5,
0x4, 0x2, 0x1, 0x3, 0x0};
-#if defined (CONFIG_HISI_FB_970)
+#if defined (CONFIG_DRM_HISI_KIRIN970)
uint32_t g_dss_module_base[DSS_CHN_MAX_DEFINE][MODULE_CHN_MAX] = {
// D0
{
--
2.26.2
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 35/49] staging: hikey9xx/gpu: add SPMI headers
Use SPMI headers to identify the license of each file. Signed-off-by: Mauro Carvalho Chehab --- .../staging/hikey9xx/gpu/kirin960_dpe_reg.h | 1 + .../staging/hikey9xx/gpu/kirin970_dpe_reg.h | 1 + .../hikey9xx/gpu/kirin9xx_drm_dpe_utils.c | 4 ++- .../hikey9xx/gpu/kirin9xx_drm_dpe_utils.h | 4 ++- .../staging/hikey9xx/gpu/kirin9xx_drm_drv.c | 1 + .../staging/hikey9xx/gpu/kirin9xx_drm_drv.h | 1 + .../staging/hikey9xx/gpu/kirin9xx_drm_dss.c | 1 + .../hikey9xx/gpu/kirin9xx_drm_overlay_utils.c | 10 +++ .../hikey9xx/gpu/kirin9xx_dw_drm_dsi.c| 2 +- .../hikey9xx/gpu/kirin9xx_dw_dsi_reg.h| 1 + .../staging/hikey9xx/gpu/kirin9xx_fb_panel.h | 25 +- drivers/staging/hikey9xx/gpu/kirin9xx_pwm.c | 26 ++- 12 files changed, 43 insertions(+), 34 deletions(-) diff --git a/drivers/staging/hikey9xx/gpu/kirin960_dpe_reg.h b/drivers/staging/hikey9xx/gpu/kirin960_dpe_reg.h index 7b9da796a671..131bb80d9bd1 100644 --- a/drivers/staging/hikey9xx/gpu/kirin960_dpe_reg.h +++ b/drivers/staging/hikey9xx/gpu/kirin960_dpe_reg.h @@ -1,3 +1,4 @@ +/* SPDX-License-Identifier: GPL-2.0 */ /* * Copyright (c) 2016 Linaro Limited. * Copyright (c) 2014-2016 Hisilicon Limited. diff --git a/drivers/staging/hikey9xx/gpu/kirin970_dpe_reg.h b/drivers/staging/hikey9xx/gpu/kirin970_dpe_reg.h index 0c6b6eb9dcab..00bbad95ee3d 100644 --- a/drivers/staging/hikey9xx/gpu/kirin970_dpe_reg.h +++ b/drivers/staging/hikey9xx/gpu/kirin970_dpe_reg.h @@ -1,3 +1,4 @@ +/* SPDX-License-Identifier: GPL-2.0 */ /* * Copyright (c) 2016 Linaro Limited. * Copyright (c) 2014-2016 Hisilicon Limited. diff --git a/drivers/staging/hikey9xx/gpu/kirin9xx_drm_dpe_utils.c b/drivers/staging/hikey9xx/gpu/kirin9xx_drm_dpe_utils.c index 3b8ff0bdd359..fa317be188e0 100644 --- a/drivers/staging/hikey9xx/gpu/kirin9xx_drm_dpe_utils.c +++ b/drivers/staging/hikey9xx/gpu/kirin9xx_drm_dpe_utils.c @@ -1,4 +1,6 @@ -/* Copyright (c) 2013-2014, Hisilicon Tech. Co., Ltd. All rights reserved. +// SPDX-License-Identifier: GPL-2.0 +/* + * Copyright (c) 2013-2014, Hisilicon Tech. Co., Ltd. All rights reserved. * * This program is free software; you can redistribute it and/or modify * it under the terms of the GNU General Public License version 2 and diff --git a/drivers/staging/hikey9xx/gpu/kirin9xx_drm_dpe_utils.h b/drivers/staging/hikey9xx/gpu/kirin9xx_drm_dpe_utils.h index 0c5681d0a5ac..e3681c26f7f4 100644 --- a/drivers/staging/hikey9xx/gpu/kirin9xx_drm_dpe_utils.h +++ b/drivers/staging/hikey9xx/gpu/kirin9xx_drm_dpe_utils.h @@ -1,4 +1,6 @@ -/* Copyright (c) 2013-2014, Hisilicon Tech. Co., Ltd. All rights reserved. +/* SPDX-License-Identifier: GPL-2.0 */ +/* + * Copyright (c) 2013-2014, Hisilicon Tech. Co., Ltd. All rights reserved. * * This program is free software; you can redistribute it and/or modify * it under the terms of the GNU General Public License version 2 and diff --git a/drivers/staging/hikey9xx/gpu/kirin9xx_drm_drv.c b/drivers/staging/hikey9xx/gpu/kirin9xx_drm_drv.c index 3d1b5f738a7f..12668646c2d3 100644 --- a/drivers/staging/hikey9xx/gpu/kirin9xx_drm_drv.c +++ b/drivers/staging/hikey9xx/gpu/kirin9xx_drm_drv.c @@ -1,3 +1,4 @@ +// SPDX-License-Identifier: GPL-2.0 /* * Hisilicon Kirin SoCs drm master driver * diff --git a/drivers/staging/hikey9xx/gpu/kirin9xx_drm_drv.h b/drivers/staging/hikey9xx/gpu/kirin9xx_drm_drv.h index 54b4ddc2fe42..8322abc0752c 100644 --- a/drivers/staging/hikey9xx/gpu/kirin9xx_drm_drv.h +++ b/drivers/staging/hikey9xx/gpu/kirin9xx_drm_drv.h @@ -1,3 +1,4 @@ +/* SPDX-License-Identifier: GPL-2.0 */ /* * Copyright (c) 2016 Linaro Limited. * Copyright (c) 2014-2016 Hisilicon Limited. diff --git a/drivers/staging/hikey9xx/gpu/kirin9xx_drm_dss.c b/drivers/staging/hikey9xx/gpu/kirin9xx_drm_dss.c index fe5b371734fe..10e62bdb9161 100644 --- a/drivers/staging/hikey9xx/gpu/kirin9xx_drm_dss.c +++ b/drivers/staging/hikey9xx/gpu/kirin9xx_drm_dss.c @@ -1,3 +1,4 @@ +// SPDX-License-Identifier: GPL-2.0 /* * Hisilicon Hi6220 SoC ADE(Advanced Display Engine)'s crtc&plane driver * diff --git a/drivers/staging/hikey9xx/gpu/kirin9xx_drm_overlay_utils.c b/drivers/staging/hikey9xx/gpu/kirin9xx_drm_overlay_utils.c index 2b9672a3d057..128d63d74168 100644 --- a/drivers/staging/hikey9xx/gpu/kirin9xx_drm_overlay_utils.c +++ b/drivers/staging/hikey9xx/gpu/kirin9xx_drm_overlay_utils.c @@ -1,4 +1,6 @@ -/* Copyright (c) 2008-2011, Hisilicon Tech. Co., Ltd. All rights reserved. +// SPDX-License-Identifier: GPL-2.0 +/* + * Copyright (c) 2008-2011, Hisilicon Tech. Co., Ltd. All rights reserved. * * This program is free software; you can redistribute it and/or modify * it under the terms of the GNU General Public License version 2 and @@ -8,12 +10,6 @@ * but WITHOUT ANY WARRANTY; without even the implied warranty of * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the * GNU General Public License for more details. - * - * You should have received a
[PATCH 20/49] staging: hikey9xx/gpu: get rid of ION headers
This is not used anymore on this version, so let's get rid of them. Signed-off-by: Mauro Carvalho Chehab --- drivers/staging/hikey9xx/gpu/kirin960_dpe_reg.h | 3 --- drivers/staging/hikey9xx/gpu/kirin970_dpe_reg.h | 3 --- drivers/staging/hikey9xx/gpu/kirin9xx_drm_drv.h | 2 -- 3 files changed, 8 deletions(-) diff --git a/drivers/staging/hikey9xx/gpu/kirin960_dpe_reg.h b/drivers/staging/hikey9xx/gpu/kirin960_dpe_reg.h index 995ab8f7c9f4..a0f7732063a3 100644 --- a/drivers/staging/hikey9xx/gpu/kirin960_dpe_reg.h +++ b/drivers/staging/hikey9xx/gpu/kirin960_dpe_reg.h @@ -27,9 +27,6 @@ #include #include -#include -#include - #define FB_ACCEL_HI62xx0x1 #define FB_ACCEL_HI363x0x2 #define FB_ACCEL_HI365x0x4 diff --git a/drivers/staging/hikey9xx/gpu/kirin970_dpe_reg.h b/drivers/staging/hikey9xx/gpu/kirin970_dpe_reg.h index ece49b99dca7..84293d2d462e 100644 --- a/drivers/staging/hikey9xx/gpu/kirin970_dpe_reg.h +++ b/drivers/staging/hikey9xx/gpu/kirin970_dpe_reg.h @@ -27,9 +27,6 @@ #include #include -#include -#include - #define FB_ACCEL_HI62xx0x1 #define FB_ACCEL_HI363x0x2 #define FB_ACCEL_HI365x0x4 diff --git a/drivers/staging/hikey9xx/gpu/kirin9xx_drm_drv.h b/drivers/staging/hikey9xx/gpu/kirin9xx_drm_drv.h index 15ef96840e9f..b704f025d64b 100644 --- a/drivers/staging/hikey9xx/gpu/kirin9xx_drm_drv.h +++ b/drivers/staging/hikey9xx/gpu/kirin9xx_drm_drv.h @@ -17,8 +17,6 @@ #include #include -#include -#include #include #define MAX_CRTC 2 -- 2.26.2 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 03/49] staging: hikey9xx/gpu: solve tearing issue of display
From: Liwei Cai
The use of synchronization mechanisms to deal with the display of
buffer, to solve the problem of display tearing.
Signed-off-by: Wanchun Zheng
Signed-off-by: Liwei Cai
Signed-off-by: John Stultz
Signed-off-by: Mauro Carvalho Chehab
---
drivers/staging/hikey9xx/gpu/dw_drm_dsi.c | 3 +-
drivers/staging/hikey9xx/gpu/kirin_drm_dss.c | 4 +-
.../hikey9xx/gpu/kirin_drm_overlay_utils.c| 90 ---
3 files changed, 41 insertions(+), 56 deletions(-)
diff --git a/drivers/staging/hikey9xx/gpu/dw_drm_dsi.c
b/drivers/staging/hikey9xx/gpu/dw_drm_dsi.c
index 9871b375416b..db408beb33ec 100644
--- a/drivers/staging/hikey9xx/gpu/dw_drm_dsi.c
+++ b/drivers/staging/hikey9xx/gpu/dw_drm_dsi.c
@@ -35,7 +35,6 @@
#define DTS_COMP_DSI_NAME "hisilicon,hi3660-dsi"
-#define MAX_TX_ESC_CLK 10
#define ROUND(x, y)((x) / (y) + \
((x) % (y) * 10 / (y) >= 5 ? 1 : 0))
#define ROUND1(x, y) ((x) / (y) + ((x) % (y) ? 1 : 0))
@@ -1237,7 +1236,7 @@ static int dsi_host_init(struct device *dev, struct
dw_dsi *dsi)
host->dev = dev;
host->ops = &dsi_host_ops;
- mipi->max_tx_esc_clk = 10;
+ mipi->max_tx_esc_clk = 10 * 100UL;
mipi->vc = 0;
mipi->color_mode = DSI_24BITS_1;
mipi->clk_post_adjust = 120;
diff --git a/drivers/staging/hikey9xx/gpu/kirin_drm_dss.c
b/drivers/staging/hikey9xx/gpu/kirin_drm_dss.c
index c47d860f4697..62ac1a0648cc 100644
--- a/drivers/staging/hikey9xx/gpu/kirin_drm_dss.c
+++ b/drivers/staging/hikey9xx/gpu/kirin_drm_dss.c
@@ -167,8 +167,8 @@ static int dss_power_up(struct dss_crtc *acrtc)
dss_inner_clk_common_enable(acrtc);
dpe_interrupt_mask(acrtc);
dpe_interrupt_clear(acrtc);
- dpe_irq_enable(acrtc);
- dpe_interrupt_unmask(acrtc);
+ //dpe_irq_enable(acrtc);
+ //dpe_interrupt_unmask(acrtc);
ctx->power_on = true;
return 0;
diff --git a/drivers/staging/hikey9xx/gpu/kirin_drm_overlay_utils.c
b/drivers/staging/hikey9xx/gpu/kirin_drm_overlay_utils.c
index 095335eba16d..917e1a7d7bdf 100644
--- a/drivers/staging/hikey9xx/gpu/kirin_drm_overlay_utils.c
+++ b/drivers/staging/hikey9xx/gpu/kirin_drm_overlay_utils.c
@@ -30,6 +30,7 @@
#define DSS_CHN_MAX_DEFINE (DSS_COPYBIT_MAX)
+#define TIME_OUT (16)
static int mid_array[DSS_CHN_MAX_DEFINE] = {0xb, 0xa, 0x9, 0x8, 0x7, 0x6, 0x5,
0x4, 0x2, 0x1, 0x3, 0x0};
@@ -1064,6 +1065,38 @@ void hisi_dss_unflow_handler(struct dss_hw_ctx *ctx,
bool unmask)
outp32(dss_base + DSS_LDI0_OFFSET + LDI_CPU_ITF_INT_MSK, tmp);
}
+void hisi_dss_wait_for_complete(struct dss_hw_ctx *ctx, bool need_clear)
+{
+ void __iomem *dss_base;
+ u32 tmp = 0;
+ u32 isr_s2 = 0;
+
+ if (!ctx) {
+ DRM_ERROR("ctx is NULL!\n");
+ return;
+ }
+
+ dss_base = ctx->base;
+
+ do {
+ isr_s2 = inp32(dss_base + DSS_LDI0_OFFSET + LDI_CPU_ITF_INTS);
+ if (isr_s2 & BIT_VACTIVE0_END) {
+ DRM_DEBUG("hisi_dss_wait_for_complete exit! temp =
%d\n", tmp);
+ if (need_clear)
+ outp32(dss_base + DSS_LDI0_OFFSET +
LDI_CPU_ITF_INTS, BIT_VACTIVE0_END);
+ break;
+ } else {
+ msleep(1);
+ tmp++;
+ }
+ } while (tmp < TIME_OUT);
+
+ if (tmp == TIME_OUT) {
+ isr_s2 = inp32(dss_base + DSS_LDI0_OFFSET + LDI_CPU_ITF_INTS);
+ DRM_INFO("wait vactive0_end timeout: isr_s2 = 0x%x\n", isr_s2);
+ }
+}
+#if 0
static int hisi_vactive0_start_config(struct dss_hw_ctx *ctx)
{
int ret = 0;
@@ -1094,6 +1127,7 @@ static int hisi_vactive0_start_config(struct dss_hw_ctx
*ctx)
return ret;
}
+#endif
void hisi_fb_pan_display(struct drm_plane *plane)
{
@@ -1109,9 +1143,6 @@ void hisi_fb_pan_display(struct drm_plane *plane)
struct kirin_drm_private *priv = plane->dev->dev_private;
struct kirin_fbdev *fbdev = to_kirin_fbdev(priv->fbdev);
- ktime_t prepare_timestamp;
- u64 vsync_timediff;
-
bool afbcd = false;
bool mmu_enable = true;
dss_rect_ltrb_t rect;
@@ -1164,26 +1195,7 @@ void hisi_fb_pan_display(struct drm_plane *plane)
vbp = mode->vtotal - mode->vsync_end;
vsw = mode->vsync_end - mode->vsync_start;
- vsync_timediff = (uint64_t)(mode->hdisplay + hbp + hfp + hsw) *
- (mode->vdisplay + vbp + vfp + vsw) *
- 10UL / (adj_mode->clock * 1000);
-
- prepare_timestamp = ktime_get();
-
- if ((ktime_to_ns(prepare_timestamp) >
ktime_to_ns(ctx->vsync_timestamp)) &&
- (ktime_to_ns(prepare_timestamp) -
ktime_to_ns(ctx->vsync_timestamp) < (vsync_timediff - 200)) &&
- (ktime_to_ns(ctx->vsync_timestamp_prev) !=
ktime_to_ns(ctx->vsync_timestamp))) {
-
[PATCH 39/49] staging: hikey9xx/gpu: get rid of typedefs
There are a few typedefs inside this driver. Get rid of them.
Signed-off-by: Mauro Carvalho Chehab
---
.../staging/hikey9xx/gpu/kirin960_dpe_reg.h | 126 +-
.../staging/hikey9xx/gpu/kirin970_dpe_reg.h | 117
.../hikey9xx/gpu/kirin9xx_drm_dpe_utils.c | 4 +-
.../hikey9xx/gpu/kirin9xx_drm_dpe_utils.h | 2 +-
.../hikey9xx/gpu/kirin9xx_drm_overlay_utils.c | 8 +-
.../hikey9xx/gpu/kirin9xx_dw_drm_dsi.c| 2 +-
6 files changed, 130 insertions(+), 129 deletions(-)
diff --git a/drivers/staging/hikey9xx/gpu/kirin960_dpe_reg.h
b/drivers/staging/hikey9xx/gpu/kirin960_dpe_reg.h
index 651b3b172033..f34d5af189f7 100644
--- a/drivers/staging/hikey9xx/gpu/kirin960_dpe_reg.h
+++ b/drivers/staging/hikey9xx/gpu/kirin960_dpe_reg.h
@@ -72,19 +72,19 @@ enum dss_channel {
#define PRIMARY_CH DSS_CH1 /* primary plane */
-typedef struct dss_rect {
+struct dss_rect {
s32 x;
s32 y;
s32 w;
s32 h;
-} dss_rect_t;
+};
-typedef struct dss_rect_ltrb {
+struct dss_rect_ltrb {
s32 left;
s32 top;
s32 right;
s32 bottom;
-} dss_rect_ltrb_t;
+};
enum {
DSI_1_LANES = 0,
@@ -103,7 +103,7 @@ enum dss_ovl_idx {
#define DSS_WCH_MAX (2)
-typedef struct dss_img {
+struct dss_img {
u32 format;
u32 width;
u32 height;
@@ -130,13 +130,13 @@ typedef struct dss_img {
u32 secure_mode;
s32 shared_fd;
u32 reserved0;
-} dss_img_t;
+};
-typedef struct drm_dss_layer {
- dss_img_t img;
- dss_rect_t src_rect;
- dss_rect_t src_rect_mask;
- dss_rect_t dst_rect;
+struct drm_dss_layer {
+ struct dss_img img;
+ struct dss_rect src_rect;
+ struct dss_rect src_rect_mask;
+ struct dss_rect dst_rect;
u32 transform;
s32 blending;
u32 glb_alpha;
@@ -145,7 +145,7 @@ typedef struct drm_dss_layer {
s32 chn_idx;
u32 need_cap;
s32 acquire_fence;
-} drm_dss_layer_t;
+};
/**/
@@ -1160,17 +1160,17 @@ enum dss_rdma_idx {
#define AIF_MODULE_CLK_SEL (0x0A04)
#define AIF_MODULE_CLK_EN (0x0A08)
-typedef struct dss_aif {
+struct dss_aif {
u32 aif_ch_ctl;
u32 aif_ch_ctl_add;
-} dss_aif_t;
+};
-typedef struct dss_aif_bw {
+struct dss_aif_bw {
u64 bw;
u8 chn_idx;
s8 axi_sel;
u8 is_used;
-} dss_aif_bw_t;
+};
/*
* MIF
@@ -1212,13 +1212,13 @@ typedef struct dss_aif_bw {
#define LITTLE_LAYER_BUF_SIZE (256 * 1024)
#define MIF_STRIDE_UNIT (4 * 1024)
-typedef struct dss_mif {
+struct dss_mif {
u32 mif_ctrl1;
u32 mif_ctrl2;
u32 mif_ctrl3;
u32 mif_ctrl4;
u32 mif_ctrl5;
-} dss_mif_t;
+};
/*
* stretch blt, linear/tile, rotation, pixel format
@@ -1317,7 +1317,7 @@ enum dss_mmu_tlb_tag_org {
#define SMMU_SID_NUM (64)
-typedef struct dss_smmu {
+struct dss_smmu {
u32 smmu_scr;
u32 smmu_memctrl;
u32 smmu_lp_ctrl;
@@ -1375,7 +1375,7 @@ typedef struct dss_smmu {
u32 smmu_offset_addr_s;
u8 smmu_smrx_ns_used[DSS_CHN_MAX_DEFINE];
-} dss_smmu_t;
+};
/*
* RDMA
@@ -1455,7 +1455,7 @@ typedef struct dss_smmu {
#define DFC_DITHER_ENABLE (0x0020)
#define DFC_PADDING_CTL(0x0024)
-typedef struct dss_dfc {
+struct dss_dfc {
u32 disp_size;
u32 pix_in_num;
u32 disp_fmt;
@@ -1465,7 +1465,7 @@ typedef struct dss_dfc {
u32 icg_module;
u32 dither_enable;
u32 padding_ctl;
-} dss_dfc_t;
+};
/*
* SCF
@@ -1514,7 +1514,7 @@ typedef struct dss_dfc {
#define SCF_EDGE_FACTOR (3)
#define ARSR2P_INC_FACTOR (65536)
-typedef struct dss_scl {
+struct dss_scl {
u32 en_hscl_str;
u32 en_vscl_str;
u32 h_v_order;
@@ -1528,7 +1528,7 @@ typedef struct dss_scl {
u32 en_mmp;
u32 scf_ch_core_gt;
u32 fmt;
-} dss_scl_t;
+};
enum scl_coef_lut_idx {
SCL_COEF_NONE_IDX = -1,
@@ -1585,7 +1585,7 @@ enum scl_coef_lut_idx {
#define ARSR2P_LUT_COEFUV_V_OFFSET (0x0600)
#define ARSR2P_LUT_COEFUV_H_OFFSET (0x0700)
-typedef struct dss_arsr2p_effect {
+struct dss_arsr2p_effect {
u32 skin_thres_y;
u32 skin_thres_u;
u32 skin_thres_v;
@@ -1605,9 +1605,9 @@ typedef struct dss_arsr2p_effect {
u32 sharp_cfg9;
u32 texturw_analysts;
u32 intplshootctrl;
-} dss_arsr2p_effect_t;
+};
-typedef struct dss_arsr2p {
+struct dss_arsr2p {
u32 arsr_input_width_height;
u32 arsr_output_width_height;
u32 ihleft;
@@ -1618,11 +1618,11 @@ typedef struct dss_arsr2p {
u32 ivinc;
u32 offset;
u32 mode;
- dss_arsr2p_effect_t arsr2p_effect;
+ struct dss_arsr2p_effect arsr2p_effect;
u32 ihleft1;
u32 ihright1;
u32 ivbottom1;
-} dss_arsr2p_t;
+};
/*
* POST_CLIP v g
@@ -1632,12 +1632
[PATCH 22/49] staging: hikey9xx/gpu: cleanup encoder attach logic
Place both adv7535 and panel logic at the same routine,
cleaning up things a little bit and fixing the includes.
Signed-off-by: Mauro Carvalho Chehab
---
.../hikey9xx/gpu/kirin9xx_dw_drm_dsi.c| 58 ++-
1 file changed, 31 insertions(+), 27 deletions(-)
diff --git a/drivers/staging/hikey9xx/gpu/kirin9xx_dw_drm_dsi.c
b/drivers/staging/hikey9xx/gpu/kirin9xx_dw_drm_dsi.c
index cba81ee2639d..e904943d9f9e 100644
--- a/drivers/staging/hikey9xx/gpu/kirin9xx_dw_drm_dsi.c
+++ b/drivers/staging/hikey9xx/gpu/kirin9xx_dw_drm_dsi.c
@@ -25,7 +25,8 @@
#include
#include
#include
-#include
+#include
+#include
#include
#include
#include
@@ -1483,17 +1484,31 @@ static const struct drm_encoder_funcs dw_encoder_funcs
= {
static int dw_drm_encoder_init(struct device *dev,
struct drm_device *drm_dev,
- struct drm_encoder *encoder)
+ struct drm_encoder *encoder,
+ struct drm_bridge *bridge)
{
int ret;
- u32 crtc_mask = drm_of_find_possible_crtcs(drm_dev, dev->of_node);
+ u32 crtc_mask;
+ dev_info(dev, "%s:\n", __func__);
+
+ /* Link drm_bridge to encoder */
+ if (!bridge) {
+ DRM_INFO("no dsi bridge to attach the encoder\n");
+ return 0;
+ }
+
+ crtc_mask = drm_of_find_possible_crtcs(drm_dev, dev->of_node);
if (!crtc_mask) {
DRM_ERROR("failed to find crtc mask\n");
return -EINVAL;
}
+ dev_info(dev, "Initializing CRTC encoder: %d\n",
+crtc_mask);
+
encoder->possible_crtcs = crtc_mask;
+ encoder->possible_clones = 0;
ret = drm_encoder_init(drm_dev, encoder, &dw_encoder_funcs,
DRM_MODE_ENCODER_DSI, NULL);
if (ret) {
@@ -1503,7 +1518,14 @@ static int dw_drm_encoder_init(struct device *dev,
drm_encoder_helper_add(encoder, &dw_encoder_helper_funcs);
- return 0;
+ /* associate the bridge to dsi encoder */
+ ret = drm_bridge_attach(encoder, bridge, NULL, 0);
+ if (ret) {
+ DRM_ERROR("failed to attach external bridge\n");
+ drm_encoder_cleanup(encoder);
+ }
+
+ return ret;
}
static int dsi_host_attach(struct mipi_dsi_host *host,
@@ -1677,22 +1699,6 @@ static int dsi_host_init(struct device *dev, struct
dw_dsi *dsi)
return 0;
}
-static int dsi_bridge_init(struct drm_device *dev, struct dw_dsi *dsi)
-{
- struct drm_encoder *encoder = &dsi->encoder;
- struct drm_bridge *bridge = dsi->bridge;
- int ret;
-
- /* associate the bridge to dsi encoder */
- ret = drm_bridge_attach(encoder, bridge, NULL, 0);
- if (ret) {
- DRM_ERROR("failed to attach external bridge\n");
- return ret;
- }
-
- return 0;
-}
-
static int dsi_connector_get_modes(struct drm_connector *connector)
{
struct dw_dsi *dsi = connector_to_dsi(connector);
@@ -1766,6 +1772,7 @@ static int dsi_connector_init(struct drm_device *dev,
struct dw_dsi *dsi)
if (ret)
return ret;
+ dev_info(dev->dev, "Attaching CRTC encoder\n");
ret = drm_connector_attach_encoder(connector, encoder);
if (ret)
return ret;
@@ -1784,16 +1791,13 @@ static int dsi_bind(struct device *dev, struct device
*master, void *data)
struct drm_device *drm_dev = data;
int ret;
- ret = dw_drm_encoder_init(dev, drm_dev, &dsi->encoder);
+ DRM_INFO("dsi_bind\n");
+
+ ret = dw_drm_encoder_init(dev, drm_dev, &dsi->encoder,
+ dsi->bridge);
if (ret)
return ret;
- if (dsi->bridge) {
- ret = dsi_bridge_init(drm_dev, dsi);
- if (ret)
- return ret;
- }
-
if (dsi->panel) {
ret = dsi_connector_init(drm_dev, dsi);
if (ret)
--
2.26.2
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 10/49] staging: hikey9xx/gpu: add debug prints for this driver
From: Xiubin Zhang
Add some debug prints on adv7535 and kirin_drm_drv.
Signed-off-by: Xiubin Zhang
Signed-off-by: Mauro Carvalho Chehab
---
drivers/staging/hikey9xx/gpu/hdmi/adv7535.c | 40 ++--
drivers/staging/hikey9xx/gpu/kirin_drm_drv.c | 2 +-
2 files changed, 37 insertions(+), 5 deletions(-)
diff --git a/drivers/staging/hikey9xx/gpu/hdmi/adv7535.c
b/drivers/staging/hikey9xx/gpu/hdmi/adv7535.c
index a21a8f8b917e..04c1e7b9ca8e 100644
--- a/drivers/staging/hikey9xx/gpu/hdmi/adv7535.c
+++ b/drivers/staging/hikey9xx/gpu/hdmi/adv7535.c
@@ -28,7 +28,8 @@
#include "adv7535.h"
-#define HPD_ENABLE 1
+//#define HPD_ENABLE 1
+#define HPD_ENABLE 0
//#define TEST_COLORBAR_DISPLAY
#ifdef CONFIG_HDMI_ADV7511_AUDIO
extern int adv7511_audio_init(struct device *dev);
@@ -785,19 +786,25 @@ adv7511_detect(struct adv7511 *adv7511,
{
enum drm_connector_status status;
unsigned int val;
+ unsigned int time = 0;
#if HPD_ENABLE
bool hpd;
#endif
int ret;
ret = regmap_read(adv7511->regmap, ADV7511_REG_STATUS, &val);
- if (ret < 0)
+ if (ret < 0) {
+ DRM_ERROR("regmap_read fail, ret = %d \n", ret);
return connector_status_disconnected;
+ }
- if (val & ADV7511_STATUS_HPD)
+ if (val & ADV7511_STATUS_HPD) {
+ DRM_INFO("connected : regmap_read val = 0x%x \n", val);
status = connector_status_connected;
- else
+ } else {
+ DRM_INFO("disconnected : regmap_read val = 0x%x \n", val);
status = connector_status_disconnected;
+ }
#if HPD_ENABLE
hpd = adv7511_hpd(adv7511);
@@ -820,7 +827,32 @@ adv7511_detect(struct adv7511 *adv7511,
}
#endif
+ if (status == connector_status_disconnected) {
+ do {
+ ret = regmap_read(adv7511->regmap, ADV7511_REG_STATUS,
&val);
+ if (ret < 0) {
+ DRM_ERROR("regmap_read fail, ret = %d \n", ret);
+ return connector_status_disconnected;
+ }
+
+ if (val & ADV7511_STATUS_HPD) {
+ DRM_INFO("connected : regmap_read val = 0x%x
\n", val);
+ status = connector_status_connected;
+ } else {
+ DRM_INFO("disconnected : regmap_read val = 0x%x
\n", val);
+ status = connector_status_disconnected;
+ }
+ time ++;
+ mdelay(20);
+ } while (status == connector_status_disconnected && time < 10);
+ }
+
+ if (time >= 10)
+ DRM_ERROR("Read connector status timout, time = %d \n", time);
+
adv7511->status = status;
+
+ DRM_INFO("hdmi connector status = %d \n", status);
return status;
}
diff --git a/drivers/staging/hikey9xx/gpu/kirin_drm_drv.c
b/drivers/staging/hikey9xx/gpu/kirin_drm_drv.c
index 958aafa1a09c..ec1f668f2d21 100644
--- a/drivers/staging/hikey9xx/gpu/kirin_drm_drv.c
+++ b/drivers/staging/hikey9xx/gpu/kirin_drm_drv.c
@@ -144,7 +144,7 @@ static int kirin_drm_kms_init(struct drm_device *dev)
/* init kms poll for handling hpd */
drm_kms_helper_poll_init(dev);
-#if 0
+#if 1
/* force detection after connectors init */
(void)drm_helper_hpd_irq_event(dev);
#endif
--
2.26.2
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 14/49] staging: hikey9xx/gpu: get rid of kirin9xx_fbdev.c
We don't need to implement legacy fbdev support. Just use
the FB emulation instead.
Signed-off-by: Mauro Carvalho Chehab
---
.../staging/hikey9xx/gpu/kirin9xx_drm_drv.c | 9 +-
.../staging/hikey9xx/gpu/kirin9xx_drm_drv.h | 2 -
drivers/staging/hikey9xx/gpu/kirin9xx_fb.c| 94
drivers/staging/hikey9xx/gpu/kirin9xx_fbdev.c | 487 --
4 files changed, 1 insertion(+), 591 deletions(-)
delete mode 100644 drivers/staging/hikey9xx/gpu/kirin9xx_fb.c
delete mode 100644 drivers/staging/hikey9xx/gpu/kirin9xx_fbdev.c
diff --git a/drivers/staging/hikey9xx/gpu/kirin9xx_drm_drv.c
b/drivers/staging/hikey9xx/gpu/kirin9xx_drm_drv.c
index ec1f668f2d21..f5b05b26bc18 100644
--- a/drivers/staging/hikey9xx/gpu/kirin9xx_drm_drv.c
+++ b/drivers/staging/hikey9xx/gpu/kirin9xx_drm_drv.c
@@ -39,10 +39,8 @@ static int kirin_drm_kms_cleanup(struct drm_device *dev)
{
struct kirin_drm_private *priv = dev->dev_private;
- if (priv->fbdev) {
- kirin_drm_fbdev_fini(dev);
+ if (priv->fbdev)
priv->fbdev = NULL;
- }
drm_kms_helper_poll_fini(dev);
drm_vblank_cleanup(dev);
@@ -75,8 +73,6 @@ static void kirin_fbdev_output_poll_changed(struct drm_device
*dev)
#else
if (priv->fbdev)
drm_fb_helper_hotplug_event(priv->fbdev);
- else
- priv->fbdev = kirin_drm_fbdev_init(dev);
#endif
}
@@ -138,9 +134,6 @@ static int kirin_drm_kms_init(struct drm_device *dev)
/* reset all the states of crtc/plane/encoder/connector */
drm_mode_config_reset(dev);
- if (fbdev)
- priv->fbdev = kirin_drm_fbdev_init(dev);
-
/* init kms poll for handling hpd */
drm_kms_helper_poll_init(dev);
diff --git a/drivers/staging/hikey9xx/gpu/kirin9xx_drm_drv.h
b/drivers/staging/hikey9xx/gpu/kirin9xx_drm_drv.h
index 697955a8e96c..18a7478fee10 100644
--- a/drivers/staging/hikey9xx/gpu/kirin9xx_drm_drv.h
+++ b/drivers/staging/hikey9xx/gpu/kirin9xx_drm_drv.h
@@ -57,7 +57,5 @@ extern void dsi_set_output_client(struct drm_device *dev);
struct drm_framebuffer *kirin_framebuffer_init(struct drm_device *dev,
struct drm_mode_fb_cmd2 *mode_cmd);
-struct drm_fb_helper *kirin_drm_fbdev_init(struct drm_device *dev);
-void kirin_drm_fbdev_fini(struct drm_device *dev);
#endif /* __KIRIN_DRM_DRV_H__ */
diff --git a/drivers/staging/hikey9xx/gpu/kirin9xx_fb.c
b/drivers/staging/hikey9xx/gpu/kirin9xx_fb.c
deleted file mode 100644
index 1cb84278f507..
--- a/drivers/staging/hikey9xx/gpu/kirin9xx_fb.c
+++ /dev/null
@@ -1,94 +0,0 @@
-/*
- * Copyright (C) 2013 Red Hat
- * Author: Rob Clark
- *
- * This program is free software; you can redistribute it and/or modify it
- * under the terms of the GNU General Public License version 2 as published by
- * the Free Software Foundation.
- *
- * This program is distributed in the hope that it will be useful, but WITHOUT
- * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
- * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
- * more details.
- *
- * You should have received a copy of the GNU General Public License along with
- * this program. If not, see
[PATCH 04/49] staging: hikey9xx/gpu: resolve the performance issue by interrupt mechanism
From: Liwei Cai
There is an error at wait for vactive end flags, waiting
vactive flag in 1ms maybe too rough, but it's not good to
control the waiting grain size, there is no way to get the
waiting unit, so the interrupt mechanism is the best way to
solve this problem.
Each frame would report hardware interrupt, implement the interrupt
service to get vactive end interrupt, and fb_post return to tell
gpu render next framebuffer.
Signed-off-by: Wanchun Zheng
Signed-off-by: Liwei Cai
Signed-off-by: John Stultz
Signed-off-by: Mauro Carvalho Chehab
---
drivers/staging/hikey9xx/gpu/kirin_dpe_reg.h | 4 +-
.../hikey9xx/gpu/kirin_drm_dpe_utils.c| 3 +-
drivers/staging/hikey9xx/gpu/kirin_drm_dss.c | 14 ++---
.../hikey9xx/gpu/kirin_drm_overlay_utils.c| 56 ---
4 files changed, 20 insertions(+), 57 deletions(-)
diff --git a/drivers/staging/hikey9xx/gpu/kirin_dpe_reg.h
b/drivers/staging/hikey9xx/gpu/kirin_dpe_reg.h
index 9fad9ef942bd..adaa71f6dcd5 100644
--- a/drivers/staging/hikey9xx/gpu/kirin_dpe_reg.h
+++ b/drivers/staging/hikey9xx/gpu/kirin_dpe_reg.h
@@ -2948,8 +2948,8 @@ struct dss_hw_ctx {
bool power_on;
int irq;
- wait_queue_head_t vactive0_start_wq;
- u32 vactive0_start_flag;
+ wait_queue_head_t vactive0_end_wq;
+ u32 vactive0_end_flag;
ktime_t vsync_timestamp;
ktime_t vsync_timestamp_prev;
diff --git a/drivers/staging/hikey9xx/gpu/kirin_drm_dpe_utils.c
b/drivers/staging/hikey9xx/gpu/kirin_drm_dpe_utils.c
index 2d6809b72b42..2a13bbd772b7 100644
--- a/drivers/staging/hikey9xx/gpu/kirin_drm_dpe_utils.c
+++ b/drivers/staging/hikey9xx/gpu/kirin_drm_dpe_utils.c
@@ -554,8 +554,7 @@ void dpe_interrupt_unmask(struct dss_crtc *acrtc)
outp32(dss_base + GLB_CPU_PDP_INT_MSK, unmask);
unmask = ~0;
- unmask &= ~(BIT_VSYNC | BIT_VACTIVE0_START
- | BIT_VACTIVE0_END | BIT_FRM_END | BIT_LDI_UNFLOW);
+ unmask &= ~(BIT_VSYNC | BIT_VACTIVE0_END | BIT_LDI_UNFLOW);
outp32(dss_base + DSS_LDI0_OFFSET + LDI_CPU_ITF_INT_MSK, unmask);
}
diff --git a/drivers/staging/hikey9xx/gpu/kirin_drm_dss.c
b/drivers/staging/hikey9xx/gpu/kirin_drm_dss.c
index 62ac1a0648cc..64d0b1979bf5 100644
--- a/drivers/staging/hikey9xx/gpu/kirin_drm_dss.c
+++ b/drivers/staging/hikey9xx/gpu/kirin_drm_dss.c
@@ -167,8 +167,8 @@ static int dss_power_up(struct dss_crtc *acrtc)
dss_inner_clk_common_enable(acrtc);
dpe_interrupt_mask(acrtc);
dpe_interrupt_clear(acrtc);
- //dpe_irq_enable(acrtc);
- //dpe_interrupt_unmask(acrtc);
+ dpe_irq_enable(acrtc);
+ dpe_interrupt_unmask(acrtc);
ctx->power_on = true;
return 0;
@@ -237,9 +237,9 @@ static irqreturn_t dss_irq_handler(int irq, void *data)
isr_s2 &= ~(inp32(dss_base + DSS_LDI0_OFFSET + LDI_CPU_ITF_INT_MSK));
isr_s2_dpp &= ~(inp32(dss_base + DSS_DPP_OFFSET + DPP_INT_MSK));
- if (isr_s2 & BIT_VACTIVE0_START) {
- ctx->vactive0_start_flag++;
- wake_up_interruptible_all(&ctx->vactive0_start_wq);
+ if (isr_s2 & BIT_VACTIVE0_END) {
+ ctx->vactive0_end_flag++;
+ wake_up_interruptible_all(&ctx->vactive0_end_wq);
}
if (isr_s2 & BIT_VSYNC) {
@@ -637,8 +637,8 @@ static int dss_drm_init(struct drm_device *dev)
ctx->screen_size = 0;
ctx->smem_start = 0;
- ctx->vactive0_start_flag = 0;
- init_waitqueue_head(&ctx->vactive0_start_wq);
+ ctx->vactive0_end_flag = 0;
+ init_waitqueue_head(&ctx->vactive0_end_wq);
/*
* plane init
diff --git a/drivers/staging/hikey9xx/gpu/kirin_drm_overlay_utils.c
b/drivers/staging/hikey9xx/gpu/kirin_drm_overlay_utils.c
index 917e1a7d7bdf..28778b15512a 100644
--- a/drivers/staging/hikey9xx/gpu/kirin_drm_overlay_utils.c
+++ b/drivers/staging/hikey9xx/gpu/kirin_drm_overlay_utils.c
@@ -30,8 +30,6 @@
#define DSS_CHN_MAX_DEFINE (DSS_COPYBIT_MAX)
-#define TIME_OUT (16)
-
static int mid_array[DSS_CHN_MAX_DEFINE] = {0xb, 0xa, 0x9, 0x8, 0x7, 0x6, 0x5,
0x4, 0x2, 0x1, 0x3, 0x0};
/*
@@ -1065,49 +1063,17 @@ void hisi_dss_unflow_handler(struct dss_hw_ctx *ctx,
bool unmask)
outp32(dss_base + DSS_LDI0_OFFSET + LDI_CPU_ITF_INT_MSK, tmp);
}
-void hisi_dss_wait_for_complete(struct dss_hw_ctx *ctx, bool need_clear)
-{
- void __iomem *dss_base;
- u32 tmp = 0;
- u32 isr_s2 = 0;
-
- if (!ctx) {
- DRM_ERROR("ctx is NULL!\n");
- return;
- }
-
- dss_base = ctx->base;
-
- do {
- isr_s2 = inp32(dss_base + DSS_LDI0_OFFSET + LDI_CPU_ITF_INTS);
- if (isr_s2 & BIT_VACTIVE0_END) {
- DRM_DEBUG("hisi_dss_wait_for_complete exit! temp =
%d\n", tmp);
- if (need_clear)
- outp32(dss_base + DSS_LDI0_OFFSET +
LDI_CPU_ITF_INTS, BIT_VACTIVE0_END);
- break
[PATCH 19/49] staging: hikey9xx/gpu: add a copy of set_reg() function there
This function has a too generic name to export it as a
symbol. Also, we should likely use some other macro instead.
So, for now, just copy it into the Kirin9xx dsi module, in order
for the driver to build.
Signed-off-by: Mauro Carvalho Chehab
---
.../staging/hikey9xx/gpu/kirin9xx_dw_drm_dsi.c | 17 -
1 file changed, 16 insertions(+), 1 deletion(-)
diff --git a/drivers/staging/hikey9xx/gpu/kirin9xx_dw_drm_dsi.c
b/drivers/staging/hikey9xx/gpu/kirin9xx_dw_drm_dsi.c
index cfb6bfd1c338..cba81ee2639d 100644
--- a/drivers/staging/hikey9xx/gpu/kirin9xx_dw_drm_dsi.c
+++ b/drivers/staging/hikey9xx/gpu/kirin9xx_dw_drm_dsi.c
@@ -37,7 +37,6 @@
#else
#include "kirin960_dpe_reg.h"
#endif
-#include "kirin9xx_drm_dpe_utils.h"
#include "kirin9xx_drm_drv.h"
#if defined (CONFIG_DRM_HISI_KIRIN970)
@@ -270,6 +269,22 @@ static const struct dsi_phy_range dphy_range_info[] = {
{ 100, 150, 0,0 }
};
+/*
+ * Except for debug, this is identical to the one defined at
+ * kirin9xx_drm_dpe_utils.h.
+ */
+static void set_reg(char __iomem *addr, uint32_t val, uint8_t bw,
+ uint8_t bs)
+{
+ u32 mask = (1UL << bw) - 1UL;
+ u32 tmp = 0;
+
+ tmp = inp32(addr);
+ tmp &= ~(mask << bs);
+
+ outp32(addr, tmp | ((val & mask) << bs));
+}
+
void dsi_set_output_client(struct drm_device *dev)
{
struct drm_connector_list_iter conn_iter;
--
2.26.2
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 12/49] staging: hikey9xx/gpu: get rid of adv7535 fork
The OOT had a fork of adv7535 with some changes for it to
work with a failing EDID retrival I/O.
Get rid of it, as we'll be using the upstream driver.
Signed-off-by: Mauro Carvalho Chehab
---
drivers/staging/hikey9xx/gpu/hdmi/adv7535.c | 1678 -
drivers/staging/hikey9xx/gpu/hdmi/adv7535.h | 351
.../staging/hikey9xx/gpu/hdmi/adv7535_audio.c | 313 ---
3 files changed, 2342 deletions(-)
delete mode 100644 drivers/staging/hikey9xx/gpu/hdmi/adv7535.c
delete mode 100644 drivers/staging/hikey9xx/gpu/hdmi/adv7535.h
delete mode 100644 drivers/staging/hikey9xx/gpu/hdmi/adv7535_audio.c
diff --git a/drivers/staging/hikey9xx/gpu/hdmi/adv7535.c
b/drivers/staging/hikey9xx/gpu/hdmi/adv7535.c
deleted file mode 100644
index 04c1e7b9ca8e..
--- a/drivers/staging/hikey9xx/gpu/hdmi/adv7535.c
+++ /dev/null
@@ -1,1678 +0,0 @@
-/*
- * Analog Devices ADV7511 HDMI transmitter driver
- *
- * Copyright 2012 Analog Devices Inc.
- *
- * Licensed under the GPL-2.
- */
-
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-
-#include
-#include
-#include
-
-#include "adv7535.h"
-
-//#define HPD_ENABLE 1
-#define HPD_ENABLE 0
-//#define TEST_COLORBAR_DISPLAY
-#ifdef CONFIG_HDMI_ADV7511_AUDIO
-extern int adv7511_audio_init(struct device *dev);
-#endif
-static struct adv7511 *encoder_to_adv7511(struct drm_encoder *encoder)
-{
- return to_encoder_slave(encoder)->slave_priv;
-}
-
-/* ADI recommended values for proper operation. */
-static const struct reg_sequence adv7511_fixed_registers[] = {
- { 0x98, 0x03 },
- { 0x9a, 0xe0 },
- { 0x9c, 0x30 },
- { 0x9d, 0x61 },
- { 0xa2, 0xa4 },
- { 0xa3, 0xa4 },
- { 0xe0, 0xd0 },
- { 0xf9, 0x00 },
- { 0x55, 0x02 },
-};
-
-/* ADI recommended values for proper operation. */
-static const struct reg_sequence adv7533_fixed_registers[] = {
- { 0x16, 0x20 },
- { 0x9a, 0xe0 },
- { 0xba, 0x70 },
- { 0xde, 0x82 },
- { 0xe4, 0x40 },
- { 0xe5, 0x80 },
-};
-
-static const struct reg_sequence adv7533_cec_fixed_registers[] = {
- { 0x15, 0xd0 },
- { 0x17, 0xd0 },
- { 0x24, 0x20 },
- { 0x57, 0x11 },
- { 0x05, 0xc8 },
-};
-
-/*
-
- * Register access
- */
-
-static const uint8_t adv7511_register_defaults[] = {
- 0x12, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, /* 00 */
- 0x00, 0x00, 0x01, 0x0e, 0xbc, 0x18, 0x01, 0x13,
- 0x25, 0x37, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, /* 10 */
- 0x46, 0x62, 0x04, 0xa8, 0x00, 0x00, 0x1c, 0x84,
- 0x1c, 0xbf, 0x04, 0xa8, 0x1e, 0x70, 0x02, 0x1e, /* 20 */
- 0x00, 0x00, 0x04, 0xa8, 0x08, 0x12, 0x1b, 0xac,
- 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, /* 30 */
- 0x00, 0x00, 0x00, 0x80, 0x00, 0x00, 0x00, 0xb0,
- 0x00, 0x50, 0x90, 0x7e, 0x79, 0x70, 0x00, 0x00, /* 40 */
- 0x00, 0xa8, 0x80, 0x00, 0x00, 0x00, 0x00, 0x00,
- 0x00, 0x00, 0x02, 0x0d, 0x00, 0x00, 0x00, 0x00, /* 50 */
- 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
- 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, /* 60 */
- 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
- 0x01, 0x0a, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, /* 70 */
- 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
- 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, /* 80 */
- 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
- 0x00, 0x00, 0x00, 0x00, 0xc0, 0x00, 0x00, 0x00, /* 90 */
- 0x0b, 0x02, 0x00, 0x18, 0x5a, 0x60, 0x00, 0x00,
- 0x00, 0x00, 0x80, 0x80, 0x08, 0x04, 0x00, 0x00, /* a0 */
- 0x00, 0x00, 0x00, 0x40, 0x00, 0x00, 0x40, 0x14,
- 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, /* b0 */
- 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
- 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, /* c0 */
- 0x00, 0x03, 0x00, 0x00, 0x02, 0x00, 0x01, 0x04,
- 0x30, 0xff, 0x80, 0x80, 0x80, 0x00, 0x00, 0x00, /* d0 */
- 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x10, 0x01,
- 0x80, 0x75, 0x00, 0x00, 0x60, 0x00, 0x00, 0x00, /* e0 */
- 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
- 0x00, 0x00, 0x00, 0x00, 0x00, 0x75, 0x11, 0x00, /* f0 */
- 0x00, 0x7c, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
-};
-
-static bool adv7511_register_volatile(struct device *dev, unsigned int reg)
-{
- switch (reg) {
- case ADV7511_REG_CHIP_REVISION:
- case ADV7511_REG_SPDIF_FREQ:
- case ADV7511_REG_CTS_AUTOMATIC1:
- case ADV7511_REG_CTS_AUTOMATIC2:
- case ADV7511_REG_VIC_DETECTED:
- case ADV7511_REG_VIC_SEND:
- case ADV7511_REG_AUX_VIC_DETECTED:
- case ADV7511_REG_STATUS:
- case ADV7511_REG_GC(1):
- case ADV7511_REG_INT(0):
- case ADV7511_REG_INT(1):
- case ADV7511_REG_PLL_STATUS:
- case AD
[PATCH 06/49] staging: hikey9xx/gpu: Solve SR Cannot Display Problems.
From: Xiubin Zhang
Add suspend and resume interface to solve SR Cannot Display Problems.
Signed-off-by: Xiubin Zhang
Signed-off-by: Mauro Carvalho Chehab
---
drivers/staging/hikey9xx/gpu/dw_drm_dsi.c | 32 +++
drivers/staging/hikey9xx/gpu/hdmi/adv7535.c | 14 +-
.../staging/hikey9xx/gpu/kirin970_dpe_reg.h | 46 ++--
drivers/staging/hikey9xx/gpu/kirin_dpe_reg.h | 6 +
.../hikey9xx/gpu/kirin_drm_dpe_utils.c| 204 +-
.../hikey9xx/gpu/kirin_drm_dpe_utils.h| 8 +
drivers/staging/hikey9xx/gpu/kirin_drm_drv.c | 32 +++
drivers/staging/hikey9xx/gpu/kirin_drm_drv.h | 2 +
drivers/staging/hikey9xx/gpu/kirin_drm_dss.c | 53 -
.../hikey9xx/gpu/kirin_drm_overlay_utils.c| 61 --
drivers/staging/hikey9xx/gpu/kirin_fbdev.c| 3 +-
11 files changed, 401 insertions(+), 60 deletions(-)
diff --git a/drivers/staging/hikey9xx/gpu/dw_drm_dsi.c
b/drivers/staging/hikey9xx/gpu/dw_drm_dsi.c
index f1376ed01dce..e69f4a9bca58 100644
--- a/drivers/staging/hikey9xx/gpu/dw_drm_dsi.c
+++ b/drivers/staging/hikey9xx/gpu/dw_drm_dsi.c
@@ -2063,6 +2063,36 @@ static int dsi_remove(struct platform_device *pdev)
return 0;
}
+static int dsi_suspend(struct platform_device *pdev, pm_message_t state)
+{
+ struct device *dev = &pdev->dev;
+ struct dsi_data *ddata = dev_get_drvdata(dev);
+ struct dw_dsi *dsi = &ddata->dsi;
+
+ DRM_INFO("+. pdev->name is %s, pm_message is %d \n", pdev->name,
state.event);
+
+ dsi_encoder_disable(&dsi->encoder);
+
+ DRM_INFO("-. \n");
+
+ return 0;
+}
+
+static int dsi_resume(struct platform_device *pdev)
+{
+ struct device *dev = &pdev->dev;
+ struct dsi_data *ddata = dev_get_drvdata(dev);
+ struct dw_dsi *dsi = &ddata->dsi;
+
+ DRM_INFO("+. pdev->name is %s \n", pdev->name);
+
+ dsi_encoder_enable(&dsi->encoder);
+
+ DRM_INFO("-. \n");
+
+ return 0;
+}
+
static const struct of_device_id dsi_of_match[] = {
{.compatible = "hisilicon,hi3660-dsi"},
{.compatible = "hisilicon,kirin970-dsi"},
@@ -2073,6 +2103,8 @@ MODULE_DEVICE_TABLE(of, dsi_of_match);
static struct platform_driver dsi_driver = {
.probe = dsi_probe,
.remove = dsi_remove,
+ .suspend = dsi_suspend,
+ .resume = dsi_resume,
.driver = {
.name = "dw-dsi",
.of_match_table = dsi_of_match,
diff --git a/drivers/staging/hikey9xx/gpu/hdmi/adv7535.c
b/drivers/staging/hikey9xx/gpu/hdmi/adv7535.c
index 818b4b65334c..3dd6059ea603 100644
--- a/drivers/staging/hikey9xx/gpu/hdmi/adv7535.c
+++ b/drivers/staging/hikey9xx/gpu/hdmi/adv7535.c
@@ -1231,12 +1231,10 @@ static int adv7533_init_regulators(struct adv7511
*adv75xx, struct device *dev)
if (IS_ERR(adv75xx->v1p2)) {
ret = PTR_ERR(adv75xx->v1p2);
dev_err(dev, "failed to get v1p2 regulator %d\n", ret);
- //return ret;
+ return ret;
}
ret = regulator_set_voltage(adv75xx->vdd, 180, 180);
- //ret = regulator_set_voltage(adv75xx->vdd, 150, 150);
- //ret = regulator_set_voltage(adv75xx->vdd, 200, 200);
if (ret) {
dev_err(dev, "failed to set avdd voltage %d\n", ret);
return ret;
@@ -1244,11 +1242,11 @@ static int adv7533_init_regulators(struct adv7511
*adv75xx, struct device *dev)
DRM_INFO(" adv75xx->vdd = %d \n", regulator_get_voltage(adv75xx->vdd));
- //ret = regulator_set_voltage(adv75xx->v1p2, 120, 120);
+ /*ret = regulator_set_voltage(adv75xx->v1p2, 120, 120);
if (ret) {
dev_err(dev, "failed to set v1p2 voltage %d\n", ret);
- //return ret;
- }
+ return ret;
+ }*/
/* keep the regulators always on */
ret = regulator_enable(adv75xx->vdd);
@@ -1257,11 +1255,11 @@ static int adv7533_init_regulators(struct adv7511
*adv75xx, struct device *dev)
return ret;
}
- //ret = regulator_enable(adv75xx->v1p2);
+ /*ret = regulator_enable(adv75xx->v1p2);
if (ret) {
dev_err(dev, "failed to enable v1p2 %d\n", ret);
//return ret;
- }
+ }*/
return 0;
}
diff --git a/drivers/staging/hikey9xx/gpu/kirin970_dpe_reg.h
b/drivers/staging/hikey9xx/gpu/kirin970_dpe_reg.h
index 6e7e5dc0a20a..867266073bc0 100644
--- a/drivers/staging/hikey9xx/gpu/kirin970_dpe_reg.h
+++ b/drivers/staging/hikey9xx/gpu/kirin970_dpe_reg.h
@@ -108,32 +108,32 @@ enum dss_ovl_idx {
#define DSS_WCH_MAX (2)
typedef struct dss_img {
- uint32_t format;
- uint32_t width;
- uint32_t height;
- uint32_t bpp; /* bytes per pixel */
- uint32_t buf_size;
- uint32_t stride;
- uint32_t stride_plane1;
- uint32_t stride_plane2;
+ u32 format;
+ u32 width;
+ u32 height;
+ u32 bpp
[PATCH 34/49] staging: hikey9xx/gpu: add support for enable/disable ldo3 regulator
This is needed for the DRM to work. Ok, right now, this is
enabled on default fastboot logic, but, as soon as we enable
the proper SPMI driver, such code is needed.
Signed-off-by: Mauro Carvalho Chehab
---
drivers/staging/hikey9xx/gpu/kirin970_dpe_reg.h | 4 +---
drivers/staging/hikey9xx/gpu/kirin9xx_drm_dpe_utils.c | 6 +++---
drivers/staging/hikey9xx/gpu/kirin9xx_drm_dss.c | 8
drivers/staging/hikey9xx/gpu/kirin9xx_fb_panel.h | 4 +---
4 files changed, 5 insertions(+), 17 deletions(-)
diff --git a/drivers/staging/hikey9xx/gpu/kirin970_dpe_reg.h
b/drivers/staging/hikey9xx/gpu/kirin970_dpe_reg.h
index 9c1b62831733..0c6b6eb9dcab 100644
--- a/drivers/staging/hikey9xx/gpu/kirin970_dpe_reg.h
+++ b/drivers/staging/hikey9xx/gpu/kirin970_dpe_reg.h
@@ -41,9 +41,7 @@
#define FB_ACCEL_PLATFORM_TYPE_ASIC 0x2000 //ASIC
/* vcc name */
-#define REGULATOR_PDP_NAME "regulator_dsssubsys"
-#define REGULATOR_MMBUF"regulator_mmbuf"
-#define REGULATOR_MEDIA_NAME "regulator_media_subsys"
+#define REGULATOR_PDP_NAME "ldo3"
/***
**
diff --git a/drivers/staging/hikey9xx/gpu/kirin9xx_drm_dpe_utils.c
b/drivers/staging/hikey9xx/gpu/kirin9xx_drm_dpe_utils.c
index a15c335da026..3b8ff0bdd359 100644
--- a/drivers/staging/hikey9xx/gpu/kirin9xx_drm_dpe_utils.c
+++ b/drivers/staging/hikey9xx/gpu/kirin9xx_drm_dpe_utils.c
@@ -967,13 +967,13 @@ int dpe_regulator_enable(struct dss_hw_ctx *ctx)
{
int ret = 0;
- DRM_INFO("+. \n");
+ DRM_INFO("enabling DPE regulator\n");
if (NULL == ctx) {
DRM_ERROR("NULL ptr.\n");
return -EINVAL;
}
- //ret = regulator_enable(ctx->dpe_regulator);
+ ret = regulator_enable(ctx->dpe_regulator);
if (ret) {
DRM_ERROR(" dpe regulator_enable failed, error=%d!\n", ret);
return -EINVAL;
@@ -998,7 +998,7 @@ int dpe_regulator_disable(struct dss_hw_ctx *ctx)
dpe_set_common_clk_rate_on_pll0(ctx);
#endif
- //ret = regulator_disable(ctx->dpe_regulator);
+ ret = regulator_disable(ctx->dpe_regulator);
if (ret != 0) {
DRM_ERROR("dpe regulator_disable failed, error=%d!\n", ret);
return -EINVAL;
diff --git a/drivers/staging/hikey9xx/gpu/kirin9xx_drm_dss.c
b/drivers/staging/hikey9xx/gpu/kirin9xx_drm_dss.c
index 0844bf372ca8..fe5b371734fe 100644
--- a/drivers/staging/hikey9xx/gpu/kirin9xx_drm_dss.c
+++ b/drivers/staging/hikey9xx/gpu/kirin9xx_drm_dss.c
@@ -873,20 +873,12 @@ static int dss_dts_parse(struct platform_device *pdev,
struct dss_hw_ctx *ctx)
DRM_INFO("dss irq = %d. \n", ctx->irq);
-#ifndef DSS_POWER_UP_ON_UEFI
#if defined (CONFIG_DRM_HISI_KIRIN970)
ctx->dpe_regulator = devm_regulator_get(dev, REGULATOR_PDP_NAME);
if (!ctx->dpe_regulator) {
DRM_ERROR("failed to get dpe_regulator resource! ret=%d.\n",
ret);
return -ENXIO;
}
-
- ctx->mediacrg_regulator = devm_regulator_get(dev, REGULATOR_MEDIA_NAME);
- if (!ctx->mediacrg_regulator) {
- DRM_ERROR("failed to get mediacrg_regulator resource!
ret=%d.\n", ret);
- return -ENXIO;
- }
-#endif
#endif
ctx->dss_mmbuf_clk = devm_clk_get(dev, "clk_dss_axi_mm");
diff --git a/drivers/staging/hikey9xx/gpu/kirin9xx_fb_panel.h
b/drivers/staging/hikey9xx/gpu/kirin9xx_fb_panel.h
index 0f69af49a355..83e79a4350c1 100644
--- a/drivers/staging/hikey9xx/gpu/kirin9xx_fb_panel.h
+++ b/drivers/staging/hikey9xx/gpu/kirin9xx_fb_panel.h
@@ -38,9 +38,7 @@
#define DEV_NAME_LCD_BKL "lcd_backlight0"
/* vcc name */
-#define REGULATOR_PDP_NAME "regulator_dsssubsys"
-#define REGULATOR_MMBUF"regulator_mmbuf"
-#define REGULATOR_MEDIA_NAME "regulator_media_subsys"
+#define REGULATOR_PDP_NAME "ldo3"
/* irq name */
--
2.26.2
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 43/49] staging: hikey9xx/gpu: get rid of DRM_HISI_KIRIN970
There are lots of ifdefs checking if the SoC version is
960 or 970. Replace them all by runtime definitions.
With that, the same DRM driver should work with both versions.
The behavior will dynamically change depending on the
OF compatible strings.
Signed-off-by: Mauro Carvalho Chehab
---
drivers/staging/hikey9xx/gpu/Makefile | 1 +
drivers/staging/hikey9xx/gpu/kirin960_defs.c | 378 ++
.../staging/hikey9xx/gpu/kirin960_dpe_reg.h | 21 -
drivers/staging/hikey9xx/gpu/kirin970_defs.c | 381 ++
.../staging/hikey9xx/gpu/kirin970_dpe_reg.h | 23 -
.../hikey9xx/gpu}/kirin9xx_dpe.h | 30 +-
.../hikey9xx/gpu/kirin9xx_drm_dpe_utils.c | 29 +-
.../hikey9xx/gpu/kirin9xx_drm_dpe_utils.h | 21 +
.../staging/hikey9xx/gpu/kirin9xx_drm_drv.c | 4 +-
.../staging/hikey9xx/gpu/kirin9xx_drm_drv.h | 3 +-
.../staging/hikey9xx/gpu/kirin9xx_drm_dss.c | 174 ++---
.../hikey9xx/gpu/kirin9xx_drm_overlay_utils.c | 697 +-
.../hikey9xx/gpu/kirin9xx_dw_drm_dsi.c| 275 +++
drivers/staging/hikey9xx/gpu/kirin9xx_pwm.c | 6 +-
14 files changed, 1074 insertions(+), 969 deletions(-)
create mode 100644 drivers/staging/hikey9xx/gpu/kirin960_defs.c
create mode 100644 drivers/staging/hikey9xx/gpu/kirin970_defs.c
rename drivers/{gpu/drm/hisilicon/kirin =>
staging/hikey9xx/gpu}/kirin9xx_dpe.h (99%)
diff --git a/drivers/staging/hikey9xx/gpu/Makefile
b/drivers/staging/hikey9xx/gpu/Makefile
index 9df7894ccb42..9177c3006b14 100644
--- a/drivers/staging/hikey9xx/gpu/Makefile
+++ b/drivers/staging/hikey9xx/gpu/Makefile
@@ -2,6 +2,7 @@
kirin9xx-drm-y := kirin9xx_drm_drv.o \
kirin9xx_drm_dss.o \
kirin9xx_drm_dpe_utils.o \
+ kirin970_defs.o kirin960_defs.o \
kirin9xx_drm_overlay_utils.o
obj-$(CONFIG_DRM_HISI_KIRIN9XX) += kirin9xx-drm.o kirin9xx_pwm.o
diff --git a/drivers/staging/hikey9xx/gpu/kirin960_defs.c
b/drivers/staging/hikey9xx/gpu/kirin960_defs.c
new file mode 100644
index ..720f4f80a518
--- /dev/null
+++ b/drivers/staging/hikey9xx/gpu/kirin960_defs.c
@@ -0,0 +1,378 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2008-2011, Hisilicon Tech. Co., Ltd. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "kirin9xx_drm_dpe_utils.h"
+#include "kirin9xx_drm_drv.h"
+#include "kirin960_dpe_reg.h"
+
+/*
+ * dss_chn_idx
+ * DSS_RCHN_D2 = 0,DSS_RCHN_D3,DSS_RCHN_V0,DSS_RCHN_G0,
DSS_RCHN_V1,
+ * DSS_RCHN_G1,DSS_RCHN_D0,DSS_RCHN_D1,DSS_WCHN_W0,
DSS_WCHN_W1,
+ * DSS_RCHN_V2, DSS_WCHN_W2,
+ */
+static const u32
kirin960_g_dss_module_base[DSS_CHN_MAX_DEFINE][MODULE_CHN_MAX] = {
+ /* D0 */
+ {
+ MIF_CH0_OFFSET,
+ AIF0_CH0_OFFSET,
+ AIF1_CH0_OFFSET,
+ MCTL_CTL_MUTEX_RCH0,
+ DSS_MCTRL_SYS_OFFSET + MCTL_RCH0_FLUSH_EN,
+ DSS_MCTRL_SYS_OFFSET + MCTL_RCH0_OV_OEN,
+ DSS_MCTRL_SYS_OFFSET + MCTL_RCH0_STARTY,
+ DSS_MCTRL_SYS_OFFSET + MCTL_MOD0_DBG,
+ DSS_RCH_D0_DMA_OFFSET,
+ DSS_RCH_D0_DFC_OFFSET,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ DSS_RCH_D0_CSC_OFFSET,
+ },
+
+ /* D1 */
+ {
+ MIF_CH1_OFFSET,
+ AIF0_CH1_OFFSET,
+ AIF1_CH1_OFFSET,
+ MCTL_CTL_MUTEX_RCH1,
+ DSS_MCTRL_SYS_OFFSET + MCTL_RCH1_FLUSH_EN,
+ DSS_MCTRL_SYS_OFFSET + MCTL_RCH1_OV_OEN,
+ DSS_MCTRL_SYS_OFFSET + MCTL_RCH1_STARTY,
+ DSS_MCTRL_SYS_OFFSET + MCTL_MOD1_DBG,
+ DSS_RCH_D1_DMA_OFFSET,
+ DSS_RCH_D1_DFC_OFFSET,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ DSS_RCH_D1_CSC_OFFSET,
+ },
+
+ /* V0 */
+ {
+ MIF_CH2_OFFSET,
+ AIF0_CH2_OFFSET,
+ AIF1_CH2_OFFSET,
+ MCTL_CTL_MUTEX_RCH2,
+ DSS_MCTRL_SYS_OFFSET + MCTL_RCH2_FLUSH_EN,
+ DSS_MCTRL_SYS_OFFSET + MCTL_RCH2_OV_OEN,
+ DSS_MCTRL_SYS_OFFSET + MCTL_RCH2_STARTY,
+ DSS_MCTRL_SYS_OFFSET + MCTL_MOD2_DBG,
+ DSS_RCH_VG0_DMA_OFFSET,
+ DSS_RCH_VG0_DFC_OFFSET,
+ DSS_RCH_VG0_SCL_OFFSET,
+ DSS_RCH_VG0_SCL_LUT_OFFSET,
+ DSS_RCH_VG0_ARSR_OFFSET,
+ DSS_RCH_VG0_ARSR_LUT_OFFSET,
+ DSS_RCH_VG0_POST_CLIP_OFFSET,
+ DSS_RCH_VG0_PCSC_OFFSET,
+ DSS_RCH_VG0_CSC_OFFSET,
+ },
+
+ /* G0 */
+ {
+ MIF_CH3_OFFSET,
+ AIF0_CH3_OFFSET,
+ AIF1_CH3_OF
[PATCH 40/49] staging: hikey9xx/gpu: get rid of input/output macros
The DPE headers define several macros for I/O. Get rid of
them by replacing by the Linux ones.
In the specific case of outp32(), I used this small
coccinelle script to change them to writel():
@ rule1 @
expression addr, val;
@@
-outp32(addr, val)
+writel(val, addr)
Signed-off-by: Mauro Carvalho Chehab
---
.../staging/hikey9xx/gpu/kirin960_dpe_reg.h | 15 --
.../staging/hikey9xx/gpu/kirin970_dpe_reg.h | 15 --
.../hikey9xx/gpu/kirin9xx_drm_dpe_utils.c | 251 ++
.../staging/hikey9xx/gpu/kirin9xx_drm_dss.c | 24 +-
.../hikey9xx/gpu/kirin9xx_drm_overlay_utils.c | 14 +-
.../hikey9xx/gpu/kirin9xx_dw_drm_dsi.c| 24 +-
drivers/staging/hikey9xx/gpu/kirin9xx_pwm.c | 20 +-
7 files changed, 180 insertions(+), 183 deletions(-)
diff --git a/drivers/staging/hikey9xx/gpu/kirin960_dpe_reg.h
b/drivers/staging/hikey9xx/gpu/kirin960_dpe_reg.h
index f34d5af189f7..cd248bf15503 100644
--- a/drivers/staging/hikey9xx/gpu/kirin960_dpe_reg.h
+++ b/drivers/staging/hikey9xx/gpu/kirin960_dpe_reg.h
@@ -3218,21 +3218,6 @@ struct mipi_ifbc_division {
/*/
-#define outp32(addr, val) writel(val, addr)
-#define outp16(addr, val) writew(val, addr)
-#define outp8(addr, val) writeb(val, addr)
-#define outp(addr, val) outp32(addr, val)
-
-#define inp32(addr) readl(addr)
-#define inp16(addr) readw(addr)
-#define inp8(addr) readb(addr)
-#define inp(addr) inp32(addr)
-
-#define inpw(port) readw(port)
-#define outpw(port, val) writew(val, port)
-#define inpdw(port) readl(port)
-#define outpdw(port, val) writel(val, port)
-
#ifndef ALIGN_DOWN
#define ALIGN_DOWN(val, al) ((val) & ~((al) - 1))
#endif
diff --git a/drivers/staging/hikey9xx/gpu/kirin970_dpe_reg.h
b/drivers/staging/hikey9xx/gpu/kirin970_dpe_reg.h
index 4f24322ebc7f..aeae3720c889 100644
--- a/drivers/staging/hikey9xx/gpu/kirin970_dpe_reg.h
+++ b/drivers/staging/hikey9xx/gpu/kirin970_dpe_reg.h
@@ -4206,21 +4206,6 @@ struct mipi_ifbc_division {
/*/
-#define outp32(addr, val) writel(val, addr)
-#define outp16(addr, val) writew(val, addr)
-#define outp8(addr, val) writeb(val, addr)
-#define outp(addr, val) outp32(addr, val)
-
-#define inp32(addr) readl(addr)
-#define inp16(addr) readw(addr)
-#define inp8(addr) readb(addr)
-#define inp(addr) inp32(addr)
-
-#define inpw(port) readw(port)
-#define outpw(port, val) writew(val, port)
-#define inpdw(port) readl(port)
-#define outpdw(port, val) writel(val, port)
-
#ifndef ALIGN_DOWN
#define ALIGN_DOWN(val, al) ((val) & ~((al) - 1))
#endif
diff --git a/drivers/staging/hikey9xx/gpu/kirin9xx_drm_dpe_utils.c
b/drivers/staging/hikey9xx/gpu/kirin9xx_drm_dpe_utils.c
index 0e3d192c3851..ac7924fd0fc9 100644
--- a/drivers/staging/hikey9xx/gpu/kirin9xx_drm_dpe_utils.c
+++ b/drivers/staging/hikey9xx/gpu/kirin9xx_drm_dpe_utils.c
@@ -123,10 +123,10 @@ void set_reg(char __iomem *addr, uint32_t val, uint8_t
bw, uint8_t bs)
u32 mask = (1UL << bw) - 1UL;
u32 tmp = 0;
- tmp = inp32(addr);
+ tmp = readl(addr);
tmp &= ~(mask << bs);
- outp32(addr, tmp | ((val & mask) << bs));
+ writel(tmp | ((val & mask) << bs), addr);
if (g_debug_set_reg_val) {
printk(KERN_INFO "writel: [%p] = 0x%x\n", addr,
@@ -275,18 +275,16 @@ void init_ldi(struct dss_crtc *acrtc)
init_ldi_pxl_div(acrtc);
- outp32(ldi_base + LDI_DPI0_HRZ_CTRL0,
- hfp | ((hbp + DSS_WIDTH(hsw)) << 16));
- outp32(ldi_base + LDI_DPI0_HRZ_CTRL1, 0);
- outp32(ldi_base + LDI_DPI0_HRZ_CTRL2, DSS_WIDTH(rect.w));
- outp32(ldi_base + LDI_VRT_CTRL0,
- vfp | (vbp << 16));
- outp32(ldi_base + LDI_VRT_CTRL1, DSS_HEIGHT(vsw));
- outp32(ldi_base + LDI_VRT_CTRL2, DSS_HEIGHT(rect.h));
+ writel(hfp | ((hbp + DSS_WIDTH(hsw)) << 16),
+ ldi_base + LDI_DPI0_HRZ_CTRL0);
+ writel(0, ldi_base + LDI_DPI0_HRZ_CTRL1);
+ writel(DSS_WIDTH(rect.w), ldi_base + LDI_DPI0_HRZ_CTRL2);
+ writel(vfp | (vbp << 16), ldi_base + LDI_VRT_CTRL0);
+ writel(DSS_HEIGHT(vsw), ldi_base + LDI_VRT_CTRL1);
+ writel(DSS_HEIGHT(rect.h), ldi_base + LDI_VRT_CTRL2);
- outp32(ldi_base + LDI_PLR_CTRL,
- vsync_plr | (hsync_plr << 1) |
- (pixelclk_plr << 2) | (data_en_plr << 3));
+ writel(vsync_plr | (hsync_plr << 1) | (pixelclk_plr << 2) |
(data_en_plr << 3),
+ ldi_base + LDI_PLR_CTRL);
/* bpp*/
set_reg(ldi_base + LDI_CTRL, acrtc->out_format, 2, 3);
@@ -294,10 +292,10 @@ void init_ldi(struct dss_crtc *acrtc)
set_reg(ldi_base + LDI_CTRL, acrtc->bgr_fmt, 1, 13);
/* for ddr pmqos*/
- outp32(ldi_base + LDI_VINACT_MSK_LEN, vfp);
+ writel(vfp, ldi_base + LDI_VINACT_MSK_LEN);
/*cmd event sel*/
- outp32(ldi_base +
[PATCH 36/49] staging: hikey9xx/gpu: solve most coding style issues
There are lots of coding style issues on this driver, as
reported by checkpatch.
Address most of them.
Signed-off-by: Mauro Carvalho Chehab
---
.../staging/hikey9xx/gpu/kirin960_dpe_reg.h | 340 +++--
.../staging/hikey9xx/gpu/kirin970_dpe_reg.h | 1199 -
.../hikey9xx/gpu/kirin9xx_drm_dpe_utils.c | 285 ++--
.../hikey9xx/gpu/kirin9xx_drm_dpe_utils.h |4 +-
.../staging/hikey9xx/gpu/kirin9xx_drm_drv.c |2 +-
.../staging/hikey9xx/gpu/kirin9xx_drm_drv.h |4 +-
.../staging/hikey9xx/gpu/kirin9xx_drm_dss.c | 62 +-
.../hikey9xx/gpu/kirin9xx_drm_overlay_utils.c | 116 +-
.../hikey9xx/gpu/kirin9xx_dw_drm_dsi.c| 226 ++--
.../staging/hikey9xx/gpu/kirin9xx_fb_panel.h | 18 +-
drivers/staging/hikey9xx/gpu/kirin9xx_pwm.c | 26 +-
11 files changed, 1140 insertions(+), 1142 deletions(-)
diff --git a/drivers/staging/hikey9xx/gpu/kirin960_dpe_reg.h
b/drivers/staging/hikey9xx/gpu/kirin960_dpe_reg.h
index 131bb80d9bd1..651b3b172033 100644
--- a/drivers/staging/hikey9xx/gpu/kirin960_dpe_reg.h
+++ b/drivers/staging/hikey9xx/gpu/kirin960_dpe_reg.h
@@ -28,11 +28,11 @@
#include
#include
-#define FB_ACCEL_HI62xx0x1
-#define FB_ACCEL_HI363x0x2
-#define FB_ACCEL_HI365x0x4
-#define FB_ACCEL_HI625x0x8
-#define FB_ACCEL_HI366x0x10
+#define FB_ACCEL_HI62xx0x1
+#define FB_ACCEL_HI363x0x2
+#define FB_ACCEL_HI365x0x4
+#define FB_ACCEL_HI625x0x8
+#define FB_ACCEL_HI366x0x10
#define FB_ACCEL_KIRIN970_ES 0x20
#define FB_ACCEL_KIRIN970 0x40
#define FB_ACCEL_KIRIN660 0x80
@@ -40,9 +40,9 @@
#define FB_ACCEL_KIRIN980 0x200
#define FB_ACCEL_PLATFORM_TYPE_FPGA 0x1000 //FPGA
#define FB_ACCEL_PLATFORM_TYPE_ASIC 0x2000 //ASIC
-/***
-**
-*/
+
+/**/
+
enum dss_chn_idx {
DSS_RCHN_NONE = -1,
DSS_RCHN_D2 = 0,
@@ -104,32 +104,32 @@ enum dss_ovl_idx {
#define DSS_WCH_MAX (2)
typedef struct dss_img {
- uint32_t format;
- uint32_t width;
- uint32_t height;
- uint32_t bpp; /* bytes per pixel */
- uint32_t buf_size;
- uint32_t stride;
- uint32_t stride_plane1;
- uint32_t stride_plane2;
- uint64_t phy_addr;
- uint64_t vir_addr;
- uint32_t offset_plane1;
- uint32_t offset_plane2;
+ u32 format;
+ u32 width;
+ u32 height;
+ u32 bpp;/* bytes per pixel */
+ u32 buf_size;
+ u32 stride;
+ u32 stride_plane1;
+ u32 stride_plane2;
+ u64 phy_addr;
+ u64 vir_addr;
+ u32 offset_plane1;
+ u32 offset_plane2;
- uint64_t afbc_header_addr;
- uint64_t afbc_payload_addr;
- uint32_t afbc_header_stride;
- uint32_t afbc_payload_stride;
- uint32_t afbc_scramble_mode;
- uint32_t mmbuf_base;
- uint32_t mmbuf_size;
+ u64 afbc_header_addr;
+ u64 afbc_payload_addr;
+ u32 afbc_header_stride;
+ u32 afbc_payload_stride;
+ u32 afbc_scramble_mode;
+ u32 mmbuf_base;
+ u32 mmbuf_size;
- uint32_t mmu_enable;
- uint32_t csc_mode;
- uint32_t secure_mode;
- int32_t shared_fd;
- uint32_t reserved0;
+ u32 mmu_enable;
+ u32 csc_mode;
+ u32 secure_mode;
+ s32 shared_fd;
+ u32 reserved0;
} dss_img_t;
typedef struct drm_dss_layer {
@@ -137,20 +137,18 @@ typedef struct drm_dss_layer {
dss_rect_t src_rect;
dss_rect_t src_rect_mask;
dss_rect_t dst_rect;
- uint32_t transform;
- int32_t blending;
- uint32_t glb_alpha;
- uint32_t color; /* background color or dim color */
- int32_t layer_idx;
- int32_t chn_idx;
- uint32_t need_cap;
- int32_t acquire_fence;
+ u32 transform;
+ s32 blending;
+ u32 glb_alpha;
+ u32 color; /* background color or dim color */
+ s32 layer_idx;
+ s32 chn_idx;
+ u32 need_cap;
+ s32 acquire_fence;
} drm_dss_layer_t;
+/**/
-/***
-**
-*/
#define DEFAULT_MIPI_CLK_RATE (192 * 10L)
#define DEFAULT_PCLK_DSI_RATE (120 * 100L)
@@ -178,9 +176,8 @@ typedef struct drm_dss_layer {
#define GPIO_PG_SEL_B (76)
#define GPIO_TX_RX_B (78)
-/***
- **
- */
+/**/
+
#define CRGPERI_PLL0_CLK_RATE (16UL)
#define CRGPERI_PLL2_CLK_RATE (96000UL)
#define CRGPERI_PLL3_CLK_RATE (16UL)
@@ -195,10 +192,10 @@ typedef struct drm_dss_layer {
#define DSS_MAX_PXL0_CLK_2
[PATCH 48/49] staging: hikey9xx/gpu: drop kirin9xx_pwm
This is part of support for a panel display. Those don't come
with the Hikey 960 or 970 boards. As I don't have any of
those for tests, and we didn't port another required driver
for this to work, for now, let's drop it.
This patch can be reversed later, if one would be adding
support for it.
Signed-off-by: Mauro Carvalho Chehab
---
.../boot/dts/hisilicon/hikey970-drm.dtsi | 37 --
drivers/staging/hikey9xx/gpu/Makefile | 2 +-
drivers/staging/hikey9xx/gpu/kirin9xx_pwm.c | 404 --
3 files changed, 1 insertion(+), 442 deletions(-)
delete mode 100644 drivers/staging/hikey9xx/gpu/kirin9xx_pwm.c
diff --git a/arch/arm64/boot/dts/hisilicon/hikey970-drm.dtsi
b/arch/arm64/boot/dts/hisilicon/hikey970-drm.dtsi
index 3bd744b061ed..503c7c9425c8 100644
--- a/arch/arm64/boot/dts/hisilicon/hikey970-drm.dtsi
+++ b/arch/arm64/boot/dts/hisilicon/hikey970-drm.dtsi
@@ -87,44 +87,7 @@ dsi_out0: endpoint@0 {
reg = <0>;
remote-endpoint = <&adv7533_in>;
};
-
- dsi_out1: endpoint@1 {
- reg = <1>;
- remote-endpoint = <&panel0_in>;
- };
};
};
-
- panel@1 {
- compatible = "hisilicon,mipi-hikey";
- #address-cells = <2>;
- #size-cells = <2>;
- reg = <1>;
- panel-width-mm = <94>;
- panel-height-mm = <151>;
- vdd-supply = <&ldo3>;
- pwr-en-gpio = <&gpio21 3 0>;//GPIO_171
- bl-en-gpio = <&gpio6 4 0>;//GPIO_052
- pwm-gpio = <&gpio23 1 0>;//GPIO_185
-
- port {
- panel0_in: endpoint {
- remote-endpoint = <&dsi_out1>;
- };
- };
- };
- };
-
- panel_pwm {
- #address-cells = <2>;
- #size-cells = <2>;
- compatible = "hisilicon,hisipwm";
- reg = <0 0xE8A04000 0 0x1000>,
- <0 0xFFF35000 0 0x1000>;
- clocks = <&crg_ctrl HI3670_CLK_GATE_PWM>;
- clock-names = "clk_pwm";
- pinctrl-names = "default","idle";
- pinctrl-0 = <&gpio185_pmx_func &gpio185_cfg_func>;
- pinctrl-1 = <&gpio185_pmx_idle &gpio185_cfg_idle>;
};
};
diff --git a/drivers/staging/hikey9xx/gpu/Makefile
b/drivers/staging/hikey9xx/gpu/Makefile
index 9177c3006b14..16a708d7faec 100644
--- a/drivers/staging/hikey9xx/gpu/Makefile
+++ b/drivers/staging/hikey9xx/gpu/Makefile
@@ -5,5 +5,5 @@ kirin9xx-drm-y := kirin9xx_drm_drv.o \
kirin970_defs.o kirin960_defs.o \
kirin9xx_drm_overlay_utils.o
-obj-$(CONFIG_DRM_HISI_KIRIN9XX) += kirin9xx-drm.o kirin9xx_pwm.o
+obj-$(CONFIG_DRM_HISI_KIRIN9XX) += kirin9xx-drm.o
obj-$(CONFIG_DRM_HISI_KIRIN9XX_DSI) += kirin9xx_dw_drm_dsi.o
diff --git a/drivers/staging/hikey9xx/gpu/kirin9xx_pwm.c
b/drivers/staging/hikey9xx/gpu/kirin9xx_pwm.c
deleted file mode 100644
index d686664b8627..
--- a/drivers/staging/hikey9xx/gpu/kirin9xx_pwm.c
+++ /dev/null
@@ -1,404 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0
-/*
- * Copyright (c) 2013-2014, Hisilicon Tech. Co., Ltd. All rights reserved.
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 and
- * only version 2 as published by the Free Software Foundation.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.See the
- * GNU General Public License for more details.
- *
- */
-#include
-#include
-
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-
-#include "kirin9xx_drm_dpe_utils.h"
-#include "kirin9xx_fb_panel.h"
-#include "kirin9xx_dw_dsi_reg.h"
-
-#include "kirin9xx_dpe.h"
-
-/* default pwm clk */
-#define DEFAULT_PWM_CLK_RATE (80 * 100L)
-
-static char __iomem *hisifd_pwm_base;
-static char __iomem *hisi_peri_crg_base;
-static struct clk *g_pwm_clk;
-static struct platform_device *g_pwm_pdev;
-static int g_pwm_on;
-
-static struct pinctrl_data pwmpctrl;
-
-static struct pinctrl_cmd_desc pwm_pinctrl_init_cmds[] = {
- {DTYPE_PINCTRL_GET, &pwmpctrl, 0},
- {DTYPE_PINCTRL_STATE_GET, &pwmpctrl, DTYPE_PINCTRL_STATE_DEFAULT},
- {DTYPE_PINCTRL_STATE_GET, &pwmpctrl, DTYPE_PINCTRL_STATE_IDLE},
-};
-
-static struct pinctrl_cmd_desc pwm_pinctrl_normal_cmds[] = {
- {DTYPE_PINCTRL_SET, &pwmpctrl, DTYPE_PINCTRL_STATE_DEFAUL
Re: [PATCH] block: convert tasklets to use new tasklet_setup() API
On 8/18/20 1:00 PM, James Bottomley wrote: > On Mon, 2020-08-17 at 13:02 -0700, Jens Axboe wrote: >> On 8/17/20 12:48 PM, Kees Cook wrote: >>> On Mon, Aug 17, 2020 at 12:44:34PM -0700, Jens Axboe wrote: On 8/17/20 12:29 PM, Kees Cook wrote: > On Mon, Aug 17, 2020 at 06:56:47AM -0700, Jens Axboe wrote: >> On 8/17/20 2:15 AM, Allen Pais wrote: >>> From: Allen Pais >>> >>> In preparation for unconditionally passing the >>> struct tasklet_struct pointer to all tasklet >>> callbacks, switch to using the new tasklet_setup() >>> and from_tasklet() to pass the tasklet pointer explicitly. >> >> Who came up with the idea to add a macro 'from_tasklet' that >> is just container_of? container_of in the code would be >> _much_ more readable, and not leave anyone guessing wtf >> from_tasklet is doing. >> >> I'd fix that up now before everything else goes in... > > As I mentioned in the other thread, I think this makes things > much more readable. It's the same thing that the timer_struct > conversion did (added a container_of wrapper) to avoid the > ever-repeating use of typeof(), long lines, etc. But then it should use a generic name, instead of each sub-system using some random name that makes people look up exactly what it does. I'm not huge fan of the container_of() redundancy, but adding private variants of this doesn't seem like the best way forward. Let's have a generic helper that does this, and use it everywhere. >>> >>> I'm open to suggestions, but as things stand, these kinds of >>> treewide >> >> On naming? Implementation is just as it stands, from_tasklet() is >> totally generic which is why I objected to it. from_member()? Not >> great with naming... But I can see this going further and then we'll >> suddenly have tons of these. It's not good for readability. > > Since both threads seem to have petered out, let me suggest in > kernel.h: > > #define cast_out(ptr, container, member) \ > container_of(ptr, typeof(*container), member) > > It does what you want, the argument order is the same as container_of > with the only difference being you name the containing structure > instead of having to specify its type. Not to incessantly bike shed on the naming, but I don't like cast_out, it's not very descriptive. And it has connotations of getting rid of something, which isn't really true. FWIW, I like the from_ part of the original naming, as it has some clues as to what is being done here. Why not just from_container()? That should immediately tell people what it does without having to look up the implementation, even before this becomes a part of the accepted coding norm. -- Jens Axboe ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] block: convert tasklets to use new tasklet_setup() API
On Wed, Aug 19, 2020 at 07:00:53AM -0600, Jens Axboe wrote: > On 8/18/20 1:00 PM, James Bottomley wrote: > > On Mon, 2020-08-17 at 13:02 -0700, Jens Axboe wrote: > >> On 8/17/20 12:48 PM, Kees Cook wrote: > >>> On Mon, Aug 17, 2020 at 12:44:34PM -0700, Jens Axboe wrote: > On 8/17/20 12:29 PM, Kees Cook wrote: > > On Mon, Aug 17, 2020 at 06:56:47AM -0700, Jens Axboe wrote: > >> On 8/17/20 2:15 AM, Allen Pais wrote: > >>> From: Allen Pais > >>> > >>> In preparation for unconditionally passing the > >>> struct tasklet_struct pointer to all tasklet > >>> callbacks, switch to using the new tasklet_setup() > >>> and from_tasklet() to pass the tasklet pointer explicitly. > >> > >> Who came up with the idea to add a macro 'from_tasklet' that > >> is just container_of? container_of in the code would be > >> _much_ more readable, and not leave anyone guessing wtf > >> from_tasklet is doing. > >> > >> I'd fix that up now before everything else goes in... > > > > As I mentioned in the other thread, I think this makes things > > much more readable. It's the same thing that the timer_struct > > conversion did (added a container_of wrapper) to avoid the > > ever-repeating use of typeof(), long lines, etc. > > But then it should use a generic name, instead of each sub-system > using some random name that makes people look up exactly what it > does. I'm not huge fan of the container_of() redundancy, but > adding private variants of this doesn't seem like the best way > forward. Let's have a generic helper that does this, and use it > everywhere. > >>> > >>> I'm open to suggestions, but as things stand, these kinds of > >>> treewide > >> > >> On naming? Implementation is just as it stands, from_tasklet() is > >> totally generic which is why I objected to it. from_member()? Not > >> great with naming... But I can see this going further and then we'll > >> suddenly have tons of these. It's not good for readability. > > > > Since both threads seem to have petered out, let me suggest in > > kernel.h: > > > > #define cast_out(ptr, container, member) \ > > container_of(ptr, typeof(*container), member) > > > > It does what you want, the argument order is the same as container_of > > with the only difference being you name the containing structure > > instead of having to specify its type. > > Not to incessantly bike shed on the naming, but I don't like cast_out, > it's not very descriptive. And it has connotations of getting rid of > something, which isn't really true. I agree, if we want to bike shed, I don't like this color either. > FWIW, I like the from_ part of the original naming, as it has some clues > as to what is being done here. Why not just from_container()? That > should immediately tell people what it does without having to look up > the implementation, even before this becomes a part of the accepted > coding norm. Why are people hating on the well-known and used container_of()? If you really hate to type the type and want a new macro, what about 'container_from()'? (noun/verb is nicer to sort symbols by...) But really, why is this even needed? thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] block: convert tasklets to use new tasklet_setup() API
On 8/19/20 6:11 AM, Greg KH wrote: > On Wed, Aug 19, 2020 at 07:00:53AM -0600, Jens Axboe wrote: >> On 8/18/20 1:00 PM, James Bottomley wrote: >>> On Mon, 2020-08-17 at 13:02 -0700, Jens Axboe wrote: On 8/17/20 12:48 PM, Kees Cook wrote: > On Mon, Aug 17, 2020 at 12:44:34PM -0700, Jens Axboe wrote: >> On 8/17/20 12:29 PM, Kees Cook wrote: >>> On Mon, Aug 17, 2020 at 06:56:47AM -0700, Jens Axboe wrote: On 8/17/20 2:15 AM, Allen Pais wrote: > From: Allen Pais > > In preparation for unconditionally passing the > struct tasklet_struct pointer to all tasklet > callbacks, switch to using the new tasklet_setup() > and from_tasklet() to pass the tasklet pointer explicitly. Who came up with the idea to add a macro 'from_tasklet' that is just container_of? container_of in the code would be _much_ more readable, and not leave anyone guessing wtf from_tasklet is doing. I'd fix that up now before everything else goes in... >>> >>> As I mentioned in the other thread, I think this makes things >>> much more readable. It's the same thing that the timer_struct >>> conversion did (added a container_of wrapper) to avoid the >>> ever-repeating use of typeof(), long lines, etc. >> >> But then it should use a generic name, instead of each sub-system >> using some random name that makes people look up exactly what it >> does. I'm not huge fan of the container_of() redundancy, but >> adding private variants of this doesn't seem like the best way >> forward. Let's have a generic helper that does this, and use it >> everywhere. > > I'm open to suggestions, but as things stand, these kinds of > treewide On naming? Implementation is just as it stands, from_tasklet() is totally generic which is why I objected to it. from_member()? Not great with naming... But I can see this going further and then we'll suddenly have tons of these. It's not good for readability. >>> >>> Since both threads seem to have petered out, let me suggest in >>> kernel.h: >>> >>> #define cast_out(ptr, container, member) \ >>> container_of(ptr, typeof(*container), member) >>> >>> It does what you want, the argument order is the same as container_of >>> with the only difference being you name the containing structure >>> instead of having to specify its type. >> >> Not to incessantly bike shed on the naming, but I don't like cast_out, >> it's not very descriptive. And it has connotations of getting rid of >> something, which isn't really true. > > I agree, if we want to bike shed, I don't like this color either. > >> FWIW, I like the from_ part of the original naming, as it has some clues >> as to what is being done here. Why not just from_container()? That >> should immediately tell people what it does without having to look up >> the implementation, even before this becomes a part of the accepted >> coding norm. > > Why are people hating on the well-known and used container_of()? > > If you really hate to type the type and want a new macro, what about > 'container_from()'? (noun/verb is nicer to sort symbols by...) > > But really, why is this even needed? container_from() or from_container(), either works just fine for me in terms of naming. I think people are hating on it because it makes for _really_ long lines, and it's arguably cleaner/simpler to just pass in the pointer type instead. Then you end up with lines like this: struct request_queue *q = container_of(work, struct request_queue, requeue_work.work); But I'm not the one that started this addition of from_tasklet(), my objection was adding a private macro for something that should be generic functionality. Hence I think we either need to provide that, or tell the from_tasklet() folks that they should just use container_of(). -- Jens Axboe ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] block: convert tasklets to use new tasklet_setup() API
On Wed, Aug 19, 2020 at 07:17:19AM -0600, Jens Axboe wrote: > On 8/19/20 6:11 AM, Greg KH wrote: > > On Wed, Aug 19, 2020 at 07:00:53AM -0600, Jens Axboe wrote: > >> On 8/18/20 1:00 PM, James Bottomley wrote: > >>> On Mon, 2020-08-17 at 13:02 -0700, Jens Axboe wrote: > On 8/17/20 12:48 PM, Kees Cook wrote: > > On Mon, Aug 17, 2020 at 12:44:34PM -0700, Jens Axboe wrote: > >> On 8/17/20 12:29 PM, Kees Cook wrote: > >>> On Mon, Aug 17, 2020 at 06:56:47AM -0700, Jens Axboe wrote: > On 8/17/20 2:15 AM, Allen Pais wrote: > > From: Allen Pais > > > > In preparation for unconditionally passing the > > struct tasklet_struct pointer to all tasklet > > callbacks, switch to using the new tasklet_setup() > > and from_tasklet() to pass the tasklet pointer explicitly. > > Who came up with the idea to add a macro 'from_tasklet' that > is just container_of? container_of in the code would be > _much_ more readable, and not leave anyone guessing wtf > from_tasklet is doing. > > I'd fix that up now before everything else goes in... > >>> > >>> As I mentioned in the other thread, I think this makes things > >>> much more readable. It's the same thing that the timer_struct > >>> conversion did (added a container_of wrapper) to avoid the > >>> ever-repeating use of typeof(), long lines, etc. > >> > >> But then it should use a generic name, instead of each sub-system > >> using some random name that makes people look up exactly what it > >> does. I'm not huge fan of the container_of() redundancy, but > >> adding private variants of this doesn't seem like the best way > >> forward. Let's have a generic helper that does this, and use it > >> everywhere. > > > > I'm open to suggestions, but as things stand, these kinds of > > treewide > > On naming? Implementation is just as it stands, from_tasklet() is > totally generic which is why I objected to it. from_member()? Not > great with naming... But I can see this going further and then we'll > suddenly have tons of these. It's not good for readability. > >>> > >>> Since both threads seem to have petered out, let me suggest in > >>> kernel.h: > >>> > >>> #define cast_out(ptr, container, member) \ > >>> container_of(ptr, typeof(*container), member) > >>> > >>> It does what you want, the argument order is the same as container_of > >>> with the only difference being you name the containing structure > >>> instead of having to specify its type. > >> > >> Not to incessantly bike shed on the naming, but I don't like cast_out, > >> it's not very descriptive. And it has connotations of getting rid of > >> something, which isn't really true. > > > > I agree, if we want to bike shed, I don't like this color either. > > > >> FWIW, I like the from_ part of the original naming, as it has some clues > >> as to what is being done here. Why not just from_container()? That > >> should immediately tell people what it does without having to look up > >> the implementation, even before this becomes a part of the accepted > >> coding norm. > > > > Why are people hating on the well-known and used container_of()? > > > > If you really hate to type the type and want a new macro, what about > > 'container_from()'? (noun/verb is nicer to sort symbols by...) > > > > But really, why is this even needed? > > container_from() or from_container(), either works just fine for me > in terms of naming. > > I think people are hating on it because it makes for _really_ long > lines, and it's arguably cleaner/simpler to just pass in the pointer > type instead. Then you end up with lines like this: > > struct request_queue *q = > container_of(work, struct request_queue, requeue_work.work); > > But I'm not the one that started this addition of from_tasklet(), my > objection was adding a private macro for something that should be > generic functionality. Agreed. > Hence I think we either need to provide that, or > tell the from_tasklet() folks that they should just use container_of(). Also agreed, thanks. greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] block: convert tasklets to use new tasklet_setup() API
On Wed, 2020-08-19 at 07:00 -0600, Jens Axboe wrote: > On 8/18/20 1:00 PM, James Bottomley wrote: [...] > > Since both threads seem to have petered out, let me suggest in > > kernel.h: > > > > #define cast_out(ptr, container, member) \ > > container_of(ptr, typeof(*container), member) > > > > It does what you want, the argument order is the same as > > container_of with the only difference being you name the containing > > structure instead of having to specify its type. > > Not to incessantly bike shed on the naming, but I don't like > cast_out, it's not very descriptive. And it has connotations of > getting rid of something, which isn't really true. Um, I thought it was exactly descriptive: you're casting to the outer container. I thought about following the C++ dynamic casting style, so out_cast(), but that seemed a bit pejorative. What about outer_cast()? > FWIW, I like the from_ part of the original naming, as it has some > clues as to what is being done here. Why not just from_container()? > That should immediately tell people what it does without having to > look up the implementation, even before this becomes a part of the > accepted coding norm. I'm not opposed to container_from() but it seems a little less descriptive than outer_cast() but I don't really care. I always have to look up container_of() when I'm using it so this would just be another macro of that type ... James ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 00/49] DRM driver for Hikey 970
Hi Mauro. On Wed, Aug 19, 2020 at 01:45:28PM +0200, Mauro Carvalho Chehab wrote: > This patch series port the out-of-tree driver for Hikey 970 (which > should also support Hikey 960) from the official 96boards tree: > >https://github.com/96boards-hikey/linux/tree/hikey970-v4.9 > > Based on his history, this driver seems to be originally written > for Kernel 4.4, and was later ported to Kernel 4.9. The original > driver used to depend on ION (from Kernel 4.4) and had its own > implementation for FB dev API. > > As I need to preserve the original history (with has patches from > both HiSilicon and from Linaro), I'm starting from the original > patch applied there. The remaining patches are incremental, > and port this driver to work with upstream Kernel. > > This driver doesn't depend on any firmware or on any special > userspace code. It works as-is with both X11 and Wayland. > > Yet, I'm submitting it via staging due to the following reasons: > > - It depends on the LDO3 power supply, which is provided by > a regulator driver that it is currently on staging; > - Due to legal reasons, I need to preserve the authorship of > each one responsbile for each patch. So, I need to start from > the original patch from Kernel 4.4; > - There are still some problems I need to figure out how to solve: >- The adv7535 can't get EDID data. Maybe it is a timing issue, > but it requires more research to be sure about how to solve it; >- The driver only accept resolutions on a defined list, as there's > a known bug that this driver may have troubles with random > resolutions. Probably due to a bug at the pixel clock settings; >- Sometimes (at least with 1080p), it generates LDI underflow > errors, which in turn causes the DRM to stop working. That > happens for example when using gdm on Wayland and > gnome on X11; >- Probably related to the previous issue, when the monitor > suspends due to DPMS, it doesn't return back to life. > > So, IMO, the best is to keep it on staging for a while, until those > remaining bugs gets solved. > > I added this series, together with the regulator driver and > a few other patches (including a hack to fix a Kernel 5.8 > regression at WiFi ) at: > > https://gitlab.freedesktop.org/mchehab_kernel/hikey-970/-/commits/master > > > Chen Feng (1): > staging: hikey9xx: Add hisilicon DRM driver for hikey960/970 > > John Stultz (1): > staging: hikey9xx/gpu: port it to work with Kernel v4.9 > > Liwei Cai (2): > staging: hikey9xx/gpu: solve tearing issue of display > staging: hikey9xx/gpu: resolve the performance issue by interrupt > mechanism > > Mauro Carvalho Chehab (38): > staging: hikey9xx/gpu: get rid of adv7535 fork Very good - I was in my mind starting a rant why we needed a fork of this driver, but I see it gets deleted again. I do acknowledge you need to preserve history and all - but this patchset is not easy to review. Could you follow-up with a review-able set of patches as a follow-up for this? I spotted some wrong bridge handling in one patch but I do not know if this got changed in a later patch. And I lost the motivation to go looking for it. > staging: hikey9xx/gpu: rename the Kirin9xx namespace > staging: hikey9xx/gpu: get rid of kirin9xx_fbdev.c > staging: hikey9xx/gpu: get rid of some ifdefs > staging: hikey9xx/gpu: rename the config option for Kirin970 > staging: hikey9xx/gpu: change the includes to reflect upstream > staging: hikey9xx/gpu: port driver to upstream kAPIs > staging: hikey9xx/gpu: add a copy of set_reg() function there > staging: hikey9xx/gpu: get rid of ION headers > staging: hikey9xx/gpu: add support for using a reserved CMA memory > staging: hikey9xx/gpu: cleanup encoder attach logic > staging: hikey9xx/gpu: Change the logic which sets the burst mode > staging: hikey9xx/gpu: fix the DRM setting logic > staging: hikey9xx/gpu: do some code cleanups > staging: hikey9xx/gpu: use default GEM_CMA fops > staging: hikey9xx/gpu: place vblank enable/disable at the right place > staging: hikey9xx/gpu: remove an uneeded hack > staging: hikey9xx/gpu: add a possible implementation for > atomic_disable > staging: hikey9xx/gpu: register connector > staging: hikey9xx/gpu: fix driver name > staging: hikey9xx/gpu: get rid of iommu_format > staging: hikey9xx/gpu: re-work the mode validation code > staging: hikey9xx/gpu: add support for enable/disable ldo3 regulator > staging: hikey9xx/gpu: add SPMI headers > staging: hikey9xx/gpu: solve most coding style issues > staging: hikey9xx/gpu: don't use iommu code > staging: hikey9xx/gpu: add kirin9xx driver to the building system > staging: hikey9xx/gpu: get rid of typedefs > staging: hikey9xx/gpu: get rid of input/output macros > staging: hikey9xx/gpu: get rid of some unused data > staging: hikey9xx/gpu: place common definitions at kirin9xx_dpe.h > staging: hikey9xx/gpu: get rid
Re: [PATCH 00/49] DRM driver for Hikey 970
On Wed, Aug 19, 2020 at 05:21:20PM +0200, Sam Ravnborg wrote: > Hi Mauro. > > On Wed, Aug 19, 2020 at 01:45:28PM +0200, Mauro Carvalho Chehab wrote: > > This patch series port the out-of-tree driver for Hikey 970 (which > > should also support Hikey 960) from the official 96boards tree: > > > >https://github.com/96boards-hikey/linux/tree/hikey970-v4.9 > > > > Based on his history, this driver seems to be originally written > > for Kernel 4.4, and was later ported to Kernel 4.9. The original > > driver used to depend on ION (from Kernel 4.4) and had its own > > implementation for FB dev API. > > > > As I need to preserve the original history (with has patches from > > both HiSilicon and from Linaro), I'm starting from the original > > patch applied there. The remaining patches are incremental, > > and port this driver to work with upstream Kernel. > > > > This driver doesn't depend on any firmware or on any special > > userspace code. It works as-is with both X11 and Wayland. > > > > Yet, I'm submitting it via staging due to the following reasons: > > > > - It depends on the LDO3 power supply, which is provided by > > a regulator driver that it is currently on staging; > > - Due to legal reasons, I need to preserve the authorship of > > each one responsbile for each patch. So, I need to start from > > the original patch from Kernel 4.4; > > - There are still some problems I need to figure out how to solve: > >- The adv7535 can't get EDID data. Maybe it is a timing issue, > > but it requires more research to be sure about how to solve it; > >- The driver only accept resolutions on a defined list, as there's > > a known bug that this driver may have troubles with random > > resolutions. Probably due to a bug at the pixel clock settings; > >- Sometimes (at least with 1080p), it generates LDI underflow > > errors, which in turn causes the DRM to stop working. That > > happens for example when using gdm on Wayland and > > gnome on X11; > >- Probably related to the previous issue, when the monitor > > suspends due to DPMS, it doesn't return back to life. > > > > So, IMO, the best is to keep it on staging for a while, until those > > remaining bugs gets solved. > > > > I added this series, together with the regulator driver and > > a few other patches (including a hack to fix a Kernel 5.8 > > regression at WiFi ) at: > > > > https://gitlab.freedesktop.org/mchehab_kernel/hikey-970/-/commits/master > > > > > > Chen Feng (1): > > staging: hikey9xx: Add hisilicon DRM driver for hikey960/970 > > > > John Stultz (1): > > staging: hikey9xx/gpu: port it to work with Kernel v4.9 > > > > Liwei Cai (2): > > staging: hikey9xx/gpu: solve tearing issue of display > > staging: hikey9xx/gpu: resolve the performance issue by interrupt > > mechanism > > > > Mauro Carvalho Chehab (38): > > staging: hikey9xx/gpu: get rid of adv7535 fork > Very good - I was in my mind starting a rant why we needed a fork of > this driver, but I see it gets deleted again. > > I do acknowledge you need to preserve history and all - > but this patchset is not easy to review. Why do we need to preserve history ? Adding relevant Signed-off-by and Co-developed-by should be enough, shouldn't it ? Having a public branch that contains the history is useful if anyone is interested, but I don't think it's required in mainline. > Could you follow-up with a review-able set of patches as a follow-up > for this? > I spotted some wrong bridge handling in one patch but I do not know if > this got changed in a later patch. And I lost the motivation to go > looking for it. > > > staging: hikey9xx/gpu: rename the Kirin9xx namespace > > staging: hikey9xx/gpu: get rid of kirin9xx_fbdev.c > > staging: hikey9xx/gpu: get rid of some ifdefs > > staging: hikey9xx/gpu: rename the config option for Kirin970 > > staging: hikey9xx/gpu: change the includes to reflect upstream > > staging: hikey9xx/gpu: port driver to upstream kAPIs > > staging: hikey9xx/gpu: add a copy of set_reg() function there > > staging: hikey9xx/gpu: get rid of ION headers > > staging: hikey9xx/gpu: add support for using a reserved CMA memory > > staging: hikey9xx/gpu: cleanup encoder attach logic > > staging: hikey9xx/gpu: Change the logic which sets the burst mode > > staging: hikey9xx/gpu: fix the DRM setting logic > > staging: hikey9xx/gpu: do some code cleanups > > staging: hikey9xx/gpu: use default GEM_CMA fops > > staging: hikey9xx/gpu: place vblank enable/disable at the right place > > staging: hikey9xx/gpu: remove an uneeded hack > > staging: hikey9xx/gpu: add a possible implementation for > > atomic_disable > > staging: hikey9xx/gpu: register connector > > staging: hikey9xx/gpu: fix driver name > > staging: hikey9xx/gpu: get rid of iommu_format > > staging: hikey9xx/gpu: re-work the mode validation code > > staging: hikey9xx/gpu: add support for enable/di
Re: [PATCH 38/49] staging: hikey9xx/gpu: add kirin9xx driver to the building system
On 8/19/20 4:46 AM, Mauro Carvalho Chehab wrote: > Now that everything is in place, add the driver to the > building system. > > Signed-off-by: Mauro Carvalho Chehab Hi Mauro, In this patch and in patch 01/49, please be consistent in capitalization on HiSilicon. more below: > --- > drivers/staging/hikey9xx/Kconfig | 3 ++ > drivers/staging/hikey9xx/Makefile | 1 + > drivers/staging/hikey9xx/gpu/Kconfig | 52 ++- > drivers/staging/hikey9xx/gpu/Makefile | 21 --- > 4 files changed, 22 insertions(+), 55 deletions(-) > > diff --git a/drivers/staging/hikey9xx/Kconfig > b/drivers/staging/hikey9xx/Kconfig > index 0e97b5b9a56a..b2ce886e1c4e 100644 > --- a/drivers/staging/hikey9xx/Kconfig > +++ b/drivers/staging/hikey9xx/Kconfig > @@ -36,3 +36,6 @@ config REGULATOR_HI6421V600 > This driver provides support for the voltage regulators on > HiSilicon Hi6421v600 PMU / Codec IC. > This is used on Kirin 3670 boards, like HiKey 970. > + > +# DRM/KMS driver > +source "drivers/staging/hikey9xx/gpu/Kconfig" > diff --git a/drivers/staging/hikey9xx/gpu/Kconfig > b/drivers/staging/hikey9xx/gpu/Kconfig > index 5533ee624f29..957da13bcf81 100644 > --- a/drivers/staging/hikey9xx/gpu/Kconfig > +++ b/drivers/staging/hikey9xx/gpu/Kconfig > @@ -1,52 +1,22 @@ > -config DRM_HISI_KIRIN > - tristate "DRM Support for Hisilicon Kirin series SoCs Platform"> > +config DRM_HISI_KIRIN9XX > + tristate "DRM Support for Hisilicon Kirin9xx series SoCs Platform" HiSilicon > depends on DRM && OF && ARM64 > select DRM_KMS_HELPER > select DRM_GEM_CMA_HELPER > select DRM_KMS_CMA_HELPER > - select HISI_KIRIN_DW_DSI > - help > - Choose this option if you have a hisilicon Kirin chipsets(hi6220). > - If M is selected the module will be called kirin-drm. > - > -config DRM_KIRIN_960 > - tristate "DRM Support for Hisilicon Kirin960 series SoCs Platform" > - depends on DRM && OF && ARM64 > - select DRM_KMS_HELPER > - select DRM_GEM_CMA_HELPER > - select DRM_KMS_CMA_HELPER > - select HISI_KIRIN_DW_DSI > - help > - Choose this option if you have a hisilicon Kirin chipsets(kirin960). > - If M is selected the module will be called kirin-drm. > - > -config HISI_KIRIN_DW_DSI > - tristate "HiSilicon Kirin specific extensions for Synopsys DW MIPI DSI" > - depends on DRM_HISI_KIRIN || DRM_KIRIN_960 > select DRM_MIPI_DSI > - select DRM_PANEL > help > - This selects support for HiSilicon Kirin SoC specific extensions for > - the Synopsys DesignWare DSI driver. If you want to enable MIPI DSI on > - hi6220 based SoC, you should selet this option. > + Choose this option if you have a HiSilicon Kirin960 or Kirin970. > + If M is selected the module will be called kirin9xx-drm. Indent with 1 tab + 2 spaces. > > -config DRM_PANEL_HIKEY960_NTE300NTS > - tristate "Hikey960 NTE300NTS video mode panel" > - depends on OF > - depends on DRM_MIPI_DSI > - help > - Say Y here if you want to enable LCD panel driver for Hikey960 > boadr. > - Current support panel: NTE300NTS(1920X1200) > - > -config HISI_FB_970 > - tristate "DRM Support for Hisilicon Kirin970 series SoCs Platform" > - depends on DRM && OF && ARM64 > +config DRM_HISI_KIRIN970 > + bool "Enable support for Hisilicon Kirin970" HiSilicon > depends on DRM_MIPI_DSI > + depends on DRM_HISI_KIRIN9XX > help > Choose this option if you have a hisilicon Kirin chipsets(kirin970). HiSilicon > - If M is selected the module will be called kirin-drm. > > -config HDMI_ADV7511_AUDIO > - tristate "HDMI Support ADV7511 audio" > - help > - Choose this option to support HDMI ADV7511 audio. > +config DRM_HISI_KIRIN9XX_DSI > + tristate > + depends on DRM_HISI_KIRIN9XX > + default y thanks. -- ~Randy ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] block: convert tasklets to use new tasklet_setup() API
> [...] > > > Since both threads seem to have petered out, let me suggest in > > > kernel.h: > > > > > > #define cast_out(ptr, container, member) \ > > > container_of(ptr, typeof(*container), member) > > > > > > It does what you want, the argument order is the same as > > > container_of with the only difference being you name the containing > > > structure instead of having to specify its type. > > > > Not to incessantly bike shed on the naming, but I don't like > > cast_out, it's not very descriptive. And it has connotations of > > getting rid of something, which isn't really true. > > Um, I thought it was exactly descriptive: you're casting to the outer > container. I thought about following the C++ dynamic casting style, so > out_cast(), but that seemed a bit pejorative. What about outer_cast()? > > > FWIW, I like the from_ part of the original naming, as it has some > > clues as to what is being done here. Why not just from_container()? > > That should immediately tell people what it does without having to > > look up the implementation, even before this becomes a part of the > > accepted coding norm. > > I'm not opposed to container_from() but it seems a little less > descriptive than outer_cast() but I don't really care. I always have > to look up container_of() when I'm using it so this would just be > another macro of that type ... > So far we have a few which have been suggested as replacement for from_tasklet() - out_cast() or outer_cast() - from_member(). - container_from() or from_container() from_container() sounds fine, would trimming it a bit work? like from_cont(). -- - Allen ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] block: convert tasklets to use new tasklet_setup() API
On 8/19/20 9:24 AM, Allen wrote: >> [...] Since both threads seem to have petered out, let me suggest in kernel.h: #define cast_out(ptr, container, member) \ container_of(ptr, typeof(*container), member) It does what you want, the argument order is the same as container_of with the only difference being you name the containing structure instead of having to specify its type. >>> >>> Not to incessantly bike shed on the naming, but I don't like >>> cast_out, it's not very descriptive. And it has connotations of >>> getting rid of something, which isn't really true. >> >> Um, I thought it was exactly descriptive: you're casting to the outer >> container. I thought about following the C++ dynamic casting style, so >> out_cast(), but that seemed a bit pejorative. What about outer_cast()? >> >>> FWIW, I like the from_ part of the original naming, as it has some >>> clues as to what is being done here. Why not just from_container()? >>> That should immediately tell people what it does without having to >>> look up the implementation, even before this becomes a part of the >>> accepted coding norm. >> >> I'm not opposed to container_from() but it seems a little less >> descriptive than outer_cast() but I don't really care. I always have >> to look up container_of() when I'm using it so this would just be >> another macro of that type ... >> > > So far we have a few which have been suggested as replacement > for from_tasklet() > > - out_cast() or outer_cast() > - from_member(). > - container_from() or from_container() > > from_container() sounds fine, would trimming it a bit work? like from_cont(). I like container_from() the most, since it's the closest to contain_of() which is a well known idiom for years. The lines will already be shorter without the need to specify the struct, so don't like the idea of squeezing container into cont for any of them. For most people, cont is usually short for continue, not container. -- Jens Axboe ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v3 0/2] staging: android: Remove BUG/BUG_ON from ion
Removeing BUG/BUG_ON from androind/ion and add error handle to calling functions Tomer Samara (2): staging: android: Remove BUG_ON from ion_page_pool.c staging: android: Remove BUG from ion_system_heap.c drivers/staging/android/ion/ion_page_pool.c | 14 ++ drivers/staging/android/ion/ion_system_heap.c | 15 --- 2 files changed, 22 insertions(+), 7 deletions(-) -- 2.25.1 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v3 0/2] staging: android: Remove BUG/BUG_ONs
Remove BUG/BUG_ONs from androind/ion allocator and add error handling to calling functions Tomer Samara (2): staging: android: Remove BUG_ON from ion_page_pool.c staging: android: Remove BUG from ion_system_heap.c drivers/staging/android/ion/ion_page_pool.c | 14 ++ drivers/staging/android/ion/ion_system_heap.c | 15 --- 2 files changed, 22 insertions(+), 7 deletions(-) -- 2.25.1 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v3 1/2] staging: android: Remove BUG_ON from ion_page_pool.c
BUG_ON() is removed at ion_page_pool.c and add error handleing to
ion_page_pool_shrink
Fixes the following issue:
Avoid crashing the kernel - try using WARN_ON & recovery code ratherthan BUG()
or BUG_ON().
Signed-off-by: Tomer Samara
---
drivers/staging/android/ion/ion_page_pool.c | 14 ++
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/drivers/staging/android/ion/ion_page_pool.c
b/drivers/staging/android/ion/ion_page_pool.c
index 0198b886d906..ae2bc57bcbe8 100644
--- a/drivers/staging/android/ion/ion_page_pool.c
+++ b/drivers/staging/android/ion/ion_page_pool.c
@@ -46,11 +46,13 @@ static struct page *ion_page_pool_remove(struct
ion_page_pool *pool, bool high)
struct page *page;
if (high) {
- BUG_ON(!pool->high_count);
+ if (!pool->high_count)
+ return NULL;
page = list_first_entry(&pool->high_items, struct page, lru);
pool->high_count--;
} else {
- BUG_ON(!pool->low_count);
+ if (!pool->low_count)
+ return NULL;
page = list_first_entry(&pool->low_items, struct page, lru);
pool->low_count--;
}
@@ -65,7 +67,8 @@ struct page *ion_page_pool_alloc(struct ion_page_pool *pool)
{
struct page *page = NULL;
- BUG_ON(!pool);
+ if (!pool)
+ return NULL;
mutex_lock(&pool->mutex);
if (pool->high_count)
@@ -82,7 +85,8 @@ struct page *ion_page_pool_alloc(struct ion_page_pool *pool)
void ion_page_pool_free(struct ion_page_pool *pool, struct page *page)
{
- BUG_ON(pool->order != compound_order(page));
+ if (pool->order != compound_order(page))
+ return;
ion_page_pool_add(pool, page);
}
@@ -124,6 +128,8 @@ int ion_page_pool_shrink(struct ion_page_pool *pool, gfp_t
gfp_mask,
break;
}
mutex_unlock(&pool->mutex);
+ if (!page)
+ break;
ion_page_pool_free_pages(pool, page);
freed += (1 << pool->order);
}
--
2.25.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v3 2/2] staging: android: Remove BUG from ion_system_heap.c
Remove BUG() at ion_sytem_heap.c and error handling to:
- free_buffer_page
- alloc_buffer_page
this fix the following checkpatch issue:
Avoid crashing the kernel - try using WARN_ON &
recovery code ratherthan BUG() or BUG_ON().
Signed-off-by: Tomer Samara
---
drivers/staging/android/ion/ion_system_heap.c | 15 ---
1 file changed, 12 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/android/ion/ion_system_heap.c
b/drivers/staging/android/ion/ion_system_heap.c
index eac0632ab4e8..56d53268b82c 100644
--- a/drivers/staging/android/ion/ion_system_heap.c
+++ b/drivers/staging/android/ion/ion_system_heap.c
@@ -30,7 +30,7 @@ static int order_to_index(unsigned int order)
for (i = 0; i < NUM_ORDERS; i++)
if (order == orders[i])
return i;
- BUG();
+
return -1;
}
@@ -48,8 +48,13 @@ static struct page *alloc_buffer_page(struct ion_system_heap
*heap,
struct ion_buffer *buffer,
unsigned long order)
{
- struct ion_page_pool *pool = heap->pools[order_to_index(order)];
+ struct ion_page_pool *pool;
+ int index = order_to_index(order);
+ if (index < 0)
+ return NULL;
+
+ pool = heap->pools[index];
return ion_page_pool_alloc(pool);
}
@@ -58,6 +63,7 @@ static void free_buffer_page(struct ion_system_heap *heap,
{
struct ion_page_pool *pool;
unsigned int order = compound_order(page);
+ int index;
/* go to system */
if (buffer->private_flags & ION_PRIV_FLAG_SHRINKER_FREE) {
@@ -65,8 +71,11 @@ static void free_buffer_page(struct ion_system_heap *heap,
return;
}
- pool = heap->pools[order_to_index(order)];
+ index = order_to_index(order);
+ if (index < 0)
+ return;
+ pool = heap->pools[index];
ion_page_pool_free(pool, page);
}
--
2.25.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 00/49] DRM driver for Hikey 970
On Wed, Aug 19, 2020 at 8:31 AM Laurent Pinchart wrote: > On Wed, Aug 19, 2020 at 05:21:20PM +0200, Sam Ravnborg wrote: > > On Wed, Aug 19, 2020 at 01:45:28PM +0200, Mauro Carvalho Chehab wrote: > > > This patch series port the out-of-tree driver for Hikey 970 (which > > > should also support Hikey 960) from the official 96boards tree: > > > > > >https://github.com/96boards-hikey/linux/tree/hikey970-v4.9 > > > > > > Based on his history, this driver seems to be originally written > > > for Kernel 4.4, and was later ported to Kernel 4.9. The original > > > driver used to depend on ION (from Kernel 4.4) and had its own > > > implementation for FB dev API. > > > > > > As I need to preserve the original history (with has patches from > > > both HiSilicon and from Linaro), I'm starting from the original > > > patch applied there. The remaining patches are incremental, > > > and port this driver to work with upstream Kernel. > > > ... > > > - Due to legal reasons, I need to preserve the authorship of > > > each one responsbile for each patch. So, I need to start from > > > the original patch from Kernel 4.4; ... > > I do acknowledge you need to preserve history and all - > > but this patchset is not easy to review. > > Why do we need to preserve history ? Adding relevant Signed-off-by and > Co-developed-by should be enough, shouldn't it ? Having a public branch > that contains the history is useful if anyone is interested, but I don't > think it's required in mainline. Yea. I concur with Laurent here. I'm not sure what legal reasoning you have on this but preserving the "absolute" history here is actively detrimental for review and understanding of the patch set. Preserving Authorship, Signed-off-by lines and adding Co-developed-by lines should be sufficient to provide both atribution credit and DCO history. thanks -john ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v14 0/2] Add initial support for slimport anx7625
Hi Xin Ji. On Mon, Aug 10, 2020 at 10:35:46PM +0200, Sam Ravnborg wrote: > Hi Xin Ji. > > On Thu, Jul 09, 2020 at 04:31:09PM +0800, Xin Ji wrote: > > Hi all, > > > > The following series add support for the Slimport ANX7625 transmitter, a > > ultra-low power Full-HD 4K MIPI to DP transmitter designed for portable > > device. > > > > > > This is the v14 version, any mistakes, please let me know, I will fix it in > > the next series. > > > > Change history: > > v14: Fix comments from Sam and Nicolas > > - Check flags at drm_bridge_attach > > - Use panel_bridge instead of drm_panel > > - Fix not correct return value > > Sorry for ignoring this for so long time. > The patch applies but no longer builds. > > I could fix it locally but wanted to know if you have a later version to > be applied? I took a short look at the driver today. I noticed following code: if (!(flags & DRM_BRIDGE_ATTACH_NO_CONNECTOR)) return -EINVAL; So if the display driver do not supply the DRM_BRIDGE_ATTACH_NO_CONNECTOR then -EINVAL is returned. But then the anx7625_bridge_attach() continues and creates a connector. For a new bridge driver there should be no need for the backward compatibility - so no need to create the connector. Unless the display driver needs it - but then we should fix the display driver and not add backward compatibility code in the bridge driver. Which display driver do you expect this bridge driver to be used with? Sam > > Sam > > > > > > v13: Fix comments from Launrent Pinchart and Rob Herring > > - Picked up Rob's Reviewed-By > > - Add .detect and .get_edid interface in bridge funcs. > > > > v12: Fix comments from Hsin-Yi Wang > > - Rebase the code on kernel 5.7, fix DRM interface not match issue. > > > > v11: Fix comments from Rob Herring > > - Update commit message. > > - Remove unused label. > > > > v10: Fix comments from Rob Herring, Daniel. > > - Fix dt_binding_check warning. > > - Update description. > > > > v9: Fix comments from Sam, Nicolas, Daniel > > - Remove extcon interface. > > - Remove DPI support. > > - Fix dt_binding_check complains. > > - Code clean up and update description. > > > > v8: Fix comments from Nicolas. > > - Fix several coding format. > > - Update description. > > > > v7: > > - Fix critical timing(eg:odd hfp/hbp) in "mode_fixup" interface, > >enhance MIPI RX tolerance by setting register MIPI_DIGITAL_ADJ_1 to 0x3D. > > > > > > Xin Ji (2): > > dt-bindings: drm/bridge: anx7625: MIPI to DP transmitter DT schema > > drm/bridge: anx7625: Add anx7625 MIPI DSI/DPI to DP > > > > .../bindings/display/bridge/analogix,anx7625.yaml | 95 + > > drivers/gpu/drm/bridge/analogix/Kconfig|9 + > > drivers/gpu/drm/bridge/analogix/Makefile |1 + > > drivers/gpu/drm/bridge/analogix/anx7625.c | 1939 > > > > drivers/gpu/drm/bridge/analogix/anx7625.h | 391 > > 5 files changed, 2435 insertions(+) > > create mode 100644 > > Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml > > create mode 100644 drivers/gpu/drm/bridge/analogix/anx7625.c > > create mode 100644 drivers/gpu/drm/bridge/analogix/anx7625.h > > > > -- > > 2.7.4 > > > > ___ > > dri-devel mailing list > > dri-de...@lists.freedesktop.org > > https://lists.freedesktop.org/mailman/listinfo/dri-devel > ___ > dri-devel mailing list > dri-de...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 00/49] DRM driver for Hikey 970
On Wed, Aug 19, 2020 at 4:46 AM Mauro Carvalho Chehab wrote: > Yet, I'm submitting it via staging due to the following reasons: > > - It depends on the LDO3 power supply, which is provided by > a regulator driver that it is currently on staging; > - Due to legal reasons, I need to preserve the authorship of > each one responsbile for each patch. So, I need to start from > the original patch from Kernel 4.4; > - There are still some problems I need to figure out how to solve: >- The adv7535 can't get EDID data. Maybe it is a timing issue, > but it requires more research to be sure about how to solve it; I've seen this on the HiKey960 as well. There is a patch to the adv7533 driver I have to add a mdelay that seems to consistently resolve the timing problem. At some point I mentioned it to one of the maintainers who seems open to having it added, but it seemed silly to submit it until there was a upstream driver that needed such a change. So I think that patch can be submitted as a follow on to this (hopefully cleaned up) series. >- The driver only accept resolutions on a defined list, as there's > a known bug that this driver may have troubles with random > resolutions. Probably due to a bug at the pixel clock settings; So, yes, the SoC clks can't generate proper signals for HDMI frequencies (apparently it's not an issue for panels). There is a fixed set that we can get "close enough" that most monitors will work, but its always a bit iffy (some monitors are strict in what they take). On the kirin driver, we were able to do a calculation to figure out if the generated frequency would be close enough: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c#n615 I suspect we could do something similar for the hikey960/70, but I've not really had time to dig in deeply there. Personally, I don't see the allow-list as a problematic short term solution, and again, not sure its worth pushing to staging for. >- Sometimes (at least with 1080p), it generates LDI underflow > errors, which in turn causes the DRM to stop working. That > happens for example when using gdm on Wayland and > gnome on X11; Interestingly, I've not seen this on HiKey960 (at least with Android/Surfaceflinger). The original HiKey board does have the trouble where at 1080p the screen sometimes comes up horizontally offset due to the LDI underflow, but the patches to address it have been worse then the problem, so we reverted those. >- Probably related to the previous issue, when the monitor > suspends due to DPMS, it doesn't return back to life. > I don't believe I see this on HiKey960. But if it's the LDI issue on the 970 that may explain it. > So, IMO, the best is to keep it on staging for a while, until those > remaining bugs gets solved. I'm not sure I see all of these as compelling for pushing it in via staging. And I suspect in the process of submitting the patches for review folks may find the cause of some of the problems you list here. > I added this series, together with the regulator driver and > a few other patches (including a hack to fix a Kernel 5.8 > regression at WiFi ) at: > > > https://gitlab.freedesktop.org/mchehab_kernel/hikey-970/-/commits/master > > > Chen Feng (1): > staging: hikey9xx: Add hisilicon DRM driver for hikey960/970 > > John Stultz (1): > staging: hikey9xx/gpu: port it to work with Kernel v4.9 Nit: This is a display driver and has little to do with the GPU (other then it will eventually live in drivers/gpu/drm/...), so I might suggest using more conventional subject prefix, "drm: hisilicon:" thanks -john ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 00/49] DRM driver for Hikey 970
Hi John. > > So, IMO, the best is to keep it on staging for a while, until those > > remaining bugs gets solved. > > I'm not sure I see all of these as compelling for pushing it in via > staging. And I suspect in the process of submitting the patches for > review folks may find the cause of some of the problems you list here. There is a tendency to forget drivers in staging, and with the almost constant refactoring that happens in the drm drivers we would end up fixing this driver when a bot trigger an error. So IMO we need very good reasons to go in via staging. Sam ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 00/49] DRM driver for Hikey 970
On Wed, Aug 19, 2020 at 4:46 AM Mauro Carvalho Chehab wrote: > So, IMO, the best is to keep it on staging for a while, until those > remaining bugs gets solved. > > I added this series, together with the regulator driver and > a few other patches (including a hack to fix a Kernel 5.8 > regression at WiFi ) at: > > > https://gitlab.freedesktop.org/mchehab_kernel/hikey-970/-/commits/master Sorry, one more small request: Could you create a branch that only has the DRM driver changes in it? The reason I ask, is that since the HiKey960 isn't affected by the majority of the problems you listed as motivation for going through staging. So if we can validate that your tree works fine on HiKey960, the series can be cleaned up and submitted properly upstream to enable that SoC, and the outstanding 970 issues can be worked out afterwards against mainline. thanks -john ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] block: convert tasklets to use new tasklet_setup() API
On Wed, 2020-08-19 at 21:54 +0530, Allen wrote: > > [...] > > > > Since both threads seem to have petered out, let me suggest in > > > > kernel.h: > > > > > > > > #define cast_out(ptr, container, member) \ > > > > container_of(ptr, typeof(*container), member) > > > > > > > > It does what you want, the argument order is the same as > > > > container_of with the only difference being you name the > > > > containing structure instead of having to specify its type. > > > > > > Not to incessantly bike shed on the naming, but I don't like > > > cast_out, it's not very descriptive. And it has connotations of > > > getting rid of something, which isn't really true. > > > > Um, I thought it was exactly descriptive: you're casting to the > > outer container. I thought about following the C++ dynamic casting > > style, so out_cast(), but that seemed a bit pejorative. What about > > outer_cast()? > > > > > FWIW, I like the from_ part of the original naming, as it has > > > some clues as to what is being done here. Why not just > > > from_container()? That should immediately tell people what it > > > does without having to look up the implementation, even before > > > this becomes a part of the accepted coding norm. > > > > I'm not opposed to container_from() but it seems a little less > > descriptive than outer_cast() but I don't really care. I always > > have to look up container_of() when I'm using it so this would just > > be another macro of that type ... > > > > So far we have a few which have been suggested as replacement > for from_tasklet() > > - out_cast() or outer_cast() > - from_member(). > - container_from() or from_container() > > from_container() sounds fine, would trimming it a bit work? like > from_cont(). I'm fine with container_from(). It's the same form as container_of() and I think we need urgent agreement to not stall everything else so the most innocuous name is likely to get the widest acceptance. James ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 25/49] staging: hikey9xx/gpu: do some code cleanups
On Wed, Aug 19, 2020 at 4:46 AM Mauro Carvalho Chehab
wrote:
> @@ -376,7 +355,7 @@ static int kirin_drm_platform_resume(struct
> platform_device *pdev)
> }
>
> static const struct of_device_id kirin_drm_dt_ids[] = {
> - { .compatible = "hisilicon,hi3660-dpe",
> + { .compatible = "hisilicon,kirin960-dpe",
One issue, elsewhere in your patch stack you still refer to the
hisilicon,hi3660-dpe compatible string. This should probably be
consistent one way or the other.
thanks
-john
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 00/49] DRM driver for Hikey 970
On Wed, Aug 19, 2020 at 2:36 PM John Stultz wrote: > > On Wed, Aug 19, 2020 at 4:46 AM Mauro Carvalho Chehab > wrote: > > So, IMO, the best is to keep it on staging for a while, until those > > remaining bugs gets solved. > > > > I added this series, together with the regulator driver and > > a few other patches (including a hack to fix a Kernel 5.8 > > regression at WiFi ) at: > > > > > > https://gitlab.freedesktop.org/mchehab_kernel/hikey-970/-/commits/master > > Sorry, one more small request: Could you create a branch that only has > the DRM driver changes in it? > > The reason I ask, is that since the HiKey960 isn't affected by the > majority of the problems you listed as motivation for going through > staging. So if we can validate that your tree works fine on HiKey960, > the series can be cleaned up and submitted properly upstream to enable > that SoC, and the outstanding 970 issues can be worked out afterwards > against mainline. Just as a heads up, I tried testing your tree with my HiKey960, and after fixing the compat string inconsistency, the drivers seem to load properly. However the drm_hwcomposer seems to have some trouble with the driver: 01-01 00:12:41.456 345 345 E hwc-drm-display-compositor: Commit test failed for display 0, FIXME 01-01 00:12:41.456 345 345 E hwc-drm-two: Failed to apply the frame composition ret=-22 01-01 00:12:41.456 351 351 E HWComposer: presentAndGetReleaseFences: present failed for display 0: BadParameter (4) I'll dig in a bit further as to why, but wanted to give you a heads up. thanks -john ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 00/49] DRM driver for Hikey 970
On Wed, Aug 19, 2020 at 7:01 PM John Stultz wrote: > > On Wed, Aug 19, 2020 at 2:36 PM John Stultz wrote: > > > > On Wed, Aug 19, 2020 at 4:46 AM Mauro Carvalho Chehab > > wrote: > > > So, IMO, the best is to keep it on staging for a while, until those > > > remaining bugs gets solved. > > > > > > I added this series, together with the regulator driver and > > > a few other patches (including a hack to fix a Kernel 5.8 > > > regression at WiFi ) at: > > > > > > > > > https://gitlab.freedesktop.org/mchehab_kernel/hikey-970/-/commits/master > > > > Sorry, one more small request: Could you create a branch that only has > > the DRM driver changes in it? > > > > The reason I ask, is that since the HiKey960 isn't affected by the > > majority of the problems you listed as motivation for going through > > staging. So if we can validate that your tree works fine on HiKey960, > > the series can be cleaned up and submitted properly upstream to enable > > that SoC, and the outstanding 970 issues can be worked out afterwards > > against mainline. > > Just as a heads up, I tried testing your tree with my HiKey960, and > after fixing the compat string inconsistency, the drivers seem to load > properly. However the drm_hwcomposer seems to have some trouble with > the driver: > 01-01 00:12:41.456 345 345 E hwc-drm-display-compositor: Commit > test failed for display 0, FIXME > 01-01 00:12:41.456 345 345 E hwc-drm-two: Failed to apply the > frame composition ret=-22 > 01-01 00:12:41.456 351 351 E HWComposer: > presentAndGetReleaseFences: present failed for display 0: BadParameter > (4) > > I'll dig in a bit further as to why, but wanted to give you a heads up. Ok, I've mostly gotten it sorted out: - You're missing a few color formats. - And I re-discovered a crash that was already fixed in my tree. I'll send those patches in a few here. That said even with the patches I've got on top of your series, I still see a few issues: 1) I'm seeing red-blue swap with your driver. I need to dig a bit to see what the difference is, I know gralloc has a config option for this, and maybe the version of the driver I'm carrying has it wrong? 2) Performance is noticeably worse. Whereas with my tree, I see close to 60fps (that clk issue we mentioned earlier is why it's not exactly 60) in most tests, but with yours it mostly hovers around 30some fps, occasionally speeding up to 40 and then back down. Obviously with some work I suspect we'll be able to sort these out, but I also do feel that the set you're starting with for upstreaming is pretty old. The driver I'm carrying was heavily refactored around 5.0 to share code with the existing kirin driver, in the hopes of making usptreaming easier, and it seems a shame to throw that out and focus your efforts on the older tree. But to be fair, I've not had time to upstream the driver myself, and it's obviously your choice on how you spend your time. I am really excited to see your efforts here, regardless of which driver you end up pushing. thanks -john ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 00/49] DRM driver for Hikey 970
Em Wed, 19 Aug 2020 14:13:05 -0700 John Stultz escreveu: > On Wed, Aug 19, 2020 at 4:46 AM Mauro Carvalho Chehab > wrote: > > Yet, I'm submitting it via staging due to the following reasons: > > > > - It depends on the LDO3 power supply, which is provided by > > a regulator driver that it is currently on staging; > > - Due to legal reasons, I need to preserve the authorship of > > each one responsbile for each patch. So, I need to start from > > the original patch from Kernel 4.4; > > - There are still some problems I need to figure out how to solve: > >- The adv7535 can't get EDID data. Maybe it is a timing issue, > > but it requires more research to be sure about how to solve it; > > I've seen this on the HiKey960 as well. There is a patch to the > adv7533 driver I have to add a mdelay that seems to consistently > resolve the timing problem. At some point I mentioned it to one of > the maintainers who seems open to having it added, but it seemed silly > to submit it until there was a upstream driver that needed such a > change. So I think that patch can be submitted as a follow on to this > (hopefully cleaned up) series. Yeah, I saw that mdelay() patch on your tree. While it should be cheap to add a mdelay() or udelay_range() there, I'm not sure if this is just a timing issue or if something else is missing. The 4.9 driver does some extra setups on adv7535 (see the enclosed patch). I'm wondering if something from that is missing. Btw, IMHO, one interesting setting on the downstream code is support for colorbar test. This was helpful when I was making this driver work upstream, as it could be useful for someone trying to make some other DRM driver using it. > > >- The driver only accept resolutions on a defined list, as there's > > a known bug that this driver may have troubles with random > > resolutions. Probably due to a bug at the pixel clock settings; > > So, yes, the SoC clks can't generate proper signals for HDMI > frequencies (apparently it's not an issue for panels). There is a > fixed set that we can get "close enough" that most monitors will work, > but its always a bit iffy (some monitors are strict in what they > take). There is an extra logic for Kirin 620 that seems to be validating the frequencies that would be set to the clocks. If they're out of the range, it would return MODE_BAD. I suspect that something similar would be needed for Kirin 970 and 960. With that regards, 970 is different from 960. I actually tried to write a patch for it, but I guess there are still some things missing on my code, for 970. This patch: https://gitlab.freedesktop.org/mchehab_kernel/hikey-970/-/commit/4614415770b33e27a9f15c7dde20895fb750592f Splits the part of the code which calculates the clk_Hz from the part which sets it. So, now, dss_calculate_clock() checks the pixel clock frequency and adjusts it, if needed. I have another patch that were checking if the code modified the clock_Hz at dss_crtc_mode_fixup(). With that, it would be easy to return MODE_INVALID if something bad happens. However, such patch didn't work as I would expect, so I ended dropping it. > On the kirin driver, we were able to do a calculation to figure out if > the generated frequency would be close enough: > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c#n615 > > I suspect we could do something similar for the hikey960/70, but I've > not really had time to dig in deeply there. Yeah, I tried something similar to that. Maybe it will work properly for Hikey 960, but Hikey 970 has a much more complex code to setup the pixel clock. On 960, just one clock is set: clk_set_rate(ctx->dss_pxl0_clk, clk_Hz); While, on 970, pxl0 is always set to the same frequency (144 MHz), at least for pixel clocks up to 255 MHz[1], but the code do some complex calculus to setup PLL7 registers using the clock frequency. [1] pixel clocks above 255 MHz will be rejected anyway, as they'll return MODE_BAD due to the checks if a mode is valid. > > Personally, I don't see the allow-list as a problematic short term > solution, and again, not sure its worth pushing to staging for. Yeah, I guess we can live with that for a while. > > >- Sometimes (at least with 1080p), it generates LDI underflow > > errors, which in turn causes the DRM to stop working. That > > happens for example when using gdm on Wayland and > > gnome on X11; > > Interestingly, I've not seen this on HiKey960 (at least with > Android/Surfaceflinger). Here, it happens all the time when the monitor returns back from DPMS suspend. It also happens on some specific cases (X11 x Wayland), console mode + startx, etc. It sounds to me that it occurs when the driver tries to setup a new resolution. Maybe something needs to be disabled before changing res (and re-enabled afterwards). > The original HiKey board does have the > trouble whe
Re: [PATCH 00/49] DRM driver for Hikey 970
Em Wed, 19 Aug 2020 23:25:51 +0200 Sam Ravnborg escreveu: > Hi John. > > > > So, IMO, the best is to keep it on staging for a while, until those > > > remaining bugs gets solved. > > > > I'm not sure I see all of these as compelling for pushing it in via > > staging. And I suspect in the process of submitting the patches for > > review folks may find the cause of some of the problems you list here. > > There is a tendency to forget drivers in staging, and with the almost > constant refactoring that happens in the drm drivers we would end up > fixing this driver when a bot trigger an error. > So IMO we need very good reasons to go in via staging. My plan is to have this driver upstream for 5.10, and getting it out of staging by Kernel 5.11. So, I doubt that the DRM kAPIs would change a lot during those 2 Kernel cycles. In any case, I'm also fine to have a final patch at the end of this series moving it out of staging. The only thing that, IMHO, prevents it to be out of staging is the LDI underflow. Right now, if no input events reach the driver, DPMS will put the monitor to suspend, and it never returns back from life. I bet that, once we discover the root cause, the fix would be just a couple of lines, but identifying where the problem is can take a while. Thanks, Mauro ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
