Re: [PATCH] drm/msm/mdp5: Fix wait-for-commit for cmd panels
On Wed, Jan 27, 2021 at 05:24:40PM +0200, Iskren Chernev wrote:
> Before the offending commit in msm_atomic_commit_tail wait_flush was
> called once per frame, after the commit was submitted. After it
> wait_flush is also called at the beginning to ensure previous
> potentially async commits are done.
>
> For cmd panels the source of wait_flush is a ping-pong irq notifying
> a completion. The completion needs to be notified with complete_all so
> multiple waiting parties (new async committers) can proceed.
>
> Signed-off-by: Iskren Chernev
> Suggested-by: Rob Clark
> Fixes: 2d99ced787e3d ("drm/msm: async commit support")
Nice job tracking down this fix!
Reviewed-by: Brian Masney
Tested-by: Brian Masney
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v1 1/1] backlight: lm3630a_bl: Put fwnode in error case during ->probe()
On Mon, May 10, 2021 at 12:57:16PM +0300, Andy Shevchenko wrote:
> device_for_each_child_node() bumps a reference counting of a returned
> variable.
> We have to balance it whenever we return to the caller.
>
> Fixes: 8fbce8efe15cd ("backlight: lm3630a: Add firmware node support")
> Cc: Brian Masney
> Cc: Dan Murphy
> Signed-off-by: Andy Shevchenko
Reviewed-by: Brian Masney
Re: [PATCH] drm: Don't make DRM_PANEL_BRIDGE dependent on DRM_KMS_HELPERS
On Tue, Mar 15, 2022 at 09:45:59AM +0100, Thomas Zimmermann wrote:
> Fix a number of undefined references to drm_kms_helper.ko in
> drm_dp_helper.ko:
>
> arm-suse-linux-gnueabi-ld: drivers/gpu/drm/dp/drm_dp_mst_topology.o: in
> function `drm_dp_mst_duplicate_state':
> drm_dp_mst_topology.c:(.text+0x2df0): undefined reference to
> `__drm_atomic_helper_private_obj_duplicate_state'
> arm-suse-linux-gnueabi-ld: drivers/gpu/drm/dp/drm_dp_mst_topology.o: in
> function `drm_dp_delayed_destroy_work':
> drm_dp_mst_topology.c:(.text+0x370c): undefined reference to
> `drm_kms_helper_hotplug_event'
> arm-suse-linux-gnueabi-ld: drivers/gpu/drm/dp/drm_dp_mst_topology.o: in
> function `drm_dp_mst_up_req_work':
> drm_dp_mst_topology.c:(.text+0x7938): undefined reference to
> `drm_kms_helper_hotplug_event'
> arm-suse-linux-gnueabi-ld: drivers/gpu/drm/dp/drm_dp_mst_topology.o: in
> function `drm_dp_mst_link_probe_work':
> drm_dp_mst_topology.c:(.text+0x82e0): undefined reference to
> `drm_kms_helper_hotplug_event'
>
> This happens if panel-edp.ko has been configured with
>
> DRM_PANEL_EDP=y
> DRM_DP_HELPER=y
> DRM_KMS_HELPER=m
>
> which builds DP helpers into the kernel and KMS helpers sa a module.
> Making DRM_PANEL_EDP select DRM_KMS_HELPER resolves this problem.
>
> To avoid a resulting cyclic dependency with DRM_PANEL_BRIDGE, don't
> make the latter depend on DRM_KMS_HELPER and fix the one DRM bridge
> drivers that doesn't already select DRM_KMS_HELPER. As KMS helpers
> cannot be selected directly by the user, config symbols should avoid
> depending on it anyway.
>
> Signed-off-by: Thomas Zimmermann
> Fixes: 3755d35ee1d2 ("drm/panel: Select DRM_DP_HELPER for DRM_PANEL_EDP")
> Reported-by: kernel test robot
> Cc: Thomas Zimmermann
> Cc: Naresh Kamboju
> Cc: Linux Kernel Functional Testing
> Cc: Lyude Paul
> Cc: Sam Ravnborg
> Cc: Daniel Vetter
> Cc: Maarten Lankhorst
> Cc: Maxime Ripard
> Cc: dri-devel@lists.freedesktop.org
> Cc: Dave Airlie
> Cc: Thierry Reding
This patch fixes the build error that I see with qcom_defconfig in
linux-next.
Tested-by: Brian Masney
Re: [PATCH 1/2] drm/msm: Call msm_init_vram before binding the gpu
On Wed, Dec 30, 2020 at 05:29:42PM +0200, Iskren Chernev wrote: > From: Craig Tatlor > > vram.size is needed when binding a gpu without an iommu and is defined > in msm_init_vram(), so run that before binding it. > > Signed-off-by: Craig Tatlor For the series: Reviewed-by: Brian Masney Next time, please include a cover letter so that tags added to the cover letter can be applied to all patches in the series via patchwork. Brian ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6 1/3] backlight: lm3630a: return 0 on success in update_status functions
On Thu, May 02, 2019 at 11:07:51AM +0100, Daniel Thompson wrote:
> On 24/04/2019 10:25, Brian Masney wrote:
> > lm3630a_bank_a_update_status() and lm3630a_bank_b_update_status()
> > both return the brightness value if the brightness was successfully
> > updated. Writing to these attributes via sysfs would cause a 'Bad
> > address' error to be returned. These functions should return 0 on
> > success, so let's change it to correct that error.
> >
> > Signed-off-by: Brian Masney
> > Fixes: 28e64a68a2ef ("backlight: lm3630: apply chip revision")
> > Acked-by: Pavel Machek
>
> Hi Brian, sorry for the delay. For some reason your mails are being dumped
> before they reach me so I only discovered these patches when I paid proper
> attention to the replies and fetched them from patchwork.
>
> Hi Lee, is the same thing happening for you? ;-)
Huh, that's odd. I haven't ran into that issue when working with people
from Linaro in other subsystems.
As a sanity check, I used 'git send-email' to send this patch to
check-a...@verifier.port25.com and it verified that I still have SPF,
DKIM, reverse DNS, etc. all setup properly on this domain.
hotmail.com addresses are the only ones I've had issues with in the
past, but I doubt you're forwarding your email there. :)
Brian
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6 3/3] backlight: lm3630a: add firmware node support
On Thu, May 02, 2019 at 11:19:50AM +0100, Daniel Thompson wrote: > On 24/04/2019 10:25, Brian Masney wrote: > > Add fwnode support to the lm3630a driver and optionally allow > > configuring the label, default brightness level, and maximum brightness > > level. The two outputs can be controlled by bank A and B independently > > or bank A can control both outputs. > > > > If the platform data was not configured, then the driver defaults to > > enabling both banks. This patch changes the default value to disable > > both banks before parsing the firmware node so that just a single bank > > can be enabled if desired. There are no in-tree users of this driver. > > In that case given I'd certainly entertain patches that move the config > structures out of include/linux/platform_data and say the driver requires a > proper entry in the hardware description! Not a requirement though. OK, I'll submit patches for that after this series is merged. Brian ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH RFC 2/6] drm/msm: add dirty framebuffer helper
Add drm_atomic_helper_dirtyfb() callback to the msm framebuffer driver
for the dirty ioctl.
Signed-off-by: Brian Masney
---
drivers/gpu/drm/msm/msm_fb.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/msm/msm_fb.c b/drivers/gpu/drm/msm/msm_fb.c
index 136058978e0f..8624a8e4025f 100644
--- a/drivers/gpu/drm/msm/msm_fb.c
+++ b/drivers/gpu/drm/msm/msm_fb.c
@@ -16,6 +16,7 @@
*/
#include
+#include
#include
#include
@@ -35,6 +36,7 @@ static struct drm_framebuffer *msm_framebuffer_init(struct
drm_device *dev,
static const struct drm_framebuffer_funcs msm_framebuffer_funcs = {
.create_handle = drm_gem_fb_create_handle,
.destroy = drm_gem_fb_destroy,
+ .dirty = drm_atomic_helper_dirtyfb,
};
#ifdef CONFIG_DEBUG_FS
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH RFC 1/6] drm/msm: fix null pointer dereference in msm_atomic_prepare_fb()
_msm_gem_new() calls msm_gem_new_impl() with a NULL reservation_object
struct. msm_atomic_prepare_fb() assumes that the reservation_object is
always set, and attempts to reference a NULL pointer. Correct this by
checking to see if this value is NULL.
Signed-off-by: Brian Masney
---
drivers/gpu/drm/msm/msm_atomic.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm_atomic.c b/drivers/gpu/drm/msm/msm_atomic.c
index f5b1256e32b6..0da80a93876a 100644
--- a/drivers/gpu/drm/msm/msm_atomic.c
+++ b/drivers/gpu/drm/msm/msm_atomic.c
@@ -56,10 +56,12 @@ int msm_atomic_prepare_fb(struct drm_plane *plane,
return 0;
obj = msm_framebuffer_bo(new_state->fb, 0);
- msm_obj = to_msm_bo(obj);
- fence = reservation_object_get_excl_rcu(msm_obj->resv);
- drm_atomic_set_fence_for_plane(new_state, fence);
+ msm_obj = to_msm_bo(obj);
+ if (msm_obj->resv) {
+ fence = reservation_object_get_excl_rcu(msm_obj->resv);
+ drm_atomic_set_fence_for_plane(new_state, fence);
+ }
return msm_framebuffer_prepare(new_state->fb, kms->aspace);
}
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH RFC 5/6] ARM: dts: qcom: msm8974-hammerhead: add support for backlight
Add necessary device tree nodes for the main LCD backlight.
Signed-off-by: Brian Masney
---
This requires this series that I submitted to the LED / backlight
subsystem:
https://lore.kernel.org/lkml/20190424092505.6578-1-masn...@onstation.org/
It's received 3 {Reviewed,Acked}-Bys, and has no outstanding change
requests, so I expect it'll be merged soon.
.../qcom-msm8974-lge-nexus5-hammerhead.dts| 34 +++
1 file changed, 34 insertions(+)
diff --git a/arch/arm/boot/dts/qcom-msm8974-lge-nexus5-hammerhead.dts
b/arch/arm/boot/dts/qcom-msm8974-lge-nexus5-hammerhead.dts
index b3b04736a159..b7cf4b1019e9 100644
--- a/arch/arm/boot/dts/qcom-msm8974-lge-nexus5-hammerhead.dts
+++ b/arch/arm/boot/dts/qcom-msm8974-lge-nexus5-hammerhead.dts
@@ -289,6 +289,16 @@
};
};
+ i2c11_pins: i2c11 {
+ mux {
+ pins = "gpio83", "gpio84";
+ function = "blsp_i2c11";
+
+ drive-strength = <2>;
+ bias-disable;
+ };
+ };
+
i2c12_pins: i2c12 {
mux {
pins = "gpio87", "gpio88";
@@ -369,6 +379,30 @@
};
};
+ i2c@f9967000 {
+ status = "ok";
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c11_pins>;
+ clock-frequency = <355000>;
+ qcom,src-freq = <5000>;
+
+ led-controller@38 {
+ compatible = "ti,lm3630a";
+ status = "ok";
+ reg = <0x38>;
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ led@0 {
+ reg = <0>;
+ led-sources = <0 1>;
+ label = "lcd-backlight";
+ default-brightness = <200>;
+ };
+ };
+ };
+
i2c@f9968000 {
status = "ok";
pinctrl-names = "default";
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH RFC 4/6] ARM: dts: msm8974: add display support
Add the MDP5, DSI and DSI PHY blocks for the display found on the
msm8974 SoCs. This is based on work from msm8916.dtsi and Jonathan
Marek.
Signed-off-by: Brian Masney
---
arch/arm/boot/dts/qcom-msm8974.dtsi | 132
1 file changed, 132 insertions(+)
diff --git a/arch/arm/boot/dts/qcom-msm8974.dtsi
b/arch/arm/boot/dts/qcom-msm8974.dtsi
index 45b5c8ef0374..3f613c5b95a1 100644
--- a/arch/arm/boot/dts/qcom-msm8974.dtsi
+++ b/arch/arm/boot/dts/qcom-msm8974.dtsi
@@ -3,6 +3,7 @@
#include
#include
+#include
#include
#include
#include
@@ -1085,6 +1086,137 @@
};
};
};
+
+ mdss: mdss@fd90 {
+ status = "disabled";
+
+ compatible = "qcom,mdss";
+ reg = <0xfd90 0x100>,
+ <0xfd924000 0x1000>;
+ reg-names = "mdss_phys",
+ "vbif_phys";
+
+ power-domains = <&mmcc MDSS_GDSC>;
+
+ clocks = <&mmcc MDSS_AHB_CLK>,
+<&mmcc MDSS_AXI_CLK>,
+<&mmcc MDSS_VSYNC_CLK>;
+ clock-names = "iface",
+ "bus",
+ "vsync";
+
+ interrupts = ;
+
+ interrupt-controller;
+ #interrupt-cells = <1>;
+
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ mdp: mdp@fd90 {
+ status = "disabled";
+
+ compatible = "qcom,mdp5";
+ reg = <0xfd900100 0x22000>;
+ reg-names = "mdp_phys";
+
+ interrupt-parent = <&mdss>;
+ interrupts = <0 0>;
+
+ clocks = <&mmcc MDSS_AHB_CLK>,
+<&mmcc MDSS_AXI_CLK>,
+<&mmcc MDSS_MDP_CLK>,
+<&mmcc MDSS_VSYNC_CLK>;
+ clock-names = "iface",
+ "bus",
+ "core",
+ "vsync";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ mdp5_intf1_out: endpoint {
+ remote-endpoint =
<&dsi0_in>;
+ };
+ };
+ };
+ };
+
+ dsi0: dsi@fd922800 {
+ status = "disabled";
+
+ compatible = "qcom,mdss-dsi-ctrl";
+ reg = <0xfd922800 0x1f8>;
+ reg-names = "dsi_ctrl";
+
+ interrupt-parent = <&mdss>;
+ interrupts = <4 IRQ_TYPE_LEVEL_HIGH>;
+
+ assigned-clocks = <&mmcc BYTE0_CLK_SRC>,
+ <&mmcc PCLK0_CLK_SRC>;
+ assigned-clock-parents = <&dsi_phy0 0>,
+<&dsi_phy0 1>;
+
+ clocks = <&mmcc MDSS_MDP_CLK>,
+<&mmcc MDSS_AHB_CLK>,
+<&mmcc MDSS_AXI_CLK>,
+<&mmcc MDSS_BYTE0_CLK>,
+<&mmcc MDSS_PCLK0_CLK>,
+<&mmcc MDSS_ESC0_CLK>,
+<&mmcc MMSS_MISC_AHB_CLK>;
+ clock-names = "mdp_core",
+ "iface",
+ "bus",
+ &quo
[PATCH RFC 0/6] ARM: qcom: initial Nexus 5 display support
Here is a patch series that adds initial display support for the LG Nexus 5 (hammerhead) phone. The board boots into terminal mode, however there is a several second (or more) delay when writing to tty1 compared to when the changes are actually shown on the screen. The following errors are in dmesg: msm fd90.mdss: pp done time out, lm=0 [drm:drm_atomic_helper_wait_for_dependencies] *ERROR* [CRTC:49:crtc-0] flip_done timed out [drm:drm_atomic_helper_wait_for_dependencies] *ERROR* [PLANE:32:plane-0] flip_done timed out mdp5_get_scanoutpos() and mdp5_get_vblank_counter() both return 0, which is causing this stack trace to be dumped into the system log several times: WARNING: CPU: 0 PID: 5 at drivers/gpu/drm/drm_atomic_helper.c:1430 drm_atomic_helper_wait_for_vblanks.part.1+0x288/0x290 [CRTC:49:crtc-0] vblank wait timed out Modules linked in: CPU: 0 PID: 5 Comm: kworker/0:0 Not tainted 5.1.0-rc6-next-20190426-6-g35c0d32a96e1-dirty #191 Hardware name: Generic DT based system Workqueue: events deferred_probe_work_func [] (unwind_backtrace) from [] (show_stack+0x10/0x14) [] (show_stack) from [] (dump_stack+0x78/0x8c) [] (dump_stack) from [] (__warn.part.3+0xb8/0xd4) [] (__warn.part.3) from [] (warn_slowpath_fmt+0x64/0x88) [] (warn_slowpath_fmt) from [] (drm_atomic_helper_wait_for_vblanks.part.1+0x288/0x290) [] (drm_atomic_helper_wait_for_vblanks.part.1) from [] (mdp5_complete_commit+0x14/0x40) [] (mdp5_complete_commit) from [] (msm_atomic_commit_tail+0xa8/0x140) [] (msm_atomic_commit_tail) from [] (commit_tail+0x40/0x6c) [] (drm_atomic_helper_commit) from [] (restore_fbdev_mode_atomic+0x168/0x1d4) In mdp5_irq(), I see that a few vblank IRQ statuses (0x1000) come through when the board boots, drm_handle_vblank() is called, and the screen updates, however mdp5_get_scanoutpos() continues to return 0 after these operations complete. I don't see any ping-pong done IRQ statuses (0x100) come through in mdp5_irq(). I can get the text console to work with a 4.17 kernel with this patch https://patchwork.kernel.org/patch/10321845/ plus about a dozen or more other patches that have been mainlined since that release. The pp done and vblank messages still happen, however tty1 is updated when I write to it and Wayland works. The lg,acx467akm-7 panel listed below is currently handled by the simple panel driver since it is sufficient for 4.17 kernel, but that may need to change in the future for the power on commands. To be sure, I followed the instructions at https://github.com/freedreno/freedreno/wiki/DSI-Panel-Driver-Porting for porting the almost 400 panel on commands from the downstream kernel sources at https://github.com/AICP/kernel_lge_hammerhead/blob/n7.1/arch/arm/boot/dts/msm8974-hammerhead/msm8974-hammerhead-panel.dtsi#L645. The screen turns all white when the panel display is turned on and the panel exits sleep mode. Unfortunately, there are a lot of power on commands listed in the downstream device tree that aren't listed in mipi_display.h. Thanks in advance for any advice that you can provide. Brian Masney (6): drm/msm: fix null pointer dereference in msm_atomic_prepare_fb() drm/msm: add dirty framebuffer helper ARM: qcom_defconfig: add display-related options ARM: dts: msm8974: add display support ARM: dts: qcom: msm8974-hammerhead: add support for backlight ARM: dts: qcom: msm8974-hammerhead: add support for display .../qcom-msm8974-lge-nexus5-hammerhead.dts| 79 +++ arch/arm/boot/dts/qcom-msm8974.dtsi | 132 ++ arch/arm/configs/qcom_defconfig | 5 + drivers/gpu/drm/msm/msm_atomic.c | 8 +- drivers/gpu/drm/msm/msm_fb.c | 2 + 5 files changed, 223 insertions(+), 3 deletions(-) -- 2.20.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH RFC 3/6] ARM: qcom_defconfig: add display-related options
Add the CMA (Contiguous Memory Allocator) for the MSM DRM driver, the simple panel, and the TI LM3630A driver in order to support the display on the LG Nexus 5 (hammerhead) phone. Signed-off-by: Brian Masney --- The panel and backlight are currently compiled into the kernel, but will be moved to be modules once the display is fully working in a later verison of this patch series. arch/arm/configs/qcom_defconfig | 5 + 1 file changed, 5 insertions(+) diff --git a/arch/arm/configs/qcom_defconfig b/arch/arm/configs/qcom_defconfig index c1854751c99a..4f02636f832e 100644 --- a/arch/arm/configs/qcom_defconfig +++ b/arch/arm/configs/qcom_defconfig @@ -37,6 +37,7 @@ CONFIG_ARM_CPUIDLE=y CONFIG_VFP=y CONFIG_NEON=y # CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS is not set +CONFIG_CMA=y CONFIG_NET=y CONFIG_PACKET=y CONFIG_UNIX=y @@ -146,12 +147,14 @@ CONFIG_REGULATOR_QCOM_SMD_RPM=y CONFIG_REGULATOR_QCOM_SPMI=y CONFIG_MEDIA_SUPPORT=y CONFIG_DRM=y +CONFIG_DRM_PANEL_SIMPLE=y CONFIG_FB=y CONFIG_FRAMEBUFFER_CONSOLE=y CONFIG_BACKLIGHT_LCD_SUPPORT=y # CONFIG_LCD_CLASS_DEVICE is not set CONFIG_BACKLIGHT_CLASS_DEVICE=y # CONFIG_BACKLIGHT_GENERIC is not set +CONFIG_BACKLIGHT_LM3630A=y CONFIG_BACKLIGHT_LP855X=y CONFIG_SOUND=y CONFIG_SND=y @@ -262,6 +265,8 @@ CONFIG_NLS_CODEPAGE_437=y CONFIG_NLS_ASCII=y CONFIG_NLS_ISO8859_1=y CONFIG_NLS_UTF8=y +CONFIG_DMA_CMA=y +CONFIG_CMA_SIZE_MBYTES=256 CONFIG_PRINTK_TIME=y CONFIG_DYNAMIC_DEBUG=y CONFIG_DEBUG_INFO=y -- 2.20.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH RFC 6/6] ARM: dts: qcom: msm8974-hammerhead: add support for display
Add initial support for the display found on the LG Nexus 5 (hammerhead)
phone.
Signed-off-by: Brian Masney
---
See the cover letter on this patch series for details about the issue
that I'm running into with this board.
.../qcom-msm8974-lge-nexus5-hammerhead.dts| 45 +++
1 file changed, 45 insertions(+)
diff --git a/arch/arm/boot/dts/qcom-msm8974-lge-nexus5-hammerhead.dts
b/arch/arm/boot/dts/qcom-msm8974-lge-nexus5-hammerhead.dts
index b7cf4b1019e9..749226e18ab5 100644
--- a/arch/arm/boot/dts/qcom-msm8974-lge-nexus5-hammerhead.dts
+++ b/arch/arm/boot/dts/qcom-msm8974-lge-nexus5-hammerhead.dts
@@ -500,6 +500,51 @@
};
};
};
+
+ mdss@fd90 {
+ status = "ok";
+
+ mdp@fd90 {
+ status = "ok";
+ };
+
+ dsi@fd922800 {
+ status = "ok";
+
+ vdda-supply = <&pm8941_l2>;
+ vdd-supply = <&pm8941_lvs3>;
+ vddio-supply = <&pm8941_l12>;
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ports {
+ port@1 {
+ endpoint {
+ remote-endpoint = <&panel_in>;
+ data-lanes = <0 1 2 3>;
+ };
+ };
+ };
+
+ panel: panel@0 {
+ reg = <0>;
+ compatible = "lg,acx467akm-7";
+
+ port {
+ panel_in: endpoint {
+ remote-endpoint = <&dsi0_out>;
+ };
+ };
+ };
+ };
+
+ dsi-phy@fd922a00 {
+ status = "ok";
+
+ vddio-supply = <&pm8941_l12>;
+ };
+ };
};
&spmi_bus {
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH RFC 0/6] ARM: qcom: initial Nexus 5 display support
On Mon, May 06, 2019 at 08:42:36AM +0200, Linus Walleij wrote: > On Sun, May 5, 2019 at 3:04 PM Brian Masney wrote: > > > mdp5_get_scanoutpos() and mdp5_get_vblank_counter() both return 0, which > > is causing this stack trace to be dumped into the system log several > > times: > > > > WARNING: CPU: 0 PID: 5 at drivers/gpu/drm/drm_atomic_helper.c:1430 > > drm_atomic_helper_wait_for_vblanks.part.1+0x288/0x290 > > [CRTC:49:crtc-0] vblank wait timed out > > Modules linked in: > > CPU: 0 PID: 5 Comm: kworker/0:0 Not tainted > > 5.1.0-rc6-next-20190426-6-g35c0d32a96e1-dirty #191 > > Hardware name: Generic DT based system > > Workqueue: events deferred_probe_work_func > > [] (unwind_backtrace) from [] (show_stack+0x10/0x14) > > [] (show_stack) from [] (dump_stack+0x78/0x8c) > > [] (dump_stack) from [] (__warn.part.3+0xb8/0xd4) > > [] (__warn.part.3) from [] > > (warn_slowpath_fmt+0x64/0x88) > > [] (warn_slowpath_fmt) from [] > > (drm_atomic_helper_wait_for_vblanks.part.1+0x288/0x290) > > [] (drm_atomic_helper_wait_for_vblanks.part.1) from > > [] (mdp5_complete_commit+0x14/0x40) > > [] (mdp5_complete_commit) from [] > > (msm_atomic_commit_tail+0xa8/0x140) > > [] (msm_atomic_commit_tail) from [] > > (commit_tail+0x40/0x6c) > > [] (drm_atomic_helper_commit) from [] > > (restore_fbdev_mode_atomic+0x168/0x1d4) > > I recently merged this patch: > https://cgit.freedesktop.org/drm/drm-misc/commit/?id=b3198c38f02d54a5e964258a2180d502abe6eaf0 > > I noticed that DSI is sometimes way slower than a monitor, even in HS mode. > On the MCDE this happened on the first screen update, which was slower > than 50ms. > > Check if your vblanks are simply slow, try bumping this timeout even higher, > I spent weeks finding this issue which boils down to an assumption that > the vblank will be fired from something like a monitor at 50 or 60 HZ > ~20 ms so 50ms seemed like a good timeout at the time. > > On a DSI display this is dubious, absolutely in LP mode, and even > in HS mode. That did not fix the issue for me, and I went as high as 5 seconds. That's good to know though since I would have likely ran into that same issue down the line. Brian ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH RFC v2 0/6] ARM: qcom: initial Nexus 5 display support
Here is a patch series that adds initial display support for the LG Nexus 5 (hammerhead) phone. It's not fully working so that's why some of these patches are RFC until we can get it fully working. The phones boots into terminal mode, however there is a several second (or more) delay when writing to tty1 compared to when the changes are actually shown on the screen. The following errors are in dmesg: [drm:drm_atomic_helper_wait_for_dependencies] *ERROR* [CRTC:49:crtc-0] flip_done timed out [drm:drm_atomic_helper_wait_for_dependencies] *ERROR* [PLANE:32:plane-0] flip_done timed out WARNING: CPU: 0 PID: 5 at drivers/gpu/drm/drm_atomic_helper.c:1430 drm_atomic_helper_wait_for_vblanks.part.1+0x288/0x290 [CRTC:49:crtc-0] vblank wait timed out Modules linked in: CPU: 0 PID: 5 Comm: kworker/0:0 Not tainted 5.1.0-rc6-next-20190426-6-g35c0d32a96e1-dirty #191 Hardware name: Generic DT based system Workqueue: events deferred_probe_work_func [] (unwind_backtrace) from [] (show_stack+0x10/0x14) [] (show_stack) from [] (dump_stack+0x78/0x8c) [] (dump_stack) from [] (__warn.part.3+0xb8/0xd4) [] (__warn.part.3) from [] (warn_slowpath_fmt+0x64/0x88) [] (warn_slowpath_fmt) from [] (drm_atomic_helper_wait_for_vblanks.part.1+0x288/0x290) [] (drm_atomic_helper_wait_for_vblanks.part.1) from [] (mdp5_complete_commit+0x14/0x40) [] (mdp5_complete_commit) from [] (msm_atomic_commit_tail+0xa8/0x140) [] (msm_atomic_commit_tail) from [] (commit_tail+0x40/0x6c) [] (drm_atomic_helper_commit) from [] (restore_fbdev_mode_atomic+0x168/0x1d4) I can get the text console to work with a 4.17 kernel with this patch https://patchwork.kernel.org/patch/10321845/ plus about a dozen or more other patches that have been mainlined since that release. I'm new to the DRM subsystem and continuing to dig into the issue, however I'd appreciate any suggestions. I suspect the issue lies somewhere in the second patch in this series. Changes since v1: - Shortened problem description above. I'll reply to this email and send a full dmesg with the boot log with debugging turned on. - Dropped patch 'fix null pointer dereference in msm_atomic_prepare_fb()' - New patch: Remove resv fields from msm_gem_object struct that was incorrectly being referenced by the prepare_fb callbacks. - Add drm_plane_enable_fb_damage_clips() to plane init for mdp4, mdp5, and dpu1. - Add Linus Walleij's reviewed-by to patches 3-6 Brian Masney (6): drm: msm: remove resv fields from msm_gem_object struct drm: msm: add dirty framebuffer helper ARM: qcom_defconfig: add display-related options ARM: dts: msm8974: add display support ARM: dts: qcom: msm8974-hammerhead: add support for backlight ARM: dts: qcom: msm8974-hammerhead: add support for display .../qcom-msm8974-lge-nexus5-hammerhead.dts| 79 +++ arch/arm/boot/dts/qcom-msm8974.dtsi | 132 ++ arch/arm/configs/qcom_defconfig | 5 + drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 7 +- drivers/gpu/drm/msm/disp/mdp4/mdp4_plane.c| 3 + drivers/gpu/drm/msm/disp/mdp5/mdp5_plane.c| 3 + drivers/gpu/drm/msm/msm_atomic.c | 4 +- drivers/gpu/drm/msm/msm_fb.c | 2 + drivers/gpu/drm/msm/msm_gem.c | 3 - drivers/gpu/drm/msm/msm_gem.h | 4 - 10 files changed, 229 insertions(+), 13 deletions(-) -- 2.20.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH RFC 4/6] ARM: dts: msm8974: add display support
On Mon, May 06, 2019 at 11:39:02PM -0700, Bjorn Andersson wrote: > On Sun 05 May 06:04 PDT 2019, Brian Masney wrote: > > diff --git a/arch/arm/boot/dts/qcom-msm8974.dtsi > > b/arch/arm/boot/dts/qcom-msm8974.dtsi > [..] > > + clocks = <&mmcc MDSS_MDP_CLK>, > > +<&mmcc MDSS_AHB_CLK>, > > +<&mmcc MDSS_AXI_CLK>, > > +<&mmcc MDSS_BYTE0_CLK>, > > +<&mmcc MDSS_PCLK0_CLK>, > > +<&mmcc MDSS_ESC0_CLK>, > > +<&mmcc MMSS_MISC_AHB_CLK>; > > + clock-names = "mdp_core", > > + "iface", > > + "bus", > > + "byte", > > + "pixel", > > + "core", > > + "core_mmss"; > > Unless I enable MMSS_MMSSNOC_AXI_CLK and MMSS_S0_AXI_CLK I get some > underrun error from DSI. You don't see anything like this? > > (These clocks are controlled by msm_bus downstream and should be driven > by interconnect upstream) > > > Apart from this, I think this looks nice. Happy to see the progress. No, I'm not seeing an underrun errors from the DSI. I think the clocks are fine since I'm able to get this working with 4.17 using these same clocks. I just sent out v2 and the cover letter has some details, along with the full dmesg. Brian ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 5/6] ARM: dts: qcom: msm8974-hammerhead: add support for backlight
Add necessary device tree nodes for the main LCD backlight.
Signed-off-by: Brian Masney
Reviewed-by: Linus Walleij
---
This requires this series that should be merged soon:
https://lore.kernel.org/lkml/20190424092505.6578-1-masn...@onstation.org/
The device tree bindings have been reviewed. The driver changes have
received 3 {Reviewed,Acked}-bys.
Changes since v1:
- None
.../qcom-msm8974-lge-nexus5-hammerhead.dts| 34 +++
1 file changed, 34 insertions(+)
diff --git a/arch/arm/boot/dts/qcom-msm8974-lge-nexus5-hammerhead.dts
b/arch/arm/boot/dts/qcom-msm8974-lge-nexus5-hammerhead.dts
index b3b04736a159..b7cf4b1019e9 100644
--- a/arch/arm/boot/dts/qcom-msm8974-lge-nexus5-hammerhead.dts
+++ b/arch/arm/boot/dts/qcom-msm8974-lge-nexus5-hammerhead.dts
@@ -289,6 +289,16 @@
};
};
+ i2c11_pins: i2c11 {
+ mux {
+ pins = "gpio83", "gpio84";
+ function = "blsp_i2c11";
+
+ drive-strength = <2>;
+ bias-disable;
+ };
+ };
+
i2c12_pins: i2c12 {
mux {
pins = "gpio87", "gpio88";
@@ -369,6 +379,30 @@
};
};
+ i2c@f9967000 {
+ status = "ok";
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c11_pins>;
+ clock-frequency = <355000>;
+ qcom,src-freq = <5000>;
+
+ led-controller@38 {
+ compatible = "ti,lm3630a";
+ status = "ok";
+ reg = <0x38>;
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ led@0 {
+ reg = <0>;
+ led-sources = <0 1>;
+ label = "lcd-backlight";
+ default-brightness = <200>;
+ };
+ };
+ };
+
i2c@f9968000 {
status = "ok";
pinctrl-names = "default";
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 6/6] ARM: dts: qcom: msm8974-hammerhead: add support for display
Add initial support for the display found on the LG Nexus 5 (hammerhead)
phone.
Signed-off-by: Brian Masney
Reviewed-by: Linus Walleij
---
Changes since v1:
- None
.../qcom-msm8974-lge-nexus5-hammerhead.dts| 45 +++
1 file changed, 45 insertions(+)
diff --git a/arch/arm/boot/dts/qcom-msm8974-lge-nexus5-hammerhead.dts
b/arch/arm/boot/dts/qcom-msm8974-lge-nexus5-hammerhead.dts
index b7cf4b1019e9..749226e18ab5 100644
--- a/arch/arm/boot/dts/qcom-msm8974-lge-nexus5-hammerhead.dts
+++ b/arch/arm/boot/dts/qcom-msm8974-lge-nexus5-hammerhead.dts
@@ -500,6 +500,51 @@
};
};
};
+
+ mdss@fd90 {
+ status = "ok";
+
+ mdp@fd90 {
+ status = "ok";
+ };
+
+ dsi@fd922800 {
+ status = "ok";
+
+ vdda-supply = <&pm8941_l2>;
+ vdd-supply = <&pm8941_lvs3>;
+ vddio-supply = <&pm8941_l12>;
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ports {
+ port@1 {
+ endpoint {
+ remote-endpoint = <&panel_in>;
+ data-lanes = <0 1 2 3>;
+ };
+ };
+ };
+
+ panel: panel@0 {
+ reg = <0>;
+ compatible = "lg,acx467akm-7";
+
+ port {
+ panel_in: endpoint {
+ remote-endpoint = <&dsi0_out>;
+ };
+ };
+ };
+ };
+
+ dsi-phy@fd922a00 {
+ status = "ok";
+
+ vddio-supply = <&pm8941_l12>;
+ };
+ };
};
&spmi_bus {
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH RFC 4/6] ARM: dts: msm8974: add display support
On Wed, May 08, 2019 at 08:00:47PM -0700, Bjorn Andersson wrote: > On Wed 08 May 19:25 PDT 2019, Rob Clark wrote: > > > On Wed, May 8, 2019 at 7:16 PM Brian Masney wrote: > > > > > > On Mon, May 06, 2019 at 11:39:02PM -0700, Bjorn Andersson wrote: > > > > On Sun 05 May 06:04 PDT 2019, Brian Masney wrote: > > > > > diff --git a/arch/arm/boot/dts/qcom-msm8974.dtsi > > > > > b/arch/arm/boot/dts/qcom-msm8974.dtsi > > > > [..] > > > > > + clocks = <&mmcc MDSS_MDP_CLK>, > > > > > +<&mmcc MDSS_AHB_CLK>, > > > > > +<&mmcc MDSS_AXI_CLK>, > > > > > +<&mmcc MDSS_BYTE0_CLK>, > > > > > +<&mmcc MDSS_PCLK0_CLK>, > > > > > +<&mmcc MDSS_ESC0_CLK>, > > > > > +<&mmcc MMSS_MISC_AHB_CLK>; > > > > > + clock-names = "mdp_core", > > > > > + "iface", > > > > > + "bus", > > > > > + "byte", > > > > > + "pixel", > > > > > + "core", > > > > > + "core_mmss"; > > > > > > > > Unless I enable MMSS_MMSSNOC_AXI_CLK and MMSS_S0_AXI_CLK I get some > > > > underrun error from DSI. You don't see anything like this? > > > > > > > > (These clocks are controlled by msm_bus downstream and should be driven > > > > by interconnect upstream) > > > > > > > > > > > > Apart from this, I think this looks nice. Happy to see the progress. > > > > > > No, I'm not seeing an underrun errors from the DSI. I think the clocks > > > are fine since I'm able to get this working with 4.17 using these same > > > clocks. I just sent out v2 and the cover letter has some details, along > > > with the full dmesg. > > > > since we don't have interconnect driver for 8974, I guess there is > > some chance that things work or not based on how lk leaves things? > > > > Right, I guess the bootloader on my device does not leave the busses > ticking - perhaps there's a boot splash involved on Brian's device? > > Regardless, this works on Nexus 5 and allows Brian to make further > progress so I'm all for merging it. There is a boot splash on the Nexus 5 and that may explain a behavior that I observed. I attempted to add reset GPIO support to the simple panel driver and the screen will clear but nothing will come on the screen after a hard reset, even on 4.17. To be sure, I got the timing information for how long to leave the GPIO high and low from the downstream MSM 3.4 sources. That's when I had a script port all of the ~400 panel on commands in the downstream device tree to a new panel driver. With the latest kernel kernel having a delay showing the console text, I observe a brief second where the boot splash is shown along with the startup text from Linux. A full refresh is performed and the boot splash goes away. I don't see this with the 4.17 kernel; perhaps maybe the full refresh occurs quick enough that its not noticeable. Can you point me to where the interconnect API is in the downstream MSM 3.4 sources? https://github.com/AICP/kernel_lge_hammerhead It looks like its in drivers/interconnect/ in the upstream sources. Brian ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH RFC v2 0/6] ARM: qcom: initial Nexus 5 display support
On Wed, May 08, 2019 at 10:03:46PM -0400, Brian Masney wrote: > Here is a patch series that adds initial display support for the LG > Nexus 5 (hammerhead) phone. It's not fully working so that's why some > of these patches are RFC until we can get it fully working. > > The phones boots into terminal mode, however there is a several second > (or more) delay when writing to tty1 compared to when the changes are > actually shown on the screen. The following errors are in dmesg: I attached the full dmesg output with this patch series applied. I enabled debugging messages for just the DRM subsystem. Brian [0.00] Booting Linux on physical CPU 0x0 [0.00] Linux version 5.1.0-rc6-next-20190426-9-g75891c3edac4-dirty (masneyb@ins7386) (gcc version 8.1.1 20180626 (Red Hat Cross 8.1.1-3) (GCC)) #303 SMP PREEMPT Wed May 8 21:59:17 EDT 2019 [0.00] CPU: ARMv7 Processor [512f06f0] revision 0 (ARMv7), cr=10c5787d [0.00] CPU: div instructions available: patching division code [0.00] CPU: PIPT / VIPT nonaliasing data cache, PIPT instruction cache [0.00] OF: fdt: Machine model: LGE MSM 8974 HAMMERHEAD [0.00] Memory policy: Data cache writealloc [0.00] cma: Reserved 256 MiB at 0x2000 [0.00] On node 0 totalpages: 491776 [0.00] Normal zone: 1536 pages used for memmap [0.00] Normal zone: 0 pages reserved [0.00] Normal zone: 164096 pages, LIFO batch:31 [0.00] HighMem zone: 327680 pages, LIFO batch:63 [0.00] percpu: Embedded 17 pages/cpu s39756 r8192 d21684 u69632 [0.00] pcpu-alloc: s39756 r8192 d21684 u69632 alloc=17*4096 [0.00] pcpu-alloc: [0] 0 [0] 1 [0] 2 [0] 3 [0.00] Built 1 zonelists, mobility grouping on. Total pages: 490240 [0.00] Kernel command line: console=tty0 console=ttyMSM0,115200,n8 rootwait androidboot.hardware=hammerhead user_debug=31 maxcpus=2 msm_watchdog_v2.enable=1 PMOS_NO_OUTPUT_REDIRECT=1 uart_console=enable gpt=enable lge.kcal=0|0|0|x lge.rev=rev_11 androidboot.laf androidboot.emmc=true fastboot=true androidboot.serialno=019eef1708e40fd2 androidboot.bootloader=HHZ20h androidboot.baseband=msm androidboot.hardware.sku=D820 androidboot.hardware.ddr=hynix androidboot.hardware.display=orise androidboot.revision=11 [0.00] Dentry cache hash table entries: 131072 (order: 7, 524288 bytes) [0.00] Inode-cache hash table entries: 65536 (order: 6, 262144 bytes) [0.00] Memory: 1633208K/1967104K available (8192K kernel code, 834K rwdata, 3436K rodata, 1024K init, 266K bss, 71752K reserved, 262144K cma-reserved, 1310720K highmem) [0.00] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=4, Nodes=1 [0.00] rcu: Preemptible hierarchical RCU implementation. [0.00] Tasks RCU enabled. [0.00] rcu: RCU calculated value of scheduler-enlistment delay is 10 jiffies. [0.00] NR_IRQS: 16, nr_irqs: 16, preallocated irqs: 16 [0.00] random: get_random_bytes called from start_kernel+0x300/0x490 with crng_init=0 [0.00] arch_timer: cp15 and mmio timer(s) running at 19.20MHz (virt/virt). [0.00] clocksource: arch_sys_counter: mask: 0xff max_cycles: 0x46d987e47, max_idle_ns: 440795202767 ns [0.05] sched_clock: 56 bits at 19MHz, resolution 52ns, wraps every 4398046511078ns [0.17] Switching to timer-based delay loop, resolution 52ns [0.000410] Console: colour dummy device 80x30 [0.000785] printk: console [tty0] enabled [0.000823] Calibrating delay loop (skipped), value calculated using timer frequency.. 38.40 BogoMIPS (lpj=192000) [0.000854] pid_max: default: 32768 minimum: 301 [0.000984] Mount-cache hash table entries: 2048 (order: 1, 8192 bytes) [0.001014] Mountpoint-cache hash table entries: 2048 (order: 1, 8192 bytes) [0.001504] *** VALIDATE proc *** [0.001629] *** VALIDATE cgroup1 *** [0.001651] *** VALIDATE cgroup2 *** [0.001676] CPU: Testing write buffer coherency: ok [0.001939] CPU0: thread -1, cpu 0, socket 0, mpidr 8000 [0.059943] Setting up static identity map for 0x30 - 0x300060 [0.079942] rcu: Hierarchical SRCU implementation. [0.120017] smp: Bringing up secondary CPUs ... [0.200453] CPU1: thread -1, cpu 1, socket 0, mpidr 8001 [0.200671] smp: Brought up 1 node, 2 CPUs [0.200705] SMP: Total of 2 processors activated (76.80 BogoMIPS). [0.200725] CPU: All CPU(s) started in SVC mode. [0.202148] devtmpfs: initialized [0.211750] VFP support v0.3: implementor 51 architecture 64 part 6f variant 2 rev 0 [0.212072] clocksource: jiffies: mask: 0x max_cycles: 0x, max_idle_ns: 1911260446275 ns [0.212111] futex hash table entries: 1024 (order: 4, 65536 bytes) [0.221586] pinctrl core: initialized pinctrl subsystem [0.222779] NET: Registered protocol family 16 [0.224668] DMA: preallocated 2
[PATCH v2 3/6] ARM: qcom_defconfig: add display-related options
Add the CMA (Contiguous Memory Allocator) for the MSM DRM driver, the simple panel, and the TI LM3630A driver in order to support the display on the LG Nexus 5 (hammerhead) phone. Signed-off-by: Brian Masney Reviewed-by: Linus Walleij --- Changes since v1: - None arch/arm/configs/qcom_defconfig | 5 + 1 file changed, 5 insertions(+) diff --git a/arch/arm/configs/qcom_defconfig b/arch/arm/configs/qcom_defconfig index c1854751c99a..4f02636f832e 100644 --- a/arch/arm/configs/qcom_defconfig +++ b/arch/arm/configs/qcom_defconfig @@ -37,6 +37,7 @@ CONFIG_ARM_CPUIDLE=y CONFIG_VFP=y CONFIG_NEON=y # CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS is not set +CONFIG_CMA=y CONFIG_NET=y CONFIG_PACKET=y CONFIG_UNIX=y @@ -146,12 +147,14 @@ CONFIG_REGULATOR_QCOM_SMD_RPM=y CONFIG_REGULATOR_QCOM_SPMI=y CONFIG_MEDIA_SUPPORT=y CONFIG_DRM=y +CONFIG_DRM_PANEL_SIMPLE=y CONFIG_FB=y CONFIG_FRAMEBUFFER_CONSOLE=y CONFIG_BACKLIGHT_LCD_SUPPORT=y # CONFIG_LCD_CLASS_DEVICE is not set CONFIG_BACKLIGHT_CLASS_DEVICE=y # CONFIG_BACKLIGHT_GENERIC is not set +CONFIG_BACKLIGHT_LM3630A=y CONFIG_BACKLIGHT_LP855X=y CONFIG_SOUND=y CONFIG_SND=y @@ -262,6 +265,8 @@ CONFIG_NLS_CODEPAGE_437=y CONFIG_NLS_ASCII=y CONFIG_NLS_ISO8859_1=y CONFIG_NLS_UTF8=y +CONFIG_DMA_CMA=y +CONFIG_CMA_SIZE_MBYTES=256 CONFIG_PRINTK_TIME=y CONFIG_DYNAMIC_DEBUG=y CONFIG_DEBUG_INFO=y -- 2.20.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH RFC v2 2/6] drm: msm: add dirty framebuffer helper
Use drm_atomic_helper_dirtyfb() as the dirty callback in the
msm_framebuffer_funcs struct. Call drm_plane_enable_fb_damage_clips()
when the planes are initialized in mdp4, mdp5, and dpu1.
Signed-off-by: Brian Masney
---
Changes since v1:
- Add drm_plane_enable_fb_damage_clips() to plane init for mdp4, mdp5,
and dpu1.
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 3 +++
drivers/gpu/drm/msm/disp/mdp4/mdp4_plane.c | 3 +++
drivers/gpu/drm/msm/disp/mdp5/mdp5_plane.c | 3 +++
drivers/gpu/drm/msm/msm_fb.c | 2 ++
4 files changed, 11 insertions(+)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
index ce1a555e1f31..f3d009a3dc63 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
@@ -21,6 +21,7 @@
#include
#include
+#include
#include
#include "msm_drv.h"
@@ -1540,6 +1541,8 @@ struct drm_plane *dpu_plane_init(struct drm_device *dev,
if (ret)
DPU_ERROR("failed to install zpos property, rc = %d\n", ret);
+ drm_plane_enable_fb_damage_clips(plane);
+
/* success! finalize initialization */
drm_plane_helper_add(plane, &dpu_plane_helper_funcs);
diff --git a/drivers/gpu/drm/msm/disp/mdp4/mdp4_plane.c
b/drivers/gpu/drm/msm/disp/mdp4/mdp4_plane.c
index 005066f7154d..2d46d1126283 100644
--- a/drivers/gpu/drm/msm/disp/mdp4/mdp4_plane.c
+++ b/drivers/gpu/drm/msm/disp/mdp4/mdp4_plane.c
@@ -15,6 +15,7 @@
* this program. If not, see <http://www.gnu.org/licenses/>.
*/
+#include
#include "mdp4_kms.h"
#define DOWN_SCALE_MAX 8
@@ -391,6 +392,8 @@ struct drm_plane *mdp4_plane_init(struct drm_device *dev,
mdp4_plane_install_properties(plane, &plane->base);
+ drm_plane_enable_fb_damage_clips(plane);
+
return plane;
fail:
diff --git a/drivers/gpu/drm/msm/disp/mdp5/mdp5_plane.c
b/drivers/gpu/drm/msm/disp/mdp5/mdp5_plane.c
index be13140967b4..fcb6d32c2b38 100644
--- a/drivers/gpu/drm/msm/disp/mdp5/mdp5_plane.c
+++ b/drivers/gpu/drm/msm/disp/mdp5/mdp5_plane.c
@@ -16,6 +16,7 @@
* this program. If not, see <http://www.gnu.org/licenses/>.
*/
+#include
#include
#include "mdp5_kms.h"
@@ -1099,6 +1100,8 @@ struct drm_plane *mdp5_plane_init(struct drm_device *dev,
mdp5_plane_install_properties(plane, &plane->base);
+ drm_plane_enable_fb_damage_clips(plane);
+
return plane;
fail:
diff --git a/drivers/gpu/drm/msm/msm_fb.c b/drivers/gpu/drm/msm/msm_fb.c
index 136058978e0f..8624a8e4025f 100644
--- a/drivers/gpu/drm/msm/msm_fb.c
+++ b/drivers/gpu/drm/msm/msm_fb.c
@@ -16,6 +16,7 @@
*/
#include
+#include
#include
#include
@@ -35,6 +36,7 @@ static struct drm_framebuffer *msm_framebuffer_init(struct
drm_device *dev,
static const struct drm_framebuffer_funcs msm_framebuffer_funcs = {
.create_handle = drm_gem_fb_create_handle,
.destroy = drm_gem_fb_destroy,
+ .dirty = drm_atomic_helper_dirtyfb,
};
#ifdef CONFIG_DEBUG_FS
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 4/6] ARM: dts: msm8974: add display support
Add the MDP5, DSI and DSI PHY blocks for the display found on the
msm8974 SoCs. This is based on work from msm8916.dtsi and Jonathan
Marek.
Signed-off-by: Brian Masney
Reviewed-by: Linus Walleij
---
Changes since v1:
- None
arch/arm/boot/dts/qcom-msm8974.dtsi | 132
1 file changed, 132 insertions(+)
diff --git a/arch/arm/boot/dts/qcom-msm8974.dtsi
b/arch/arm/boot/dts/qcom-msm8974.dtsi
index 45b5c8ef0374..3f613c5b95a1 100644
--- a/arch/arm/boot/dts/qcom-msm8974.dtsi
+++ b/arch/arm/boot/dts/qcom-msm8974.dtsi
@@ -3,6 +3,7 @@
#include
#include
+#include
#include
#include
#include
@@ -1085,6 +1086,137 @@
};
};
};
+
+ mdss: mdss@fd90 {
+ status = "disabled";
+
+ compatible = "qcom,mdss";
+ reg = <0xfd90 0x100>,
+ <0xfd924000 0x1000>;
+ reg-names = "mdss_phys",
+ "vbif_phys";
+
+ power-domains = <&mmcc MDSS_GDSC>;
+
+ clocks = <&mmcc MDSS_AHB_CLK>,
+<&mmcc MDSS_AXI_CLK>,
+<&mmcc MDSS_VSYNC_CLK>;
+ clock-names = "iface",
+ "bus",
+ "vsync";
+
+ interrupts = ;
+
+ interrupt-controller;
+ #interrupt-cells = <1>;
+
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ mdp: mdp@fd90 {
+ status = "disabled";
+
+ compatible = "qcom,mdp5";
+ reg = <0xfd900100 0x22000>;
+ reg-names = "mdp_phys";
+
+ interrupt-parent = <&mdss>;
+ interrupts = <0 0>;
+
+ clocks = <&mmcc MDSS_AHB_CLK>,
+<&mmcc MDSS_AXI_CLK>,
+<&mmcc MDSS_MDP_CLK>,
+<&mmcc MDSS_VSYNC_CLK>;
+ clock-names = "iface",
+ "bus",
+ "core",
+ "vsync";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ mdp5_intf1_out: endpoint {
+ remote-endpoint =
<&dsi0_in>;
+ };
+ };
+ };
+ };
+
+ dsi0: dsi@fd922800 {
+ status = "disabled";
+
+ compatible = "qcom,mdss-dsi-ctrl";
+ reg = <0xfd922800 0x1f8>;
+ reg-names = "dsi_ctrl";
+
+ interrupt-parent = <&mdss>;
+ interrupts = <4 IRQ_TYPE_LEVEL_HIGH>;
+
+ assigned-clocks = <&mmcc BYTE0_CLK_SRC>,
+ <&mmcc PCLK0_CLK_SRC>;
+ assigned-clock-parents = <&dsi_phy0 0>,
+<&dsi_phy0 1>;
+
+ clocks = <&mmcc MDSS_MDP_CLK>,
+<&mmcc MDSS_AHB_CLK>,
+<&mmcc MDSS_AXI_CLK>,
+<&mmcc MDSS_BYTE0_CLK>,
+<&mmcc MDSS_PCLK0_CLK>,
+<&mmcc MDSS_ESC0_CLK>,
+<&mmcc MMSS_MISC_AHB_CLK>;
+ clock-names = "mdp_core",
+ "iface",
+ "bus",
[PATCH v2 1/6] drm: msm: remove resv fields from msm_gem_object struct
The msm_gem_object structure contains resv and _resv fields that are
no longer needed since the reservation object is now stored on
drm_gem_object. msm_atomic_prepare_fb() and msm_atomic_prepare_fb()
both referenced the wrong reservation object, and would lead to an
attempt to dereference a NULL pointer. Correct those two cases to
point to the correct reservation object.
Signed-off-by: Brian Masney
Fixes: dd55cf6929e6 ("drm: msm: Switch to use drm_gem_object
reservation_object")
---
Patch introduced in v2
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 4 +---
drivers/gpu/drm/msm/msm_atomic.c | 4 +---
drivers/gpu/drm/msm/msm_gem.c | 3 ---
drivers/gpu/drm/msm/msm_gem.h | 4
4 files changed, 2 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
index da1f727d7495..ce1a555e1f31 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
@@ -780,7 +780,6 @@ static int dpu_plane_prepare_fb(struct drm_plane *plane,
struct dpu_plane_state *pstate = to_dpu_plane_state(new_state);
struct dpu_hw_fmt_layout layout;
struct drm_gem_object *obj;
- struct msm_gem_object *msm_obj;
struct dma_fence *fence;
struct dpu_kms *kms = _dpu_plane_get_kms(&pdpu->base);
int ret;
@@ -799,8 +798,7 @@ static int dpu_plane_prepare_fb(struct drm_plane *plane,
* implicit fence and fb prepare by hand here.
*/
obj = msm_framebuffer_bo(new_state->fb, 0);
- msm_obj = to_msm_bo(obj);
- fence = reservation_object_get_excl_rcu(msm_obj->resv);
+ fence = reservation_object_get_excl_rcu(obj->resv);
if (fence)
drm_atomic_set_fence_for_plane(new_state, fence);
diff --git a/drivers/gpu/drm/msm/msm_atomic.c b/drivers/gpu/drm/msm/msm_atomic.c
index f5b1256e32b6..131c23a267ee 100644
--- a/drivers/gpu/drm/msm/msm_atomic.c
+++ b/drivers/gpu/drm/msm/msm_atomic.c
@@ -49,15 +49,13 @@ int msm_atomic_prepare_fb(struct drm_plane *plane,
struct msm_drm_private *priv = plane->dev->dev_private;
struct msm_kms *kms = priv->kms;
struct drm_gem_object *obj;
- struct msm_gem_object *msm_obj;
struct dma_fence *fence;
if (!new_state->fb)
return 0;
obj = msm_framebuffer_bo(new_state->fb, 0);
- msm_obj = to_msm_bo(obj);
- fence = reservation_object_get_excl_rcu(msm_obj->resv);
+ fence = reservation_object_get_excl_rcu(obj->resv);
drm_atomic_set_fence_for_plane(new_state, fence);
diff --git a/drivers/gpu/drm/msm/msm_gem.c b/drivers/gpu/drm/msm/msm_gem.c
index 31d5a744d84f..947508e8269d 100644
--- a/drivers/gpu/drm/msm/msm_gem.c
+++ b/drivers/gpu/drm/msm/msm_gem.c
@@ -973,9 +973,6 @@ static int msm_gem_new_impl(struct drm_device *dev,
msm_obj->flags = flags;
msm_obj->madv = MSM_MADV_WILLNEED;
- if (resv)
- msm_obj->base.resv = resv;
-
INIT_LIST_HEAD(&msm_obj->submit_entry);
INIT_LIST_HEAD(&msm_obj->vmas);
diff --git a/drivers/gpu/drm/msm/msm_gem.h b/drivers/gpu/drm/msm/msm_gem.h
index c5ac781dffee..812d1b1369a5 100644
--- a/drivers/gpu/drm/msm/msm_gem.h
+++ b/drivers/gpu/drm/msm/msm_gem.h
@@ -86,10 +86,6 @@ struct msm_gem_object {
struct llist_node freed;
- /* normally (resv == &_resv) except for imported bo's */
- struct reservation_object *resv;
- struct reservation_object _resv;
-
/* For physically contiguous buffers. Used when we don't have
* an IOMMU. Also used for stolen/splashscreen buffer.
*/
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 1/6] drm: msm: remove resv fields from msm_gem_object struct
On Mon, May 13, 2019 at 01:32:39PM -0700, Bjorn Andersson wrote:
> On Wed 08 May 19:03 PDT 2019, Brian Masney wrote:
>
> > The msm_gem_object structure contains resv and _resv fields that are
> > no longer needed since the reservation object is now stored on
> > drm_gem_object. msm_atomic_prepare_fb() and msm_atomic_prepare_fb()
> > both referenced the wrong reservation object, and would lead to an
> > attempt to dereference a NULL pointer. Correct those two cases to
> > point to the correct reservation object.
> >
> > Signed-off-by: Brian Masney
> > Fixes: dd55cf6929e6 ("drm: msm: Switch to use drm_gem_object
> > reservation_object")
>
> Reviewed-by: Bjorn Andersson
> Tested-by: Bjorn Andersson
>
> This resolves a NULL-pointer dereference about to show up in v5.2-rc1,
> so please pick this up for -rc.
Let me send out another version of just this patch. This snippet below
that I removed needs to stay. I got a little too over eager removing
code.
> > @@ -973,9 +973,6 @@ static int msm_gem_new_impl(struct drm_device *dev,
> > msm_obj->flags = flags;
> > msm_obj->madv = MSM_MADV_WILLNEED;
> >
> > - if (resv)
> > - msm_obj->base.resv = resv;
> > -
> > INIT_LIST_HEAD(&msm_obj->submit_entry);
> > INIT_LIST_HEAD(&msm_obj->vmas);
> >
Brian
[PATCH 2/2] drm/msm: correct attempted NULL pointer dereference in debugfs
msm_gem_describe() would attempt to dereference a NULL pointer via the
address space pointer when no IOMMU is present. Correct this by adding
the appropriate check.
Signed-off-by: Brian Masney
Fixes: 575f0485508b ("drm/msm: Clean up and enhance the output of the 'gem'
debugfs node")
---
drivers/gpu/drm/msm/msm_gem.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/msm_gem.c b/drivers/gpu/drm/msm/msm_gem.c
index 31d5a744d84f..35f55dd25994 100644
--- a/drivers/gpu/drm/msm/msm_gem.c
+++ b/drivers/gpu/drm/msm/msm_gem.c
@@ -803,7 +803,8 @@ void msm_gem_describe(struct drm_gem_object *obj, struct
seq_file *m)
seq_puts(m, " vmas:");
list_for_each_entry(vma, &msm_obj->vmas, list)
- seq_printf(m, " [%s: %08llx,%s,inuse=%d]",
vma->aspace->name,
+ seq_printf(m, " [%s: %08llx,%s,inuse=%d]",
+ vma->aspace != NULL ? vma->aspace->name : NULL,
vma->iova, vma->mapped ? "mapped" : "unmapped",
vma->inuse);
--
2.20.1
[PATCH v2.1 1/2] drm/msm: remove resv fields from msm_gem_object struct
The msm_gem_object structure contains resv and _resv fields that are
no longer needed since the reservation object is now stored on
drm_gem_object. msm_atomic_prepare_fb() and msm_atomic_prepare_fb()
both referenced the wrong reservation object, and would lead to an
attempt to dereference a NULL pointer. Correct those two cases to
point to the correct reservation object.
Signed-off-by: Brian Masney
Reviewed-by: Bjorn Andersson
Tested-by: Bjorn Andersson
Fixes: dd55cf6929e6 ("drm: msm: Switch to use drm_gem_object
reservation_object")
---
This is a split out version of this patch from where I am working to get
the display working on the Nexus 5:
https://lore.kernel.org/lkml/20190509020352.14282-2-masn...@onstation.org/
Bjorn asks:
This resolves a NULL-pointer dereference about to show up in v5.2-rc1,
so please pick this up for -rc.
In this version, I dropped the change to msm_gem_new_impl() that
mistakenly removed 'msm_obj->base.resv = resv;'. I did not put a v3 on
this patch since I wanted to keep that version number for the larger work
to get the display working on the Nexus 5 so I went with 2.1 here. :)
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 4 +---
drivers/gpu/drm/msm/msm_atomic.c | 4 +---
drivers/gpu/drm/msm/msm_gem.h | 4
3 files changed, 2 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
index 4fca24b8702c..f3d009a3dc63 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
@@ -781,7 +781,6 @@ static int dpu_plane_prepare_fb(struct drm_plane *plane,
struct dpu_plane_state *pstate = to_dpu_plane_state(new_state);
struct dpu_hw_fmt_layout layout;
struct drm_gem_object *obj;
- struct msm_gem_object *msm_obj;
struct dma_fence *fence;
struct dpu_kms *kms = _dpu_plane_get_kms(&pdpu->base);
int ret;
@@ -800,8 +799,7 @@ static int dpu_plane_prepare_fb(struct drm_plane *plane,
* implicit fence and fb prepare by hand here.
*/
obj = msm_framebuffer_bo(new_state->fb, 0);
- msm_obj = to_msm_bo(obj);
- fence = reservation_object_get_excl_rcu(msm_obj->resv);
+ fence = reservation_object_get_excl_rcu(obj->resv);
if (fence)
drm_atomic_set_fence_for_plane(new_state, fence);
diff --git a/drivers/gpu/drm/msm/msm_atomic.c b/drivers/gpu/drm/msm/msm_atomic.c
index f5b1256e32b6..131c23a267ee 100644
--- a/drivers/gpu/drm/msm/msm_atomic.c
+++ b/drivers/gpu/drm/msm/msm_atomic.c
@@ -49,15 +49,13 @@ int msm_atomic_prepare_fb(struct drm_plane *plane,
struct msm_drm_private *priv = plane->dev->dev_private;
struct msm_kms *kms = priv->kms;
struct drm_gem_object *obj;
- struct msm_gem_object *msm_obj;
struct dma_fence *fence;
if (!new_state->fb)
return 0;
obj = msm_framebuffer_bo(new_state->fb, 0);
- msm_obj = to_msm_bo(obj);
- fence = reservation_object_get_excl_rcu(msm_obj->resv);
+ fence = reservation_object_get_excl_rcu(obj->resv);
drm_atomic_set_fence_for_plane(new_state, fence);
diff --git a/drivers/gpu/drm/msm/msm_gem.h b/drivers/gpu/drm/msm/msm_gem.h
index c5ac781dffee..812d1b1369a5 100644
--- a/drivers/gpu/drm/msm/msm_gem.h
+++ b/drivers/gpu/drm/msm/msm_gem.h
@@ -86,10 +86,6 @@ struct msm_gem_object {
struct llist_node freed;
- /* normally (resv == &_resv) except for imported bo's */
- struct reservation_object *resv;
- struct reservation_object _resv;
-
/* For physically contiguous buffers. Used when we don't have
* an IOMMU. Also used for stolen/splashscreen buffer.
*/
--
2.20.1
Re: [PATCH v6 2/3] dt-bindings: backlight: add lm3630a bindings
Hi Rob, On Fri, May 17, 2019 at 04:11:48PM -0500, Rob Herring wrote: > On Wed, Apr 24, 2019 at 4:25 AM Brian Masney wrote: > > > > Add new backlight bindings for the TI LM3630A dual-string white LED. > > > > Signed-off-by: Brian Masney > > Reviewed-by: Rob Herring > > --- > > Changes since v5: > > - Change 'lm3630a_bl@38' in examples to 'led-controller@38' > > > > Changes since v4: > > - Drop $ref from led-sources > > - Drop description from reg of i2c address > > - Expand description of reg for the control bank > > - Drop status from examples > > > > Changes since v3: > > - Add label. I didn't add a description for it since that'll come from > > the common properties once its converted. > > > > Changes since v2: > > - Update description of max-brightness > > - Add description for reg > > - Correct typo: s/tranisiton/transition > > - add reg to control banks > > - add additionalProperties > > > > .../leds/backlight/lm3630a-backlight.yaml | 129 ++ > > 1 file changed, 129 insertions(+) > > create mode 100644 > > Documentation/devicetree/bindings/leds/backlight/lm3630a-backlight.yaml > > I'm working on getting the examples to be validated by the schema (in > addition to just building with dtc) and there's a couple of errors: > > Documentation/devicetree/bindings/leds/backlight/lm3630a-backlight.example.dt.yaml: > '#address-cells', '#size-cells' do not match any of the regexes: > '^led@[01]$', 'pinctrl-[0-9]+' > Documentation/devicetree/bindings/leds/backlight/lm3630a-backlight.example.dt.yaml: > '#address-cells', '#size-cells' do not match any of the regexes: > '^led@[01]$', 'pinctrl-[0-9]+' > > You didn't list '#address-cells' and '#size-cells'. > > Documentation/devicetree/bindings/leds/backlight/lm3630a-backlight.example.dt.yaml: > led@0: 'ti,linear-mapping-mode' does not match any of the regexes: > 'pinctrl-[0-9]+' > Documentation/devicetree/bindings/leds/backlight/lm3630a-backlight.example.dt.yaml: > led@1: 'ti,linear-mapping-mode' does not match any of the regexes: > 'pinctrl-[0-9]+' > > 'ti,linear-mapping-mode' is not defined in the child nodes. I'm sorry about that. I'll send out a patch this weekend to correct this. I have 'make dt_binding_check' in my local build script. Is there something else that I should be running as well? Or do you have a branch somewhere with your validation work that I can test my changes against? Brian
[PATCH] dt-bindings: backlight: lm3630a: correct schema validation
The '#address-cells' and '#size-cells' properties were not defined in
the lm3630a bindings and would cause the following error when
attempting to validate the examples against the schema:
Documentation/devicetree/bindings/leds/backlight/lm3630a-backlight.example.dt.yaml:
'#address-cells', '#size-cells' do not match any of the regexes:
'^led@[01]$', 'pinctrl-[0-9]+'
Correct this by adding those two properties.
While we're here, move the ti,linear-mapping-mode property to the
led@[01] child nodes to correct the following validation error:
Documentation/devicetree/bindings/leds/backlight/lm3630a-backlight.example.dt.yaml:
led@0: 'ti,linear-mapping-mode' does not match any of the regexes:
'pinctrl-[0-9]+'
Fixes: 32fcb75c66a0 ("dt-bindings: backlight: Add lm3630a bindings")
Signed-off-by: Brian Masney
Reported-by: Rob Herring
---
.../leds/backlight/lm3630a-backlight.yaml | 20 +--
1 file changed, 14 insertions(+), 6 deletions(-)
diff --git
a/Documentation/devicetree/bindings/leds/backlight/lm3630a-backlight.yaml
b/Documentation/devicetree/bindings/leds/backlight/lm3630a-backlight.yaml
index 4d61fe0a98a4..f0855e248ae5 100644
--- a/Documentation/devicetree/bindings/leds/backlight/lm3630a-backlight.yaml
+++ b/Documentation/devicetree/bindings/leds/backlight/lm3630a-backlight.yaml
@@ -23,16 +23,17 @@ properties:
reg:
maxItems: 1
- ti,linear-mapping-mode:
-description: |
- Enable linear mapping mode. If disabled, then it will use exponential
- mapping mode in which the ramp up/down appears to have a more uniform
- transition to the human eye.
-type: boolean
+ '#address-cells':
+const: 1
+
+ '#size-cells':
+const: 0
required:
- compatible
- reg
+ - '#address-cells'
+ - '#size-cells'
patternProperties:
"^led@[01]$":
@@ -73,6 +74,13 @@ patternProperties:
minimum: 0
maximum: 255
+ ti,linear-mapping-mode:
+description: |
+ Enable linear mapping mode. If disabled, then it will use exponential
+ mapping mode in which the ramp up/down appears to have a more uniform
+ transition to the human eye.
+type: boolean
+
required:
- reg
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH RFC v2 0/6] ARM: qcom: initial Nexus 5 display support
On Tue, May 28, 2019 at 03:46:14PM +0200, Linus Walleij wrote:
> On Thu, May 9, 2019 at 4:04 AM Brian Masney wrote:
>
> > Here is a patch series that adds initial display support for the LG
> > Nexus 5 (hammerhead) phone. It's not fully working so that's why some
> > of these patches are RFC until we can get it fully working.
> >
> > The phones boots into terminal mode, however there is a several second
> > (or more) delay when writing to tty1 compared to when the changes are
> > actually shown on the screen. The following errors are in dmesg:
>
> I tested to apply patches 2-6 and got the console up on the phone as well.
> I see the same timouts, and I also notice the update is slow in the
> display, as if the DSI panel was running in low power (LP) mode.
>
> Was booting this to do some other work, but happy to see the progress!
Thanks!
I've had three people email me off list regarding the display working on
4.17 before the msm kms/drm driver was converted to the DRM atomic API so
this email is to get some more information out publicly.
I pushed up a branch to my github with 15 patches applied against 4.17
that has a working display:
https://github.com/masneyb/linux/commits/display-works-4.17
It's in low speed mode but its usable. The first 10 patches are in
mainline now and the last 5 are in essence this patch series with the
exception of 'drm/atomic+msm: add helper to implement legacy dirtyfb'.
There's a slightly different version of that patch in mainline now.
I'm planning to work on the msm8974 interconnect support once some of
the outstanding interconnect patches for the msm kms/drm driver arrive
in mainline. I'd really like to understand why the display works on
4.17 with those patches though. I assume that it's related to the
vblank events not working properly? Let me preface this with I'm a
total DRM newbie, but it looked like the pre-DRM-atomic driver wasn't
looking for these events in the atomic commits before the migration?
See commit 70db18dca4e0 ("drm/msm: Remove msm_commit/worker, use atomic
helper commit"), specifically the drm_atomic_helper_wait_for_vblanks()
call that was added.
Brian
Re: [Freedreno] [PATCH RFC v2 0/6] ARM: qcom: initial Nexus 5 display support
On Tue, May 28, 2019 at 07:32:14PM -0600, Jeffrey Hugo wrote:
> On Tue, May 28, 2019 at 7:17 PM Brian Masney wrote:
> >
> > On Tue, May 28, 2019 at 03:46:14PM +0200, Linus Walleij wrote:
> > > On Thu, May 9, 2019 at 4:04 AM Brian Masney wrote:
> > >
> > > > Here is a patch series that adds initial display support for the LG
> > > > Nexus 5 (hammerhead) phone. It's not fully working so that's why some
> > > > of these patches are RFC until we can get it fully working.
> > > >
> > > > The phones boots into terminal mode, however there is a several second
> > > > (or more) delay when writing to tty1 compared to when the changes are
> > > > actually shown on the screen. The following errors are in dmesg:
> > >
> > > I tested to apply patches 2-6 and got the console up on the phone as well.
> > > I see the same timouts, and I also notice the update is slow in the
> > > display, as if the DSI panel was running in low power (LP) mode.
> > >
> > > Was booting this to do some other work, but happy to see the progress!
> >
> > Thanks!
> >
> > I've had three people email me off list regarding the display working on
> > 4.17 before the msm kms/drm driver was converted to the DRM atomic API so
> > this email is to get some more information out publicly.
> >
> > I pushed up a branch to my github with 15 patches applied against 4.17
> > that has a working display:
> >
> > https://github.com/masneyb/linux/commits/display-works-4.17
> >
> > It's in low speed mode but its usable. The first 10 patches are in
> > mainline now and the last 5 are in essence this patch series with the
> > exception of 'drm/atomic+msm: add helper to implement legacy dirtyfb'.
> > There's a slightly different version of that patch in mainline now.
> >
> > I'm planning to work on the msm8974 interconnect support once some of
> > the outstanding interconnect patches for the msm kms/drm driver arrive
> > in mainline. I'd really like to understand why the display works on
> > 4.17 with those patches though. I assume that it's related to the
> > vblank events not working properly? Let me preface this with I'm a
> > total DRM newbie, but it looked like the pre-DRM-atomic driver wasn't
> > looking for these events in the atomic commits before the migration?
> > See commit 70db18dca4e0 ("drm/msm: Remove msm_commit/worker, use atomic
> > helper commit"), specifically the drm_atomic_helper_wait_for_vblanks()
> > call that was added.
>
> Do you know if the nexus 5 has a video or command mode panel? There
> is some glitchyness with vblanks and command mode panels.
Its in command mode. I know this because I see two 'pp done time out'
messages, even on 4.17. Based on my understanding, the ping pong code is
only applicable for command mode panels.
Brian
Re: [Freedreno] [PATCH RFC v2 0/6] ARM: qcom: initial Nexus 5 display support
On Tue, May 28, 2019 at 07:42:19PM -0600, Jeffrey Hugo wrote: > > > Do you know if the nexus 5 has a video or command mode panel? There > > > is some glitchyness with vblanks and command mode panels. > > > > Its in command mode. I know this because I see two 'pp done time out' > > messages, even on 4.17. Based on my understanding, the ping pong code is > > only applicable for command mode panels. > > Actually, the ping pong element exists in both modes, but 'pp done > time out' is a good indicator that it is command mode. > > Are you also seeing vblank timeouts? Yes, here's a snippet of the first one. [2.556014] WARNING: CPU: 0 PID: 5 at drivers/gpu/drm/drm_atomic_helper.c:1429 drm_atomic_helper_wait_for_vblanks.part.1+0x288/0x290 [2.556020] [CRTC:49:crtc-0] vblank wait timed out [2.556023] Modules linked in: [2.556034] CPU: 0 PID: 5 Comm: kworker/0:0 Not tainted 5.2.0-rc1-00178-g72c3c1fd5f86-dirty #426 [2.556038] Hardware name: Generic DT based system [2.556056] Workqueue: events deferred_probe_work_func ... > Do you have busybox? > > Can you run - > sudo busybox devmem 0xFD900614 > sudo busybox devmem 0xFD900714 > sudo busybox devmem 0xFD900814 > sudo busybox devmem 0xFD900914 > sudo busybox devmem 0xFD900A14 # busybox devmem 0xFD900614 0x00020020 # busybox devmem 0xFD900714 0x # busybox devmem 0xFD900814 0x # busybox devmem 0xFD900914 0x # busybox devmem 0xFD900A14 0x I get the same values with the mainline kernel and 4.17. Brian
Re: [PATCH RFC v2 0/6] ARM: qcom: initial Nexus 5 display support
On Wed, May 29, 2019 at 08:23:17AM +0200, Linus Walleij wrote: > On Wed, May 29, 2019 at 3:17 AM Brian Masney wrote: > > > It's in low speed mode but its usable. > > How low speed is that? I don't have a number but my test with 4.17 is to run 'cat /etc/passwd > /dev/tty1' over a serial cable. The first 2-3 calls will fill up the screen and the file contents appear to show up on the screen immediately to the human eye. The next time that I run it requires scrolling the entire console and there is a small fraction of a second where I see the entire framebuffer contents scroll up. I don't have a graphics background, but I believe that this is the tearing effect that I'm seeing based on what I've read. I believe that disp-te-gpios can be used to mitigate this tearing effect. I have a few questions about this later once we get the basic display working. > > I assume that it's related to the > > vblank events not working properly? > > They are only waiting for 50 ms before timing out, I raised it > to 100ms in the -next kernel. I'm still suspicious about this > even though I think you said this was not the problem. > > For a command mode panel in LP mode it will nevertheless > be more than 100ms for sure, the update is visible to the > naked eye. > > Raise it to 1 ms or something and see what happens. > drivers/gpu/drm/drm_atomic_helper.c: > msecs_to_jiffies(50) I previously raised those timeouts as high as 5 seconds and it still has the same issue. Writing to /dev/tty1 can take anywhere between a few seconds to 30 seconds or more. Brian
Re: [PATCH v2 2/3] dt-bindings: backlight: add lm3630a bindings
Hi Dan, On Tue, Apr 02, 2019 at 08:44:22AM -0500, Dan Murphy wrote: > Also one other comment I noticed when reviewing the code that there is no > definition to > which child led properties are optional and which are required? With the new YAML bindings, there is a separate toplevel 'required' tag in the schema. Here is a snippet from my last submission that illustrates this: properties: compatible: const: ti,lm3630a reg: maxItems: 1 ti,linear-mapping-mode: description: | Enable linear mapping mode. If disabled, then it will use exponential mapping mode in which the ramp up/down appears to have a more uniform transition to the human eye. type: boolean required: - compatible - reg So 'ti,linear-mapping-mode' is optional in this example. > > + led-sources: > > +description: | > > + List of device current outputs the LED is connected to. > > +allOf: > > + - $ref: /schemas/types.yaml#/definitions/uint32-array > > + - minItems: 1 > > +maxItems: 2 > > +items: > > + minimum: 0 > > + maximum: 1 > > + > > label and led-sources are already defined in the common.txt no need to > redefine them here. We'll still need to define the led-sources and label in this binding with the new format even though it will also be in the LED common bindings. We won't have to put the common things like the description since that information will come from the common binding. We only need to specify the additional constraints like the min/max number of items and the min/max value for each item for this particular example. Brian ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 3/3] backlight: lm3630a: add firmware node support
Add fwnode support to the lm3630a driver and allow configuring
the initial and maximum LED brightness on both LED banks independently.
The two outputs can be controlled by bank A and B independently or
bank A can control both outputs.
If the platform data was not configured, then the driver defaults to
enabling both banks. This patch changes the default value to disable
both banks before parsing the firmware node so that just a single bank
can be enabled if desired. There are no in-tree users of this driver.
Driver was tested on a LG Nexus 5 (hammerhead) phone.
Signed-off-by: Brian Masney
---
Changes since v2
- Separated out control banks and outputs via the reg and led-sources
properties.
- Use fwnode instead of of API
- Disable both banks by default before calling lm3630a_parse_node()
- Add lots of error handling
- Check for duplicate source / bank definitions
- Remove extra ;
- Make probe() method fail if fwnode parsing fails.
drivers/video/backlight/lm3630a_bl.c | 128 ++-
1 file changed, 126 insertions(+), 2 deletions(-)
diff --git a/drivers/video/backlight/lm3630a_bl.c
b/drivers/video/backlight/lm3630a_bl.c
index ef2553f452ca..15922da9c05a 100644
--- a/drivers/video/backlight/lm3630a_bl.c
+++ b/drivers/video/backlight/lm3630a_bl.c
@@ -364,6 +364,116 @@ static const struct regmap_config lm3630a_regmap = {
.max_register = REG_MAX,
};
+/**
+ * lm3630a_parse_led_sources - Parse the optional led-sources fwnode property.
+ * @node: firmware node
+ * @default_bitmask: bitmask to return if the led-sources property was not
+ * specified
+ *
+ * Parses the optional led-sources firmware node and returns a bitmask that
+ * contains the outputs that are associated with the control bank. If the
+ * property is missing, then the value of of @default_bitmask will be returned.
+ */
+static int lm3630a_parse_led_sources(struct fwnode_handle *node,
+int default_bitmask)
+{
+ int ret, num_sources, i;
+ u32 sources[2];
+
+ num_sources = fwnode_property_read_u32_array(node, "led-sources", NULL,
+0);
+ if (num_sources < 0)
+ return default_bitmask;
+ else if (num_sources > ARRAY_SIZE(sources))
+ return -EINVAL;
+
+ ret = fwnode_property_read_u32_array(node, "led-sources", sources,
+num_sources);
+ if (ret)
+ return ret;
+
+ ret = 0;
+ for (i = 0; i < num_sources; i++) {
+ if (sources[i] < 0 || sources[i] > 1)
+ return -EINVAL;
+
+ ret |= BIT(sources[i]);
+ }
+
+ return ret;
+}
+
+static int lm3630a_parse_node(struct lm3630a_chip *pchip,
+ struct lm3630a_platform_data *pdata)
+{
+ int seen = 0, led_sources, ret;
+ struct fwnode_handle *node;
+ u32 bank, val;
+ bool linear;
+
+ device_for_each_child_node(pchip->dev, node) {
+ ret = fwnode_property_read_u32(node, "reg", &bank);
+ if (ret < 0)
+ return ret;
+
+ if (bank < 0 || bank > 1)
+ return -EINVAL;
+
+ if (seen & BIT(bank))
+ return -EINVAL;
+ seen |= BIT(bank);
+
+ led_sources = lm3630a_parse_led_sources(node, BIT(bank));
+ if (led_sources < 0)
+ return led_sources;
+
+ linear = fwnode_property_read_bool(node,
+ "ti,linear-mapping-mode");
+ if (bank == 0) {
+ if (!(led_sources & BIT(0)))
+ return -EINVAL;
+
+ pdata->leda_ctrl = linear ?
+ LM3630A_LEDA_ENABLE_LINEAR :
+ LM3630A_LEDA_ENABLE;
+
+ if (led_sources & BIT(1)) {
+ if (seen & BIT(1))
+ return -EINVAL;
+ seen |= BIT(1);
+
+ pdata->ledb_ctrl = LM3630A_LEDB_ON_A;
+ }
+ } else {
+ if (led_sources & BIT(0) || !(led_sources & BIT(1)))
+ return -EINVAL;
+
+ pdata->ledb_ctrl = linear ?
+ LM3630A_LEDB_ENABLE_LINEAR :
+ LM3630A_LEDB_ENABLE;
+ }
+
+ ret = fwnode_property_read_u32(node, "default-brightness",
+ &val);
+ if (!ret) {
+ if (bank == 0)
+
[PATCH v3 2/3] dt-bindings: backlight: add lm3630a bindings
Add new backlight bindings for the TI LM3630A dual-string white LED.
Signed-off-by: Brian Masney
---
Rob: Since the common bindings aren't converted to the new JSON schema
yet, I'm not sure how to do led-sources here. I would expect that we'd
have the uint32-array on the common binding once it exists. I had to
add it here to keep 'make dt_binding_check' happy. I left the
description off though for that property since that'll come from common
once its converted.
Changes since v2:
- Update description of max-brightness
- Add description for reg
- Correct typo: s/tranisiton/transition
- Remove label from bindings since this isn't on backlight_properties
- add reg to control banks
- add additionalProperties
.../leds/backlight/lm3630a-backlight.yaml | 124 ++
1 file changed, 124 insertions(+)
create mode 100644
Documentation/devicetree/bindings/leds/backlight/lm3630a-backlight.yaml
diff --git
a/Documentation/devicetree/bindings/leds/backlight/lm3630a-backlight.yaml
b/Documentation/devicetree/bindings/leds/backlight/lm3630a-backlight.yaml
new file mode 100644
index ..cccd43c02732
--- /dev/null
+++ b/Documentation/devicetree/bindings/leds/backlight/lm3630a-backlight.yaml
@@ -0,0 +1,124 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/leds/backlight/lm3630a-backlight.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: TI LM3630A High-Efficiency Dual-String White LED
+
+maintainers:
+ - Lee Jones
+ - Daniel Thompson
+ - Jingoo Han
+
+description: |
+ The LM3630A is a current-mode boost converter which supplies the power and
+ controls the current in up to two strings of 10 LEDs per string.
+ https://www.ti.com/product/LM3630A
+
+properties:
+ compatible:
+const: ti,lm3630a
+
+ reg:
+description: The I2C address of the device
+maxItems: 1
+
+ ti,linear-mapping-mode:
+description: |
+ Enable linear mapping mode. If disabled, then it will use exponential
+ mapping mode in which the ramp up/down appears to have a more uniform
+ transition to the human eye.
+type: boolean
+
+required:
+ - compatible
+ - reg
+
+patternProperties:
+ "^led@[01]$":
+type: object
+description: |
+ Properties for a string of connected LEDs.
+
+properties:
+ reg:
+description: Control Bank
+maxItems: 1
+minimum: 0
+maximum: 1
+
+ led-sources:
+allOf:
+ - $ref: /schemas/types.yaml#/definitions/uint32-array
+ - minItems: 1
+maxItems: 2
+items:
+ minimum: 0
+ maximum: 1
+
+ default-brightness:
+description: Default brightness level on boot.
+minimum: 0
+maximum: 255
+
+ max-brightness:
+description: Maximum brightness that is allowed during runtime.
+minimum: 0
+maximum: 255
+
+required:
+ - reg
+
+additionalProperties: false
+
+additionalProperties: false
+
+examples:
+ - |
+i2c {
+#address-cells = <1>;
+#size-cells = <0>;
+
+lm3630a_bl@38 {
+compatible = "ti,lm3630a";
+status = "ok";
+reg = <0x38>;
+
+#address-cells = <1>;
+#size-cells = <0>;
+
+led@0 {
+reg = <0>;
+led-sources = <0 1>;
+default-brightness = <200>;
+max-brightness = <255>;
+};
+};
+};
+ - |
+i2c {
+#address-cells = <1>;
+#size-cells = <0>;
+
+lm3630a_bl@38 {
+compatible = "ti,lm3630a";
+status = "ok";
+reg = <0x38>;
+
+#address-cells = <1>;
+#size-cells = <0>;
+
+led@0 {
+reg = <0>;
+default-brightness = <150>;
+ti,linear-mapping-mode;
+};
+
+led@1 {
+reg = <1>;
+default-brightness = <225>;
+ti,linear-mapping-mode;
+};
+};
+};
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 0/3] backlight: lm3630a: bug fix and fwnode support
Here is a patch series that fixes a single bug and adds fwnode support to the lm3630a driver. This work was tested on a LG Nexus 5 (hammerhead) phone. My status page at https://masneyb.github.io/nexus-5-upstream/ describes what is working so far with the upstream kernel. See the individual patches for the changelog. Brian Masney (3): backlight: lm3630a: return 0 on success in update_status functions dt-bindings: backlight: add lm3630a bindings backlight: lm3630a: add firmware node support .../leds/backlight/lm3630a-backlight.yaml | 124 drivers/video/backlight/lm3630a_bl.c | 132 +- 2 files changed, 252 insertions(+), 4 deletions(-) create mode 100644 Documentation/devicetree/bindings/leds/backlight/lm3630a-backlight.yaml -- 2.20.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 2/3] dt-bindings: backlight: add lm3630a bindings
On Mon, Apr 15, 2019 at 07:10:04AM -0500, Dan Murphy wrote: > I noticed we are missing "label". It is defined as optional and it is hard > coded in the driver > but wondering if there is a need to add it. OK, I'll make it optional and have it fall back to the hardcoded values if it is missing. Thanks for the quick feedback on this patch and the other one. Brian ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 1/3] backlight: lm3630a: return 0 on success in update_status functions
lm3630a_bank_a_update_status() and lm3630a_bank_b_update_status()
both return the brightness value if the brightness was successfully
updated. Writing to these attributes via sysfs would cause a 'Bad
address' error to be returned. These functions should return 0 on
success, so let's change it to correct that error.
Signed-off-by: Brian Masney
Fixes: 28e64a68a2ef ("backlight: lm3630: apply chip revision")
Acked-by: Pavel Machek
---
Changes since v2:
- None
drivers/video/backlight/lm3630a_bl.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/video/backlight/lm3630a_bl.c
b/drivers/video/backlight/lm3630a_bl.c
index 2030a6b77a09..ef2553f452ca 100644
--- a/drivers/video/backlight/lm3630a_bl.c
+++ b/drivers/video/backlight/lm3630a_bl.c
@@ -201,7 +201,7 @@ static int lm3630a_bank_a_update_status(struct
backlight_device *bl)
LM3630A_LEDA_ENABLE, LM3630A_LEDA_ENABLE);
if (ret < 0)
goto out_i2c_err;
- return bl->props.brightness;
+ return 0;
out_i2c_err:
dev_err(pchip->dev, "i2c failed to access\n");
@@ -278,7 +278,7 @@ static int lm3630a_bank_b_update_status(struct
backlight_device *bl)
LM3630A_LEDB_ENABLE, LM3630A_LEDB_ENABLE);
if (ret < 0)
goto out_i2c_err;
- return bl->props.brightness;
+ return 0;
out_i2c_err:
dev_err(pchip->dev, "i2c failed to access REG_CTRL\n");
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 0/3] backlight: lm3630a: bug fix and fwnode support
Here is a patch series that fixes a single bug and adds fwnode support to the lm3630a driver. This work was tested on a LG Nexus 5 (hammerhead) phone. My status page at https://masneyb.github.io/nexus-5-upstream/ describes what is working so far with the upstream kernel. See the individual patches for the changelog. Brian Masney (3): backlight: lm3630a: return 0 on success in update_status functions dt-bindings: backlight: add lm3630a bindings backlight: lm3630a: add firmware node support .../leds/backlight/lm3630a-backlight.yaml | 128 +++ drivers/video/backlight/lm3630a_bl.c | 151 +- include/linux/platform_data/lm3630a_bl.h | 4 + 3 files changed, 276 insertions(+), 7 deletions(-) create mode 100644 Documentation/devicetree/bindings/leds/backlight/lm3630a-backlight.yaml -- 2.20.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 2/3] dt-bindings: backlight: add lm3630a bindings
Add new backlight bindings for the TI LM3630A dual-string white LED.
Signed-off-by: Brian Masney
---
Rob: Since the common bindings aren't converted to the new JSON schema
yet, I'm not sure how to do led-sources here. I would expect that we'd
have the uint32-array on the common binding once it exists. I had to
add it here to keep 'make dt_binding_check' happy. I left the
description off though for that property since that'll come from common
once its converted.
Changes since v3:
- Add label. I didn't add a description for it since that'll come from
the common properties once its converted.
Changes since v2:
- Update description of max-brightness
- Add description for reg
- Correct typo: s/tranisiton/transition
- add reg to control banks
- add additionalProperties
.../leds/backlight/lm3630a-backlight.yaml | 128 ++
1 file changed, 128 insertions(+)
create mode 100644
Documentation/devicetree/bindings/leds/backlight/lm3630a-backlight.yaml
diff --git
a/Documentation/devicetree/bindings/leds/backlight/lm3630a-backlight.yaml
b/Documentation/devicetree/bindings/leds/backlight/lm3630a-backlight.yaml
new file mode 100644
index ..5067038ca637
--- /dev/null
+++ b/Documentation/devicetree/bindings/leds/backlight/lm3630a-backlight.yaml
@@ -0,0 +1,128 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/leds/backlight/lm3630a-backlight.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: TI LM3630A High-Efficiency Dual-String White LED
+
+maintainers:
+ - Lee Jones
+ - Daniel Thompson
+ - Jingoo Han
+
+description: |
+ The LM3630A is a current-mode boost converter which supplies the power and
+ controls the current in up to two strings of 10 LEDs per string.
+ https://www.ti.com/product/LM3630A
+
+properties:
+ compatible:
+const: ti,lm3630a
+
+ reg:
+description: The I2C address of the device
+maxItems: 1
+
+ ti,linear-mapping-mode:
+description: |
+ Enable linear mapping mode. If disabled, then it will use exponential
+ mapping mode in which the ramp up/down appears to have a more uniform
+ transition to the human eye.
+type: boolean
+
+required:
+ - compatible
+ - reg
+
+patternProperties:
+ "^led@[01]$":
+type: object
+description: |
+ Properties for a string of connected LEDs.
+
+properties:
+ reg:
+description: Control Bank
+maxItems: 1
+minimum: 0
+maximum: 1
+
+ label:
+maxItems: 1
+
+ led-sources:
+allOf:
+ - $ref: /schemas/types.yaml#/definitions/uint32-array
+ - minItems: 1
+maxItems: 2
+items:
+ minimum: 0
+ maximum: 1
+
+ default-brightness:
+description: Default brightness level on boot.
+minimum: 0
+maximum: 255
+
+ max-brightness:
+description: Maximum brightness that is allowed during runtime.
+minimum: 0
+maximum: 255
+
+required:
+ - reg
+
+additionalProperties: false
+
+additionalProperties: false
+
+examples:
+ - |
+i2c {
+#address-cells = <1>;
+#size-cells = <0>;
+
+lm3630a_bl@38 {
+compatible = "ti,lm3630a";
+status = "ok";
+reg = <0x38>;
+
+#address-cells = <1>;
+#size-cells = <0>;
+
+led@0 {
+reg = <0>;
+led-sources = <0 1>;
+label = "lcd-backlight";
+default-brightness = <200>;
+max-brightness = <255>;
+};
+};
+};
+ - |
+i2c {
+#address-cells = <1>;
+#size-cells = <0>;
+
+lm3630a_bl@38 {
+compatible = "ti,lm3630a";
+status = "ok";
+reg = <0x38>;
+
+#address-cells = <1>;
+#size-cells = <0>;
+
+led@0 {
+reg = <0>;
+default-brightness = <150>;
+ti,linear-mapping-mode;
+};
+
+led@1 {
+reg = <1>;
+default-brightness = <225>;
+ti,linear-mapping-mode;
+};
+};
+};
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 3/3] backlight: lm3630a: add firmware node support
Add fwnode support to the lm3630a driver and optionally allow
configuring the label, default brightness level, and maximum brightness
level. The two outputs can be controlled by bank A and B independently
or bank A can control both outputs.
If the platform data was not configured, then the driver defaults to
enabling both banks. This patch changes the default value to disable
both banks before parsing the firmware node so that just a single bank
can be enabled if desired. There are no in-tree users of this driver.
Driver was tested on a LG Nexus 5 (hammerhead) phone.
Signed-off-by: Brian Masney
---
Changes since v3
- Add support for label
- Changed lm3630a_parse_node() to return -ENODEV if no nodes were found
- Remove LM3630A_LED{A,B}_DISABLE
- Add two additional newlines for code readability
- Remove extra newline
Changes since v2
- Separated out control banks and outputs via the reg and led-sources
properties.
- Use fwnode instead of of API
- Disable both banks by default before calling lm3630a_parse_node()
- Add lots of error handling
- Check for duplicate source / bank definitions
- Remove extra ;
- Make probe() method fail if fwnode parsing fails.
drivers/video/backlight/lm3630a_bl.c | 147 ++-
include/linux/platform_data/lm3630a_bl.h | 4 +
2 files changed, 146 insertions(+), 5 deletions(-)
diff --git a/drivers/video/backlight/lm3630a_bl.c
b/drivers/video/backlight/lm3630a_bl.c
index ef2553f452ca..6d3c54bfbb10 100644
--- a/drivers/video/backlight/lm3630a_bl.c
+++ b/drivers/video/backlight/lm3630a_bl.c
@@ -329,15 +329,17 @@ static const struct backlight_ops lm3630a_bank_b_ops = {
static int lm3630a_backlight_register(struct lm3630a_chip *pchip)
{
- struct backlight_properties props;
struct lm3630a_platform_data *pdata = pchip->pdata;
+ struct backlight_properties props;
+ const char *label;
props.type = BACKLIGHT_RAW;
if (pdata->leda_ctrl != LM3630A_LEDA_DISABLE) {
props.brightness = pdata->leda_init_brt;
props.max_brightness = pdata->leda_max_brt;
+ label = pdata->leda_label ? pdata->leda_label : "lm3630a_leda";
pchip->bleda =
- devm_backlight_device_register(pchip->dev, "lm3630a_leda",
+ devm_backlight_device_register(pchip->dev, label,
pchip->dev, pchip,
&lm3630a_bank_a_ops, &props);
if (IS_ERR(pchip->bleda))
@@ -348,8 +350,9 @@ static int lm3630a_backlight_register(struct lm3630a_chip
*pchip)
(pdata->ledb_ctrl != LM3630A_LEDB_ON_A)) {
props.brightness = pdata->ledb_init_brt;
props.max_brightness = pdata->ledb_max_brt;
+ label = pdata->ledb_label ? pdata->ledb_label : "lm3630a_ledb";
pchip->bledb =
- devm_backlight_device_register(pchip->dev, "lm3630a_ledb",
+ devm_backlight_device_register(pchip->dev, label,
pchip->dev, pchip,
&lm3630a_bank_b_ops, &props);
if (IS_ERR(pchip->bledb))
@@ -364,6 +367,129 @@ static const struct regmap_config lm3630a_regmap = {
.max_register = REG_MAX,
};
+/**
+ * lm3630a_parse_led_sources - Parse the optional led-sources fwnode property.
+ * @node: firmware node
+ * @default_bitmask: bitmask to return if the led-sources property was not
+ * specified
+ *
+ * Parses the optional led-sources firmware node and returns a bitmask that
+ * contains the outputs that are associated with the control bank. If the
+ * property is missing, then the value of of @default_bitmask will be returned.
+ */
+static int lm3630a_parse_led_sources(struct fwnode_handle *node,
+int default_bitmask)
+{
+ int ret, num_sources, i;
+ u32 sources[2];
+
+ num_sources = fwnode_property_read_u32_array(node, "led-sources", NULL,
+0);
+ if (num_sources < 0)
+ return default_bitmask;
+ else if (num_sources > ARRAY_SIZE(sources))
+ return -EINVAL;
+
+ ret = fwnode_property_read_u32_array(node, "led-sources", sources,
+num_sources);
+ if (ret)
+ return ret;
+
+ ret = 0;
+ for (i = 0; i < num_sources; i++) {
+ if (sources[i] < 0 || sources[i] > 1)
+ return -EINVAL;
+
+ ret |= BIT(sources[i]);
+ }
+
+ return ret;
+}
+
+static int lm3630a_parse_node(struct lm3630a_chip *pchip,
+ struct lm3630a_
[PATCH v4 1/3] backlight: lm3630a: return 0 on success in update_status functions
lm3630a_bank_a_update_status() and lm3630a_bank_b_update_status()
both return the brightness value if the brightness was successfully
updated. Writing to these attributes via sysfs would cause a 'Bad
address' error to be returned. These functions should return 0 on
success, so let's change it to correct that error.
Signed-off-by: Brian Masney
Fixes: 28e64a68a2ef ("backlight: lm3630: apply chip revision")
Acked-by: Pavel Machek
---
Changes since v3:
- None
Changes since v2:
- None
drivers/video/backlight/lm3630a_bl.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/video/backlight/lm3630a_bl.c
b/drivers/video/backlight/lm3630a_bl.c
index 2030a6b77a09..ef2553f452ca 100644
--- a/drivers/video/backlight/lm3630a_bl.c
+++ b/drivers/video/backlight/lm3630a_bl.c
@@ -201,7 +201,7 @@ static int lm3630a_bank_a_update_status(struct
backlight_device *bl)
LM3630A_LEDA_ENABLE, LM3630A_LEDA_ENABLE);
if (ret < 0)
goto out_i2c_err;
- return bl->props.brightness;
+ return 0;
out_i2c_err:
dev_err(pchip->dev, "i2c failed to access\n");
@@ -278,7 +278,7 @@ static int lm3630a_bank_b_update_status(struct
backlight_device *bl)
LM3630A_LEDB_ENABLE, LM3630A_LEDB_ENABLE);
if (ret < 0)
goto out_i2c_err;
- return bl->props.brightness;
+ return 0;
out_i2c_err:
dev_err(pchip->dev, "i2c failed to access REG_CTRL\n");
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 2/3] dt-bindings: backlight: add lm3630a bindings
On Wed, Apr 17, 2019 at 08:34:33AM -0500, Rob Herring wrote: > On Tue, Apr 16, 2019 at 6:54 PM Brian Masney wrote: > > > > Add new backlight bindings for the TI LM3630A dual-string white LED. > > > > Signed-off-by: Brian Masney > > --- > > Rob: Since the common bindings aren't converted to the new JSON schema > > yet, I'm not sure how to do led-sources here. I would expect that we'd > > have the uint32-array on the common binding once it exists. I had to > > add it here to keep 'make dt_binding_check' happy. I left the > > description off though for that property since that'll come from common > > once its converted. > > What was the error? '$ref' shouldn't be needed for this. The tooling > has no knowledge whether there's common schema or not. So you probably > have some pattern the meta-schema doesn't like and we need to fix. Ahh, you're right... it works without the $ref. I just needed the minItems and maxItems to fix the error I originally saw. I'll wait for feedback from Dan before I send out another version with your changes. Thanks, Brian ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v5 2/3] dt-bindings: backlight: add lm3630a bindings
Add new backlight bindings for the TI LM3630A dual-string white LED.
Signed-off-by: Brian Masney
---
Changes since v4:
- Drop $ref from led-sources
- Drop description from reg of i2c address
- Expand description of reg for the control bank
- Drop status from examples
Changes since v3:
- Add label. I didn't add a description for it since that'll come from
the common properties once its converted.
Changes since v2:
- Update description of max-brightness
- Add description for reg
- Correct typo: s/tranisiton/transition
- add reg to control banks
- add additionalProperties
.../leds/backlight/lm3630a-backlight.yaml | 129 ++
1 file changed, 129 insertions(+)
create mode 100644
Documentation/devicetree/bindings/leds/backlight/lm3630a-backlight.yaml
diff --git
a/Documentation/devicetree/bindings/leds/backlight/lm3630a-backlight.yaml
b/Documentation/devicetree/bindings/leds/backlight/lm3630a-backlight.yaml
new file mode 100644
index ..e754df569365
--- /dev/null
+++ b/Documentation/devicetree/bindings/leds/backlight/lm3630a-backlight.yaml
@@ -0,0 +1,129 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/leds/backlight/lm3630a-backlight.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: TI LM3630A High-Efficiency Dual-String White LED
+
+maintainers:
+ - Lee Jones
+ - Daniel Thompson
+ - Jingoo Han
+
+description: |
+ The LM3630A is a current-mode boost converter which supplies the power and
+ controls the current in up to two strings of 10 LEDs per string.
+ https://www.ti.com/product/LM3630A
+
+properties:
+ compatible:
+const: ti,lm3630a
+
+ reg:
+maxItems: 1
+
+ ti,linear-mapping-mode:
+description: |
+ Enable linear mapping mode. If disabled, then it will use exponential
+ mapping mode in which the ramp up/down appears to have a more uniform
+ transition to the human eye.
+type: boolean
+
+required:
+ - compatible
+ - reg
+
+patternProperties:
+ "^led@[01]$":
+type: object
+description: |
+ Properties for a string of connected LEDs.
+
+properties:
+ reg:
+description: |
+ The control bank that is used to program the two current sinks. The
+ LM3630A has two control banks (A and B) and are represented as 0 or 1
+ in this property. The two current sinks can be controlled
+ independently with both banks, or bank A can be configured to control
+ both sinks with the led-sources property.
+maxItems: 1
+minimum: 0
+maximum: 1
+
+ label:
+maxItems: 1
+
+ led-sources:
+allOf:
+ - minItems: 1
+maxItems: 2
+items:
+ minimum: 0
+ maximum: 1
+
+ default-brightness:
+description: Default brightness level on boot.
+minimum: 0
+maximum: 255
+
+ max-brightness:
+description: Maximum brightness that is allowed during runtime.
+minimum: 0
+maximum: 255
+
+required:
+ - reg
+
+additionalProperties: false
+
+additionalProperties: false
+
+examples:
+ - |
+i2c {
+#address-cells = <1>;
+#size-cells = <0>;
+
+lm3630a_bl@38 {
+compatible = "ti,lm3630a";
+reg = <0x38>;
+
+#address-cells = <1>;
+#size-cells = <0>;
+
+led@0 {
+reg = <0>;
+led-sources = <0 1>;
+label = "lcd-backlight";
+default-brightness = <200>;
+max-brightness = <255>;
+};
+};
+};
+ - |
+i2c {
+#address-cells = <1>;
+#size-cells = <0>;
+
+lm3630a_bl@38 {
+compatible = "ti,lm3630a";
+reg = <0x38>;
+
+#address-cells = <1>;
+#size-cells = <0>;
+
+led@0 {
+reg = <0>;
+default-brightness = <150>;
+ti,linear-mapping-mode;
+};
+
+led@1 {
+reg = <1>;
+default-brightness = <225>;
+ti,linear-mapping-mode;
+};
+};
+};
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v5 3/3] backlight: lm3630a: add firmware node support
Add fwnode support to the lm3630a driver and optionally allow
configuring the label, default brightness level, and maximum brightness
level. The two outputs can be controlled by bank A and B independently
or bank A can control both outputs.
If the platform data was not configured, then the driver defaults to
enabling both banks. This patch changes the default value to disable
both banks before parsing the firmware node so that just a single bank
can be enabled if desired. There are no in-tree users of this driver.
Driver was tested on a LG Nexus 5 (hammerhead) phone.
Signed-off-by: Brian Masney
---
Changes since v4
- Added new function lm3630a_parse_bank()
- Renamed seen variable to seen_led_sources
- Use the bitmask returned from lm3630a_parse_led_sources() to compare
against the seen_led_sources rather than just the control bank. This
eliminated another if statement that was previously present that
checked to see if control bank A should control both sinks.
- #define LM3630A_BANK_0, LM3630A_BANK_1, LM3630A_SINK_0,
LM3630A_SINK_1, and LM3630A_NUM_SINKS and use where appropriate.
- Changed all occurances of
'if (bank == 0) { BANK_A_WORK } else { BANK_B_WORK }' to
'if (bank) { BANK_B_WORK } else { BANK_A_WORK }'
- Dropped unnecessary 'ret = 0' from lm3630a_parse_led_sources().
- Changed 'if (ret < 0)' to 'if (ret)' in lm3630a_parse_node().
- Dropped kerneldoc from lm3630a_parse_led_sources().
Changes since v3
- Add support for label
- Changed lm3630a_parse_node() to return -ENODEV if no nodes were found
- Remove LM3630A_LED{A,B}_DISABLE
- Add two additional newlines for code readability
- Remove extra newline
Changes since v2
- Separated out control banks and outputs via the reg and led-sources
properties.
- Use fwnode instead of of API
- Disable both banks by default before calling lm3630a_parse_node()
- Add lots of error handling
- Check for duplicate source / bank definitions
- Remove extra ;
- Make probe() method fail if fwnode parsing fails.
drivers/video/backlight/lm3630a_bl.c | 149 ++-
include/linux/platform_data/lm3630a_bl.h | 4 +
2 files changed, 148 insertions(+), 5 deletions(-)
diff --git a/drivers/video/backlight/lm3630a_bl.c
b/drivers/video/backlight/lm3630a_bl.c
index ef2553f452ca..75d996490cf0 100644
--- a/drivers/video/backlight/lm3630a_bl.c
+++ b/drivers/video/backlight/lm3630a_bl.c
@@ -35,6 +35,14 @@
#define REG_MAX0x50
#define INT_DEBOUNCE_MSEC 10
+
+#define LM3630A_BANK_0 0
+#define LM3630A_BANK_1 1
+
+#define LM3630A_NUM_SINKS 2
+#define LM3630A_SINK_0 0
+#define LM3630A_SINK_1 1
+
struct lm3630a_chip {
struct device *dev;
struct delayed_work work;
@@ -329,15 +337,17 @@ static const struct backlight_ops lm3630a_bank_b_ops = {
static int lm3630a_backlight_register(struct lm3630a_chip *pchip)
{
- struct backlight_properties props;
struct lm3630a_platform_data *pdata = pchip->pdata;
+ struct backlight_properties props;
+ const char *label;
props.type = BACKLIGHT_RAW;
if (pdata->leda_ctrl != LM3630A_LEDA_DISABLE) {
props.brightness = pdata->leda_init_brt;
props.max_brightness = pdata->leda_max_brt;
+ label = pdata->leda_label ? pdata->leda_label : "lm3630a_leda";
pchip->bleda =
- devm_backlight_device_register(pchip->dev, "lm3630a_leda",
+ devm_backlight_device_register(pchip->dev, label,
pchip->dev, pchip,
&lm3630a_bank_a_ops, &props);
if (IS_ERR(pchip->bleda))
@@ -348,8 +358,9 @@ static int lm3630a_backlight_register(struct lm3630a_chip
*pchip)
(pdata->ledb_ctrl != LM3630A_LEDB_ON_A)) {
props.brightness = pdata->ledb_init_brt;
props.max_brightness = pdata->ledb_max_brt;
+ label = pdata->ledb_label ? pdata->ledb_label : "lm3630a_ledb";
pchip->bledb =
- devm_backlight_device_register(pchip->dev, "lm3630a_ledb",
+ devm_backlight_device_register(pchip->dev, label,
pchip->dev, pchip,
&lm3630a_bank_b_ops, &props);
if (IS_ERR(pchip->bledb))
@@ -364,6 +375,123 @@ static const struct regmap_config lm3630a_regmap = {
.max_register = REG_MAX,
};
+static int lm3630a_parse_led_sources(struct fwnode_handle *node,
+int default_led_sources)
+{
+ u32 sources[LM3630A_NUM_SINKS];
+ int ret, num_sources, i;
+
+ num_sources = fwnode_property_read_u32_array(
[PATCH v5 1/3] backlight: lm3630a: return 0 on success in update_status functions
lm3630a_bank_a_update_status() and lm3630a_bank_b_update_status()
both return the brightness value if the brightness was successfully
updated. Writing to these attributes via sysfs would cause a 'Bad
address' error to be returned. These functions should return 0 on
success, so let's change it to correct that error.
Signed-off-by: Brian Masney
Fixes: 28e64a68a2ef ("backlight: lm3630: apply chip revision")
Acked-by: Pavel Machek
---
drivers/video/backlight/lm3630a_bl.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/video/backlight/lm3630a_bl.c
b/drivers/video/backlight/lm3630a_bl.c
index 2030a6b77a09..ef2553f452ca 100644
--- a/drivers/video/backlight/lm3630a_bl.c
+++ b/drivers/video/backlight/lm3630a_bl.c
@@ -201,7 +201,7 @@ static int lm3630a_bank_a_update_status(struct
backlight_device *bl)
LM3630A_LEDA_ENABLE, LM3630A_LEDA_ENABLE);
if (ret < 0)
goto out_i2c_err;
- return bl->props.brightness;
+ return 0;
out_i2c_err:
dev_err(pchip->dev, "i2c failed to access\n");
@@ -278,7 +278,7 @@ static int lm3630a_bank_b_update_status(struct
backlight_device *bl)
LM3630A_LEDB_ENABLE, LM3630A_LEDB_ENABLE);
if (ret < 0)
goto out_i2c_err;
- return bl->props.brightness;
+ return 0;
out_i2c_err:
dev_err(pchip->dev, "i2c failed to access REG_CTRL\n");
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v5 0/3] backlight: lm3630a: bug fix and fwnode support
Here is a patch series that fixes a single bug and adds fwnode support to the lm3630a driver. This work was tested on a LG Nexus 5 (hammerhead) phone. My status page at https://masneyb.github.io/nexus-5-upstream/ describes what is working so far with the upstream kernel. See the individual patches for the changelog. Brian Masney (3): backlight: lm3630a: return 0 on success in update_status functions dt-bindings: backlight: add lm3630a bindings backlight: lm3630a: add firmware node support .../leds/backlight/lm3630a-backlight.yaml | 129 +++ drivers/video/backlight/lm3630a_bl.c | 153 +- include/linux/platform_data/lm3630a_bl.h | 4 + 3 files changed, 279 insertions(+), 7 deletions(-) create mode 100644 Documentation/devicetree/bindings/leds/backlight/lm3630a-backlight.yaml -- 2.20.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 3/3] backlight: lm3630a: add firmware node support
On Tue, Apr 23, 2019 at 10:31:41AM -0500, Dan Murphy wrote:
> On 4/23/19 9:01 AM, Brian Masney wrote:
> > On Tue, Apr 23, 2019 at 08:49:20AM -0500, Dan Murphy wrote:
> >>> +static int lm3630a_parse_led_sources(struct fwnode_handle *node,
> >>> + int default_led_sources)
> >>> +{
> >>> + u32 sources[LM3630A_NUM_SINKS];
> >>> + int ret, num_sources, i;
> >>> +
> >>> + num_sources = fwnode_property_read_u32_array(node, "led-sources", NULL,
> >>> + 0);
> >>> + if (num_sources < 0)
> >>> + return default_led_sources;
> >>> + else if (num_sources > ARRAY_SIZE(sources))
> >>> + return -EINVAL;
> >>> +
> >>> + ret = fwnode_property_read_u32_array(node, "led-sources", sources,
> >>> + num_sources);
> >>> + if (ret)
> >>> + return ret;
> >>> +
> >>> + for (i = 0; i < num_sources; i++) {
> >>> + if (sources[i] < LM3630A_SINK_0 || sources[i] > LM3630A_SINK_1)
> >>> + return -EINVAL;
> >>> +
> >>> + ret |= BIT(sources[i]);
> >>> + }
> >>> +
> >>> + return ret;
> >>> +}
> >>> +
> >>> +static int lm3630a_parse_bank(struct lm3630a_platform_data *pdata,
> >>> + struct fwnode_handle *node, int *seen_led_sources)
> >>
> >> Why is seen_led_sources passed in here?
> >> It is initialized on the stack in lm3630a_parse_node but the variable is
> >> never referenced in that API.
> >
> > It's to see all of the led-sources that are configured across all of the
> > banks. If it is just in lm3630a_parse_bank(), then it won't catch the
> > following invalid configuration:
> >
>
> Ok I see what it is for now.
>
> Not sure why it is declared as a pointer though.
It's so that lm3630a_parse_bank() can update that value with the
led-sources that have been seen. Otherwise, the changes wouldn't make
their way back out to the outer function.
Brian
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 3/3] backlight: lm3630a: add firmware node support
On Tue, Apr 23, 2019 at 08:49:20AM -0500, Dan Murphy wrote:
> > +static int lm3630a_parse_led_sources(struct fwnode_handle *node,
> > +int default_led_sources)
> > +{
> > + u32 sources[LM3630A_NUM_SINKS];
> > + int ret, num_sources, i;
> > +
> > + num_sources = fwnode_property_read_u32_array(node, "led-sources", NULL,
> > +0);
> > + if (num_sources < 0)
> > + return default_led_sources;
> > + else if (num_sources > ARRAY_SIZE(sources))
> > + return -EINVAL;
> > +
> > + ret = fwnode_property_read_u32_array(node, "led-sources", sources,
> > +num_sources);
> > + if (ret)
> > + return ret;
> > +
> > + for (i = 0; i < num_sources; i++) {
> > + if (sources[i] < LM3630A_SINK_0 || sources[i] > LM3630A_SINK_1)
> > + return -EINVAL;
> > +
> > + ret |= BIT(sources[i]);
> > + }
> > +
> > + return ret;
> > +}
> > +
> > +static int lm3630a_parse_bank(struct lm3630a_platform_data *pdata,
> > + struct fwnode_handle *node, int *seen_led_sources)
>
> Why is seen_led_sources passed in here?
> It is initialized on the stack in lm3630a_parse_node but the variable is
> never referenced in that API.
It's to see all of the led-sources that are configured across all of the
banks. If it is just in lm3630a_parse_bank(), then it won't catch the
following invalid configuration:
led@0 {
reg = <0>;
led-sources = <0 1>;
label = "lcd-backlight";
default-brightness = <200>;
};
led@1 {
reg = <1>;
default-brightness = <150>;
};
Brian
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v6 2/3] dt-bindings: backlight: add lm3630a bindings
Add new backlight bindings for the TI LM3630A dual-string white LED.
Signed-off-by: Brian Masney
Reviewed-by: Rob Herring
---
Changes since v5:
- Change 'lm3630a_bl@38' in examples to 'led-controller@38'
Changes since v4:
- Drop $ref from led-sources
- Drop description from reg of i2c address
- Expand description of reg for the control bank
- Drop status from examples
Changes since v3:
- Add label. I didn't add a description for it since that'll come from
the common properties once its converted.
Changes since v2:
- Update description of max-brightness
- Add description for reg
- Correct typo: s/tranisiton/transition
- add reg to control banks
- add additionalProperties
.../leds/backlight/lm3630a-backlight.yaml | 129 ++
1 file changed, 129 insertions(+)
create mode 100644
Documentation/devicetree/bindings/leds/backlight/lm3630a-backlight.yaml
diff --git
a/Documentation/devicetree/bindings/leds/backlight/lm3630a-backlight.yaml
b/Documentation/devicetree/bindings/leds/backlight/lm3630a-backlight.yaml
new file mode 100644
index ..4d61fe0a98a4
--- /dev/null
+++ b/Documentation/devicetree/bindings/leds/backlight/lm3630a-backlight.yaml
@@ -0,0 +1,129 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/leds/backlight/lm3630a-backlight.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: TI LM3630A High-Efficiency Dual-String White LED
+
+maintainers:
+ - Lee Jones
+ - Daniel Thompson
+ - Jingoo Han
+
+description: |
+ The LM3630A is a current-mode boost converter which supplies the power and
+ controls the current in up to two strings of 10 LEDs per string.
+ https://www.ti.com/product/LM3630A
+
+properties:
+ compatible:
+const: ti,lm3630a
+
+ reg:
+maxItems: 1
+
+ ti,linear-mapping-mode:
+description: |
+ Enable linear mapping mode. If disabled, then it will use exponential
+ mapping mode in which the ramp up/down appears to have a more uniform
+ transition to the human eye.
+type: boolean
+
+required:
+ - compatible
+ - reg
+
+patternProperties:
+ "^led@[01]$":
+type: object
+description: |
+ Properties for a string of connected LEDs.
+
+properties:
+ reg:
+description: |
+ The control bank that is used to program the two current sinks. The
+ LM3630A has two control banks (A and B) and are represented as 0 or 1
+ in this property. The two current sinks can be controlled
+ independently with both banks, or bank A can be configured to control
+ both sinks with the led-sources property.
+maxItems: 1
+minimum: 0
+maximum: 1
+
+ label:
+maxItems: 1
+
+ led-sources:
+allOf:
+ - minItems: 1
+maxItems: 2
+items:
+ minimum: 0
+ maximum: 1
+
+ default-brightness:
+description: Default brightness level on boot.
+minimum: 0
+maximum: 255
+
+ max-brightness:
+description: Maximum brightness that is allowed during runtime.
+minimum: 0
+maximum: 255
+
+required:
+ - reg
+
+additionalProperties: false
+
+additionalProperties: false
+
+examples:
+ - |
+i2c {
+#address-cells = <1>;
+#size-cells = <0>;
+
+led-controller@38 {
+compatible = "ti,lm3630a";
+reg = <0x38>;
+
+#address-cells = <1>;
+#size-cells = <0>;
+
+led@0 {
+reg = <0>;
+led-sources = <0 1>;
+label = "lcd-backlight";
+default-brightness = <200>;
+max-brightness = <255>;
+};
+};
+};
+ - |
+i2c {
+#address-cells = <1>;
+#size-cells = <0>;
+
+led-controller@38 {
+compatible = "ti,lm3630a";
+reg = <0x38>;
+
+#address-cells = <1>;
+#size-cells = <0>;
+
+led@0 {
+reg = <0>;
+default-brightness = <150>;
+ti,linear-mapping-mode;
+};
+
+led@1 {
+reg = <1>;
+default-brightness = <225>;
+ti,linear-mapping-mode;
+};
+};
+};
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v6 1/3] backlight: lm3630a: return 0 on success in update_status functions
lm3630a_bank_a_update_status() and lm3630a_bank_b_update_status()
both return the brightness value if the brightness was successfully
updated. Writing to these attributes via sysfs would cause a 'Bad
address' error to be returned. These functions should return 0 on
success, so let's change it to correct that error.
Signed-off-by: Brian Masney
Fixes: 28e64a68a2ef ("backlight: lm3630: apply chip revision")
Acked-by: Pavel Machek
---
No changes since v2 when this patch was originally introduced.
drivers/video/backlight/lm3630a_bl.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/video/backlight/lm3630a_bl.c
b/drivers/video/backlight/lm3630a_bl.c
index 2030a6b77a09..ef2553f452ca 100644
--- a/drivers/video/backlight/lm3630a_bl.c
+++ b/drivers/video/backlight/lm3630a_bl.c
@@ -201,7 +201,7 @@ static int lm3630a_bank_a_update_status(struct
backlight_device *bl)
LM3630A_LEDA_ENABLE, LM3630A_LEDA_ENABLE);
if (ret < 0)
goto out_i2c_err;
- return bl->props.brightness;
+ return 0;
out_i2c_err:
dev_err(pchip->dev, "i2c failed to access\n");
@@ -278,7 +278,7 @@ static int lm3630a_bank_b_update_status(struct
backlight_device *bl)
LM3630A_LEDB_ENABLE, LM3630A_LEDB_ENABLE);
if (ret < 0)
goto out_i2c_err;
- return bl->props.brightness;
+ return 0;
out_i2c_err:
dev_err(pchip->dev, "i2c failed to access REG_CTRL\n");
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v6 0/3] backlight: lm3630a: bug fix and fwnode support
Here is a patch series that fixes a single bug and adds fwnode support to the lm3630a driver. This work was tested on a LG Nexus 5 (hammerhead) phone. My status page at https://masneyb.github.io/nexus-5-upstream/ describes what is working so far with the upstream kernel. See the individual patches for the changelog. Brian Masney (3): backlight: lm3630a: return 0 on success in update_status functions dt-bindings: backlight: add lm3630a bindings backlight: lm3630a: add firmware node support .../leds/backlight/lm3630a-backlight.yaml | 129 +++ drivers/video/backlight/lm3630a_bl.c | 153 +- include/linux/platform_data/lm3630a_bl.h | 4 + 3 files changed, 279 insertions(+), 7 deletions(-) create mode 100644 Documentation/devicetree/bindings/leds/backlight/lm3630a-backlight.yaml -- 2.20.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v6 3/3] backlight: lm3630a: add firmware node support
Add fwnode support to the lm3630a driver and optionally allow
configuring the label, default brightness level, and maximum brightness
level. The two outputs can be controlled by bank A and B independently
or bank A can control both outputs.
If the platform data was not configured, then the driver defaults to
enabling both banks. This patch changes the default value to disable
both banks before parsing the firmware node so that just a single bank
can be enabled if desired. There are no in-tree users of this driver.
Driver was tested on a LG Nexus 5 (hammerhead) phone.
Signed-off-by: Brian Masney
Reviewed-by: Dan Murphy
---
Changes since v5
- None
Changes since v4
- Added new function lm3630a_parse_bank()
- Renamed seen variable to seen_led_sources
- Use the bitmask returned from lm3630a_parse_led_sources() to compare
against the seen_led_sources rather than just the control bank. This
eliminated another if statement that was previously present that
checked to see if control bank A should control both sinks.
- #define LM3630A_BANK_0, LM3630A_BANK_1, LM3630A_SINK_0,
LM3630A_SINK_1, and LM3630A_NUM_SINKS and use where appropriate.
- Changed all occurances of
'if (bank == 0) { BANK_A_WORK } else { BANK_B_WORK }' to
'if (bank) { BANK_B_WORK } else { BANK_A_WORK }'
- Dropped unnecessary 'ret = 0' from lm3630a_parse_led_sources().
- Changed 'if (ret < 0)' to 'if (ret)' in lm3630a_parse_node().
- Dropped kerneldoc from lm3630a_parse_led_sources().
Changes since v3
- Add support for label
- Changed lm3630a_parse_node() to return -ENODEV if no nodes were found
- Remove LM3630A_LED{A,B}_DISABLE
- Add two additional newlines for code readability
- Remove extra newline
Changes since v2
- Separated out control banks and outputs via the reg and led-sources
properties.
- Use fwnode instead of of API
- Disable both banks by default before calling lm3630a_parse_node()
- Add lots of error handling
- Check for duplicate source / bank definitions
- Remove extra ;
- Make probe() method fail if fwnode parsing fails.
drivers/video/backlight/lm3630a_bl.c | 149 ++-
include/linux/platform_data/lm3630a_bl.h | 4 +
2 files changed, 148 insertions(+), 5 deletions(-)
diff --git a/drivers/video/backlight/lm3630a_bl.c
b/drivers/video/backlight/lm3630a_bl.c
index ef2553f452ca..75d996490cf0 100644
--- a/drivers/video/backlight/lm3630a_bl.c
+++ b/drivers/video/backlight/lm3630a_bl.c
@@ -35,6 +35,14 @@
#define REG_MAX0x50
#define INT_DEBOUNCE_MSEC 10
+
+#define LM3630A_BANK_0 0
+#define LM3630A_BANK_1 1
+
+#define LM3630A_NUM_SINKS 2
+#define LM3630A_SINK_0 0
+#define LM3630A_SINK_1 1
+
struct lm3630a_chip {
struct device *dev;
struct delayed_work work;
@@ -329,15 +337,17 @@ static const struct backlight_ops lm3630a_bank_b_ops = {
static int lm3630a_backlight_register(struct lm3630a_chip *pchip)
{
- struct backlight_properties props;
struct lm3630a_platform_data *pdata = pchip->pdata;
+ struct backlight_properties props;
+ const char *label;
props.type = BACKLIGHT_RAW;
if (pdata->leda_ctrl != LM3630A_LEDA_DISABLE) {
props.brightness = pdata->leda_init_brt;
props.max_brightness = pdata->leda_max_brt;
+ label = pdata->leda_label ? pdata->leda_label : "lm3630a_leda";
pchip->bleda =
- devm_backlight_device_register(pchip->dev, "lm3630a_leda",
+ devm_backlight_device_register(pchip->dev, label,
pchip->dev, pchip,
&lm3630a_bank_a_ops, &props);
if (IS_ERR(pchip->bleda))
@@ -348,8 +358,9 @@ static int lm3630a_backlight_register(struct lm3630a_chip
*pchip)
(pdata->ledb_ctrl != LM3630A_LEDB_ON_A)) {
props.brightness = pdata->ledb_init_brt;
props.max_brightness = pdata->ledb_max_brt;
+ label = pdata->ledb_label ? pdata->ledb_label : "lm3630a_ledb";
pchip->bledb =
- devm_backlight_device_register(pchip->dev, "lm3630a_ledb",
+ devm_backlight_device_register(pchip->dev, label,
pchip->dev, pchip,
&lm3630a_bank_b_ops, &props);
if (IS_ERR(pchip->bledb))
@@ -364,6 +375,123 @@ static const struct regmap_config lm3630a_regmap = {
.max_register = REG_MAX,
};
+static int lm3630a_parse_led_sources(struct fwnode_handle *node,
+int default_led_sources)
+{
+ u32 sources[LM3630A_NUM_SINKS];
+ int ret, num_source
Re: [Freedreno] [PATCH RFC v2 0/6] ARM: qcom: initial Nexus 5 display support
On Wed, May 29, 2019 at 08:41:31AM -0600, Jeffrey Hugo wrote: > On Wed, May 29, 2019 at 4:28 AM Brian Masney wrote: > > > > On Tue, May 28, 2019 at 08:53:49PM -0600, Jeffrey Hugo wrote: > > > On Tue, May 28, 2019 at 8:46 PM Brian Masney > > > wrote: > > > > > > > > On Tue, May 28, 2019 at 07:42:19PM -0600, Jeffrey Hugo wrote: > > > > > > > Do you know if the nexus 5 has a video or command mode panel? > > > > > > > There > > > > > > > is some glitchyness with vblanks and command mode panels. > > > > > > > > > > > > Its in command mode. I know this because I see two 'pp done time > > > > > > out' > > > > > > messages, even on 4.17. Based on my understanding, the ping pong > > > > > > code is > > > > > > only applicable for command mode panels. > > > > > > > > > > Actually, the ping pong element exists in both modes, but 'pp done > > > > > time out' is a good indicator that it is command mode. > > > > > > > > > > Are you also seeing vblank timeouts? > > > > > > > > Yes, here's a snippet of the first one. > > > > > > > > [2.556014] WARNING: CPU: 0 PID: 5 at > > > > drivers/gpu/drm/drm_atomic_helper.c:1429 > > > > drm_atomic_helper_wait_for_vblanks.part.1+0x288/0x290 > > > > [2.556020] [CRTC:49:crtc-0] vblank wait timed out > > > > [2.556023] Modules linked in: > > > > [2.556034] CPU: 0 PID: 5 Comm: kworker/0:0 Not tainted > > > > 5.2.0-rc1-00178-g72c3c1fd5f86-dirty #426 > > > > [2.556038] Hardware name: Generic DT based system > > > > [2.556056] Workqueue: events deferred_probe_work_func > > > > ... > > > > > > > > > Do you have busybox? > > > > > > > > > > Can you run - > > > > > sudo busybox devmem 0xFD900614 > > > > > sudo busybox devmem 0xFD900714 > > > > > sudo busybox devmem 0xFD900814 > > > > > sudo busybox devmem 0xFD900914 > > > > > sudo busybox devmem 0xFD900A14 > > > > > > > > # busybox devmem 0xFD900614 > > > > 0x00020020 > > > > > > Ok, so CTL_0 path, command mode, ping pong 0, with the output going to > > > DSI 1. > > > > > > Next one please: > > > > > > busybox devmem 0xFD912D30 > > > > It's 0x on mainline and 4.17. I used the following script to > > dump the entire mdp5 memory region and attached the dump from 4.17 and > > 5.2rc1. > > > > ok, 0 means autorefresh is not on. Which is fine. My next guess > would be the vblank code checking the hardware vblank counter, which > doesn't exist. > In video mode, there is a frame counter which increments, which can be > used as the vblank counter. Unfortunately, that hardware isn't active > in command mode, and there isn't an equivalent. > > So, the vblank code is going to read the register, and look for an > update, which will never happen, thus it will timeout. There is a > backup path which uses timestamps (no hardware), which you can > activate with a quick hack - make max_vblank_count = 0 at the > following line > https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c#L753 That fixed the issue! I previously observed that mdp5_get_vblank_counter, specifically mdp5_encoder_get_framecount, would always return 0. What's the best way to fix this in mainline? Set that to zero if any of the interface modes is MDP5_INTF_DSI_MODE_COMMAND? Brian
Re: [Freedreno] [PATCH RFC v2 0/6] ARM: qcom: initial Nexus 5 display support
On Wed, May 29, 2019 at 01:58:16PM -0600, Jeffrey Hugo wrote: > On 5/29/2019 1:30 PM, Brian Masney wrote: > > On Wed, May 29, 2019 at 08:41:31AM -0600, Jeffrey Hugo wrote: > > > On Wed, May 29, 2019 at 4:28 AM Brian Masney > > > wrote: > > > > > > > > On Tue, May 28, 2019 at 08:53:49PM -0600, Jeffrey Hugo wrote: > > > > > On Tue, May 28, 2019 at 8:46 PM Brian Masney > > > > > wrote: > > > > > > > > > > > > On Tue, May 28, 2019 at 07:42:19PM -0600, Jeffrey Hugo wrote: > > > > > > > > > Do you know if the nexus 5 has a video or command mode panel? > > > > > > > > > There > > > > > > > > > is some glitchyness with vblanks and command mode panels. > > > > > > > > > > > > > > > > Its in command mode. I know this because I see two 'pp done > > > > > > > > time out' > > > > > > > > messages, even on 4.17. Based on my understanding, the ping > > > > > > > > pong code is > > > > > > > > only applicable for command mode panels. > > > > > > > > > > > > > > Actually, the ping pong element exists in both modes, but 'pp done > > > > > > > time out' is a good indicator that it is command mode. > > > > > > > > > > > > > > Are you also seeing vblank timeouts? > > > > > > > > > > > > Yes, here's a snippet of the first one. > > > > > > > > > > > > [2.556014] WARNING: CPU: 0 PID: 5 at > > > > > > drivers/gpu/drm/drm_atomic_helper.c:1429 > > > > > > drm_atomic_helper_wait_for_vblanks.part.1+0x288/0x290 > > > > > > [2.556020] [CRTC:49:crtc-0] vblank wait timed out > > > > > > [2.556023] Modules linked in: > > > > > > [2.556034] CPU: 0 PID: 5 Comm: kworker/0:0 Not tainted > > > > > > 5.2.0-rc1-00178-g72c3c1fd5f86-dirty #426 > > > > > > [2.556038] Hardware name: Generic DT based system > > > > > > [2.556056] Workqueue: events deferred_probe_work_func > > > > > > ... > > > > > > > > > > > > > Do you have busybox? > > > > > > > > > > > > > > Can you run - > > > > > > > sudo busybox devmem 0xFD900614 > > > > > > > sudo busybox devmem 0xFD900714 > > > > > > > sudo busybox devmem 0xFD900814 > > > > > > > sudo busybox devmem 0xFD900914 > > > > > > > sudo busybox devmem 0xFD900A14 > > > > > > > > > > > > # busybox devmem 0xFD900614 > > > > > > 0x00020020 > > > > > > > > > > Ok, so CTL_0 path, command mode, ping pong 0, with the output going > > > > > to DSI 1. > > > > > > > > > > Next one please: > > > > > > > > > > busybox devmem 0xFD912D30 > > > > > > > > It's 0x on mainline and 4.17. I used the following script to > > > > dump the entire mdp5 memory region and attached the dump from 4.17 and > > > > 5.2rc1. > > > > > > > > > > ok, 0 means autorefresh is not on. Which is fine. My next guess > > > would be the vblank code checking the hardware vblank counter, which > > > doesn't exist. > > > In video mode, there is a frame counter which increments, which can be > > > used as the vblank counter. Unfortunately, that hardware isn't active > > > in command mode, and there isn't an equivalent. > > > > > > So, the vblank code is going to read the register, and look for an > > > update, which will never happen, thus it will timeout. There is a > > > backup path which uses timestamps (no hardware), which you can > > > activate with a quick hack - make max_vblank_count = 0 at the > > > following line > > > https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c#L753 > > > > That fixed the issue! > > Awesome. I'm glad it was something simple. > > > > > I previously observed that mdp5_get_vblank_counter, specifically > > mdp5_encoder_get_framecount, would always return 0. > > > > What's the best way to fix this in mainline? Set that to zero if any > > of the interface modes is MDP5_INTF_DSI_MODE_COMMAND? > > > > Short version, yes. Long version: > > I still have that hack in my tree and haven't come back to formulating > a proper fix yet. Feel free to run with it. > > Thinking about it briefly, we could do two things. We could fake a > hardware counter by just increment an int every time the vblank irq is > processed, but that seems clunky. Otherwise, we could force a > fallback onto the timestamp solution, which seems less invasive. > > In theory, we could service multiple displays, with different > properties (ie a combination of command and video mode). The hack > then, is not good, because it would break video mode (at-least we > wouldn't be using the register when we could). It would be great if > the use of the hardware register could be done per display. > > Luckily, it looks like someone just made that possible - > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/gpu/drm/drm_vblank.c?h=v5.2-rc2&id=ed20151a7699bb2c77eba3610199789a126940c4 I'll work on this for the msm driver. Thanks for the info! Brian
[PATCH v3 3/6] ARM: qcom_defconfig: add display-related options
Add the CMA (Contiguous Memory Allocator) for the MSM DRM/KMS driver, the simple panel, and the TI LM3630A driver in order to support the display on the LG Nexus 5 (hammerhead) phone. Signed-off-by: Brian Masney Reviewed-by: Linus Walleij --- arch/arm/configs/qcom_defconfig | 5 + 1 file changed, 5 insertions(+) diff --git a/arch/arm/configs/qcom_defconfig b/arch/arm/configs/qcom_defconfig index c1854751c99a..4f02636f832e 100644 --- a/arch/arm/configs/qcom_defconfig +++ b/arch/arm/configs/qcom_defconfig @@ -37,6 +37,7 @@ CONFIG_ARM_CPUIDLE=y CONFIG_VFP=y CONFIG_NEON=y # CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS is not set +CONFIG_CMA=y CONFIG_NET=y CONFIG_PACKET=y CONFIG_UNIX=y @@ -146,12 +147,14 @@ CONFIG_REGULATOR_QCOM_SMD_RPM=y CONFIG_REGULATOR_QCOM_SPMI=y CONFIG_MEDIA_SUPPORT=y CONFIG_DRM=y +CONFIG_DRM_PANEL_SIMPLE=y CONFIG_FB=y CONFIG_FRAMEBUFFER_CONSOLE=y CONFIG_BACKLIGHT_LCD_SUPPORT=y # CONFIG_LCD_CLASS_DEVICE is not set CONFIG_BACKLIGHT_CLASS_DEVICE=y # CONFIG_BACKLIGHT_GENERIC is not set +CONFIG_BACKLIGHT_LM3630A=y CONFIG_BACKLIGHT_LP855X=y CONFIG_SOUND=y CONFIG_SND=y @@ -262,6 +265,8 @@ CONFIG_NLS_CODEPAGE_437=y CONFIG_NLS_ASCII=y CONFIG_NLS_ISO8859_1=y CONFIG_NLS_UTF8=y +CONFIG_DMA_CMA=y +CONFIG_CMA_SIZE_MBYTES=256 CONFIG_PRINTK_TIME=y CONFIG_DYNAMIC_DEBUG=y CONFIG_DEBUG_INFO=y -- 2.20.1
[PATCH v3 6/6] ARM: dts: qcom: msm8974-hammerhead: add support for display
Add initial support for the display found on the LG Nexus 5 (hammerhead)
phone. This is based on work from Jonathan Marek.
Signed-off-by: Brian Masney
---
.../qcom-msm8974-lge-nexus5-hammerhead.dts| 58 +++
1 file changed, 58 insertions(+)
diff --git a/arch/arm/boot/dts/qcom-msm8974-lge-nexus5-hammerhead.dts
b/arch/arm/boot/dts/qcom-msm8974-lge-nexus5-hammerhead.dts
index 51889d66b55a..4776f01f492c 100644
--- a/arch/arm/boot/dts/qcom-msm8974-lge-nexus5-hammerhead.dts
+++ b/arch/arm/boot/dts/qcom-msm8974-lge-nexus5-hammerhead.dts
@@ -332,6 +332,16 @@
function = "gpio";
};
};
+
+ panel_pin: panel {
+ te {
+ pins = "gpio12";
+ function = "mdp_vsync";
+
+ drive-strength = <2>;
+ bias-disable;
+ };
+ };
};
vibrator@fd8c3450 {
@@ -531,6 +541,54 @@
};
};
};
+
+ mdss@fd90 {
+ status = "ok";
+
+ mdp@fd90 {
+ status = "ok";
+ };
+
+ dsi@fd922800 {
+ status = "ok";
+
+ vdda-supply = <&pm8941_l2>;
+ vdd-supply = <&pm8941_lvs3>;
+ vddio-supply = <&pm8941_l12>;
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ports {
+ port@1 {
+ endpoint {
+ remote-endpoint = <&panel_in>;
+ data-lanes = <0 1 2 3>;
+ };
+ };
+ };
+
+ panel: panel@0 {
+ reg = <0>;
+ compatible = "lg,acx467akm-7";
+
+ pinctrl-names = "default";
+ pinctrl-0 = <&panel_pin>;
+
+ port {
+ panel_in: endpoint {
+ remote-endpoint = <&dsi0_out>;
+ };
+ };
+ };
+ };
+
+ dsi-phy@fd922a00 {
+ status = "ok";
+
+ vddio-supply = <&pm8941_l12>;
+ };
+ };
};
&spmi_bus {
--
2.20.1
[PATCH v3 1/6] drm/msm: add dirty framebuffer helper
Use drm_atomic_helper_dirtyfb() as the dirty callback in the
msm_framebuffer_funcs struct. Call drm_plane_enable_fb_damage_clips()
when the planes are initialized in mdp4, mdp5, and dpu1.
Signed-off-by: Brian Masney
---
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 3 +++
drivers/gpu/drm/msm/disp/mdp4/mdp4_plane.c | 3 +++
drivers/gpu/drm/msm/disp/mdp5/mdp5_plane.c | 3 +++
drivers/gpu/drm/msm/msm_fb.c | 2 ++
4 files changed, 11 insertions(+)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
index d831cedb55ec..2ea42f50401f 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
@@ -21,6 +21,7 @@
#include
#include
+#include
#include
#include "msm_drv.h"
@@ -1535,6 +1536,8 @@ struct drm_plane *dpu_plane_init(struct drm_device *dev,
if (ret)
DPU_ERROR("failed to install zpos property, rc = %d\n", ret);
+ drm_plane_enable_fb_damage_clips(plane);
+
/* success! finalize initialization */
drm_plane_helper_add(plane, &dpu_plane_helper_funcs);
diff --git a/drivers/gpu/drm/msm/disp/mdp4/mdp4_plane.c
b/drivers/gpu/drm/msm/disp/mdp4/mdp4_plane.c
index 005066f7154d..2d46d1126283 100644
--- a/drivers/gpu/drm/msm/disp/mdp4/mdp4_plane.c
+++ b/drivers/gpu/drm/msm/disp/mdp4/mdp4_plane.c
@@ -15,6 +15,7 @@
* this program. If not, see <http://www.gnu.org/licenses/>.
*/
+#include
#include "mdp4_kms.h"
#define DOWN_SCALE_MAX 8
@@ -391,6 +392,8 @@ struct drm_plane *mdp4_plane_init(struct drm_device *dev,
mdp4_plane_install_properties(plane, &plane->base);
+ drm_plane_enable_fb_damage_clips(plane);
+
return plane;
fail:
diff --git a/drivers/gpu/drm/msm/disp/mdp5/mdp5_plane.c
b/drivers/gpu/drm/msm/disp/mdp5/mdp5_plane.c
index 9d9fb6c5fd68..9a9ae44655b4 100644
--- a/drivers/gpu/drm/msm/disp/mdp5/mdp5_plane.c
+++ b/drivers/gpu/drm/msm/disp/mdp5/mdp5_plane.c
@@ -16,6 +16,7 @@
* this program. If not, see <http://www.gnu.org/licenses/>.
*/
+#include
#include
#include "mdp5_kms.h"
@@ -1095,6 +1096,8 @@ struct drm_plane *mdp5_plane_init(struct drm_device *dev,
mdp5_plane_install_properties(plane, &plane->base);
+ drm_plane_enable_fb_damage_clips(plane);
+
return plane;
fail:
diff --git a/drivers/gpu/drm/msm/msm_fb.c b/drivers/gpu/drm/msm/msm_fb.c
index 68fa2c8f61e6..a816ceb58716 100644
--- a/drivers/gpu/drm/msm/msm_fb.c
+++ b/drivers/gpu/drm/msm/msm_fb.c
@@ -16,6 +16,7 @@
*/
#include
+#include
#include
#include
@@ -35,6 +36,7 @@ static struct drm_framebuffer *msm_framebuffer_init(struct
drm_device *dev,
static const struct drm_framebuffer_funcs msm_framebuffer_funcs = {
.create_handle = drm_gem_fb_create_handle,
.destroy = drm_gem_fb_destroy,
+ .dirty = drm_atomic_helper_dirtyfb,
};
#ifdef CONFIG_DEBUG_FS
--
2.20.1
[PATCH v3 2/6] drm/msm: add support for per-CRTC max_vblank_count on mdp5
The mdp5 drm/kms driver currently does not work on command-mode DSI
panels due to 'vblank wait timed out' errors. This causes a latency
of seconds, or tens of seconds in some cases, before content is shown
on the panel. This hardware does not have the something that we can use
as a frame counter available when running in command mode, so we need to
fall back to using timestamps by setting the max_vblank_count to zero.
This can be done on a per-CRTC basis, so the convert mdp5 to use
drm_crtc_set_max_vblank_count().
This change was tested on a LG Nexus 5 (hammerhead) phone.
Signed-off-by: Brian Masney
Suggested-by: Jeffrey Hugo
---
drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c | 16 +++-
drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c | 2 +-
2 files changed, 16 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c
b/drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c
index c3751c95b452..6fde1097844f 100644
--- a/drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c
+++ b/drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c
@@ -450,6 +450,18 @@ static void mdp5_crtc_atomic_disable(struct drm_crtc *crtc,
mdp5_crtc->enabled = false;
}
+static void mdp5_crtc_vblank_on(struct drm_crtc *crtc)
+{
+ struct mdp5_crtc_state *mdp5_cstate = to_mdp5_crtc_state(crtc->state);
+ struct mdp5_interface *intf = mdp5_cstate->pipeline.intf;
+ u32 count;
+
+ count = intf->mode == MDP5_INTF_DSI_MODE_COMMAND ? 0 : 0x;
+ drm_crtc_set_max_vblank_count(crtc, count);
+
+ drm_crtc_vblank_on(crtc);
+}
+
static void mdp5_crtc_atomic_enable(struct drm_crtc *crtc,
struct drm_crtc_state *old_state)
{
@@ -486,7 +498,7 @@ static void mdp5_crtc_atomic_enable(struct drm_crtc *crtc,
}
/* Restore vblank irq handling after power is enabled */
- drm_crtc_vblank_on(crtc);
+ mdp5_crtc_vblank_on(crtc);
mdp5_crtc_mode_set_nofb(crtc);
@@ -1039,6 +1051,8 @@ static void mdp5_crtc_reset(struct drm_crtc *crtc)
mdp5_crtc_destroy_state(crtc, crtc->state);
__drm_atomic_helper_crtc_reset(crtc, &mdp5_cstate->base);
+
+ drm_crtc_vblank_reset(crtc);
}
static const struct drm_crtc_funcs mdp5_crtc_funcs = {
diff --git a/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
b/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
index 97179bec8902..fcb0b0455abe 100644
--- a/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
+++ b/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
@@ -750,7 +750,7 @@ struct msm_kms *mdp5_kms_init(struct drm_device *dev)
dev->driver->get_vblank_timestamp =
drm_calc_vbltimestamp_from_scanoutpos;
dev->driver->get_scanout_position = mdp5_get_scanoutpos;
dev->driver->get_vblank_counter = mdp5_get_vblank_counter;
- dev->max_vblank_count = 0x;
+ dev->max_vblank_count = 0; /* max_vblank_count is set on each CRTC */
dev->vblank_disable_immediate = true;
return kms;
--
2.20.1
[PATCH v3 5/6] ARM: dts: msm8974: add display support
Add the MDP5, DSI and DSI PHY blocks for the display found on the
msm8974 SoCs. This is based on work from msm8916.dtsi and Jonathan
Marek.
Signed-off-by: Brian Masney
Reviewed-by: Linus Walleij
---
arch/arm/boot/dts/qcom-msm8974.dtsi | 132
1 file changed, 132 insertions(+)
diff --git a/arch/arm/boot/dts/qcom-msm8974.dtsi
b/arch/arm/boot/dts/qcom-msm8974.dtsi
index 45b5c8ef0374..3f613c5b95a1 100644
--- a/arch/arm/boot/dts/qcom-msm8974.dtsi
+++ b/arch/arm/boot/dts/qcom-msm8974.dtsi
@@ -3,6 +3,7 @@
#include
#include
+#include
#include
#include
#include
@@ -1085,6 +1086,137 @@
};
};
};
+
+ mdss: mdss@fd90 {
+ status = "disabled";
+
+ compatible = "qcom,mdss";
+ reg = <0xfd90 0x100>,
+ <0xfd924000 0x1000>;
+ reg-names = "mdss_phys",
+ "vbif_phys";
+
+ power-domains = <&mmcc MDSS_GDSC>;
+
+ clocks = <&mmcc MDSS_AHB_CLK>,
+<&mmcc MDSS_AXI_CLK>,
+<&mmcc MDSS_VSYNC_CLK>;
+ clock-names = "iface",
+ "bus",
+ "vsync";
+
+ interrupts = ;
+
+ interrupt-controller;
+ #interrupt-cells = <1>;
+
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ mdp: mdp@fd90 {
+ status = "disabled";
+
+ compatible = "qcom,mdp5";
+ reg = <0xfd900100 0x22000>;
+ reg-names = "mdp_phys";
+
+ interrupt-parent = <&mdss>;
+ interrupts = <0 0>;
+
+ clocks = <&mmcc MDSS_AHB_CLK>,
+<&mmcc MDSS_AXI_CLK>,
+<&mmcc MDSS_MDP_CLK>,
+<&mmcc MDSS_VSYNC_CLK>;
+ clock-names = "iface",
+ "bus",
+ "core",
+ "vsync";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ mdp5_intf1_out: endpoint {
+ remote-endpoint =
<&dsi0_in>;
+ };
+ };
+ };
+ };
+
+ dsi0: dsi@fd922800 {
+ status = "disabled";
+
+ compatible = "qcom,mdss-dsi-ctrl";
+ reg = <0xfd922800 0x1f8>;
+ reg-names = "dsi_ctrl";
+
+ interrupt-parent = <&mdss>;
+ interrupts = <4 IRQ_TYPE_LEVEL_HIGH>;
+
+ assigned-clocks = <&mmcc BYTE0_CLK_SRC>,
+ <&mmcc PCLK0_CLK_SRC>;
+ assigned-clock-parents = <&dsi_phy0 0>,
+<&dsi_phy0 1>;
+
+ clocks = <&mmcc MDSS_MDP_CLK>,
+<&mmcc MDSS_AHB_CLK>,
+<&mmcc MDSS_AXI_CLK>,
+<&mmcc MDSS_BYTE0_CLK>,
+<&mmcc MDSS_PCLK0_CLK>,
+<&mmcc MDSS_ESC0_CLK>,
+<&mmcc MMSS_MISC_AHB_CLK>;
+ clock-names = "mdp_core",
+ "iface",
+ "bus",
+ &quo
[PATCH v3 4/6] ARM: dts: qcom: msm8974-hammerhead: add support for backlight
Add necessary device tree nodes for the main LCD backlight.
Signed-off-by: Brian Masney
Reviewed-by: Linus Walleij
---
.../qcom-msm8974-lge-nexus5-hammerhead.dts| 34 +++
1 file changed, 34 insertions(+)
diff --git a/arch/arm/boot/dts/qcom-msm8974-lge-nexus5-hammerhead.dts
b/arch/arm/boot/dts/qcom-msm8974-lge-nexus5-hammerhead.dts
index 1fd9f429f34a..51889d66b55a 100644
--- a/arch/arm/boot/dts/qcom-msm8974-lge-nexus5-hammerhead.dts
+++ b/arch/arm/boot/dts/qcom-msm8974-lge-nexus5-hammerhead.dts
@@ -290,6 +290,16 @@
};
};
+ i2c11_pins: i2c11 {
+ mux {
+ pins = "gpio83", "gpio84";
+ function = "blsp_i2c11";
+
+ drive-strength = <2>;
+ bias-disable;
+ };
+ };
+
i2c12_pins: i2c12 {
mux {
pins = "gpio87", "gpio88";
@@ -400,6 +410,30 @@
};
};
+ i2c@f9967000 {
+ status = "ok";
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c11_pins>;
+ clock-frequency = <355000>;
+ qcom,src-freq = <5000>;
+
+ led-controller@38 {
+ compatible = "ti,lm3630a";
+ status = "ok";
+ reg = <0x38>;
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ led@0 {
+ reg = <0>;
+ led-sources = <0 1>;
+ label = "lcd-backlight";
+ default-brightness = <200>;
+ };
+ };
+ };
+
i2c@f9968000 {
status = "ok";
pinctrl-names = "default";
--
2.20.1
[PATCH v3 0/6] ARM: qcom: working Nexus 5 display support
This patch series adds working display support to the LG Nexus 5 (hammerhead) phone. Changes since v2: - Dropped two drm/msm bug fix patches that have been merged separately. - New patch: 'add support for per-CRTC max_vblank_count on mdp5'. Special thanks to Jeffrey Hugo for helping to track down this issue. - Add panel_pin to msm8974-hammerhead device tree. Dropped Linus Walleij's reviewed-by on this patch due to this change. Changes since v1: - Shortened problem description above. I'll reply to this email and send a full dmesg with the boot log with debugging turned on. - Dropped patch 'fix null pointer dereference in msm_atomic_prepare_fb()' - New patch: Remove resv fields from msm_gem_object struct that was incorrectly being referenced by the prepare_fb callbacks. - Add drm_plane_enable_fb_damage_clips() to plane init for mdp4, mdp5, and dpu1. - Add Linus Walleij's reviewed-by to patches 3-6 My status page at https://masneyb.github.io/nexus-5-upstream/ describes what is working so far with the upstream kernel on the Nexus 5. Brian Masney (6): drm/msm: add dirty framebuffer helper drm/msm: add support for per-CRTC max_vblank_count on mdp5 ARM: qcom_defconfig: add display-related options ARM: dts: qcom: msm8974-hammerhead: add support for backlight ARM: dts: msm8974: add display support ARM: dts: qcom: msm8974-hammerhead: add support for display .../qcom-msm8974-lge-nexus5-hammerhead.dts| 92 arch/arm/boot/dts/qcom-msm8974.dtsi | 132 ++ arch/arm/configs/qcom_defconfig | 5 + drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 3 + drivers/gpu/drm/msm/disp/mdp4/mdp4_plane.c| 3 + drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c | 16 ++- drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c | 2 +- drivers/gpu/drm/msm/disp/mdp5/mdp5_plane.c| 3 + drivers/gpu/drm/msm/msm_fb.c | 2 + 9 files changed, 256 insertions(+), 2 deletions(-) -- 2.20.1
[PATCH] drm/msm: correct attempted NULL pointer dereference in put_iova
put_iova() would attempt to dereference a NULL pointer via the
address space pointer when no IOMMU is present. Correct this by adding
the appropriate check.
Signed-off-by: Brian Masney
---
drivers/gpu/drm/msm/msm_gem.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm_gem.c b/drivers/gpu/drm/msm/msm_gem.c
index 35f55dd25994..d31d9f927887 100644
--- a/drivers/gpu/drm/msm/msm_gem.c
+++ b/drivers/gpu/drm/msm/msm_gem.c
@@ -352,8 +352,10 @@ put_iova(struct drm_gem_object *obj)
WARN_ON(!mutex_is_locked(&msm_obj->lock));
list_for_each_entry_safe(vma, tmp, &msm_obj->vmas, list) {
- msm_gem_purge_vma(vma->aspace, vma);
- msm_gem_close_vma(vma->aspace, vma);
+ if (vma->aspace) {
+ msm_gem_purge_vma(vma->aspace, vma);
+ msm_gem_close_vma(vma->aspace, vma);
+ }
del_vma(vma);
}
}
--
2.20.1
[PATCH 6/6] drm/msm/gpu: add ocmem init/cleanup functions
The files a3xx_gpu.c and a4xx_gpu.c have ifdefs for the OCMEM support
that was missing upstream. Add two new functions (adreno_gpu_ocmem_init
and adreno_gpu_ocmem_cleanup) that removes some duplicated code. We also
need to change the ifdef check for CONFIG_MSM_OCMEM to CONFIG_QCOM_OCMEM
now that OCMEM support is upstream.
Signed-off-by: Brian Masney
---
drivers/gpu/drm/msm/adreno/a3xx_gpu.c | 33 +++-
drivers/gpu/drm/msm/adreno/a3xx_gpu.h | 3 +-
drivers/gpu/drm/msm/adreno/a4xx_gpu.c | 30 ++
drivers/gpu/drm/msm/adreno/a4xx_gpu.h | 3 +-
drivers/gpu/drm/msm/adreno/adreno_gpu.c | 41 +
drivers/gpu/drm/msm/adreno/adreno_gpu.h | 10 ++
6 files changed, 74 insertions(+), 46 deletions(-)
diff --git a/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
b/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
index c3b4bc6e4155..72720bb2aca1 100644
--- a/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
@@ -17,10 +17,6 @@
* this program. If not, see <http://www.gnu.org/licenses/>.
*/
-#ifdef CONFIG_MSM_OCMEM
-# include
-#endif
-
#include "a3xx_gpu.h"
#define A3XX_INT0_MASK \
@@ -206,9 +202,9 @@ static int a3xx_hw_init(struct msm_gpu *gpu)
gpu_write(gpu, REG_A3XX_RBBM_GPR0_CTL, 0x);
/* Set the OCMEM base address for A330, etc */
- if (a3xx_gpu->ocmem_hdl) {
+ if (a3xx_gpu->ocmem.hdl) {
gpu_write(gpu, REG_A3XX_RB_GMEM_BASE_ADDR,
- (unsigned int)(a3xx_gpu->ocmem_base >> 14));
+ (unsigned int)(a3xx_gpu->ocmem.base >> 14));
}
/* Turn on performance counters: */
@@ -329,10 +325,7 @@ static void a3xx_destroy(struct msm_gpu *gpu)
adreno_gpu_cleanup(adreno_gpu);
-#ifdef CONFIG_MSM_OCMEM
- if (a3xx_gpu->ocmem_base)
- ocmem_free(OCMEM_GRAPHICS, a3xx_gpu->ocmem_hdl);
-#endif
+ adreno_gpu_ocmem_cleanup(&a3xx_gpu->ocmem);
kfree(a3xx_gpu);
}
@@ -507,17 +500,10 @@ struct msm_gpu *a3xx_gpu_init(struct drm_device *dev)
/* if needed, allocate gmem: */
if (adreno_is_a330(adreno_gpu)) {
-#ifdef CONFIG_MSM_OCMEM
- /* TODO this is different/missing upstream: */
- struct ocmem_buf *ocmem_hdl =
- ocmem_allocate(OCMEM_GRAPHICS,
adreno_gpu->gmem);
-
- a3xx_gpu->ocmem_hdl = ocmem_hdl;
- a3xx_gpu->ocmem_base = ocmem_hdl->addr;
- adreno_gpu->gmem = ocmem_hdl->len;
- DBG("using %dK of OCMEM at 0x%08x", adreno_gpu->gmem / 1024,
- a3xx_gpu->ocmem_base);
-#endif
+ ret = adreno_gpu_ocmem_init(&adreno_gpu->base.pdev->dev,
+ adreno_gpu, &a3xx_gpu->ocmem);
+ if (ret)
+ goto fail;
}
if (!gpu->aspace) {
@@ -530,11 +516,14 @@ struct msm_gpu *a3xx_gpu_init(struct drm_device *dev)
*/
DRM_DEV_ERROR(dev->dev, "No memory protection without IOMMU\n");
ret = -ENXIO;
- goto fail;
+ goto fail_cleanup_ocmem;
}
return gpu;
+fail_cleanup_ocmem:
+ adreno_gpu_ocmem_cleanup(&a3xx_gpu->ocmem);
+
fail:
if (a3xx_gpu)
a3xx_destroy(&a3xx_gpu->base.base);
diff --git a/drivers/gpu/drm/msm/adreno/a3xx_gpu.h
b/drivers/gpu/drm/msm/adreno/a3xx_gpu.h
index ab60dc9e344e..727c34f38f9e 100644
--- a/drivers/gpu/drm/msm/adreno/a3xx_gpu.h
+++ b/drivers/gpu/drm/msm/adreno/a3xx_gpu.h
@@ -30,8 +30,7 @@ struct a3xx_gpu {
struct adreno_gpu base;
/* if OCMEM is used for GMEM: */
- uint32_t ocmem_base;
- void *ocmem_hdl;
+ struct adreno_ocmem ocmem;
};
#define to_a3xx_gpu(x) container_of(x, struct a3xx_gpu, base)
diff --git a/drivers/gpu/drm/msm/adreno/a4xx_gpu.c
b/drivers/gpu/drm/msm/adreno/a4xx_gpu.c
index ab2b752566d8..b8f825107796 100644
--- a/drivers/gpu/drm/msm/adreno/a4xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a4xx_gpu.c
@@ -2,9 +2,6 @@
/* Copyright (c) 2014 The Linux Foundation. All rights reserved.
*/
#include "a4xx_gpu.h"
-#ifdef CONFIG_MSM_OCMEM
-# include
-#endif
#define A4XX_INT0_MASK \
(A4XX_INT0_RBBM_AHB_ERROR |\
@@ -188,7 +185,7 @@ static int a4xx_hw_init(struct msm_gpu *gpu)
(1 << 30) | 0x);
gpu_write(gpu, REG_A4XX_RB_GMEM_BASE_ADDR,
- (unsigned int)(a4xx_gpu->ocmem_base >> 14));
+ (unsigned int)(a4xx_gpu->ocmem.base >> 14));
/* Turn on performance counters: */
gpu_write(gpu, REG_A4XX_RBBM_PERFCTR_CTL, 0x01);
@@ -318,10 +315,7 @@ static void a4xx_destroy(struct msm_gpu *gpu)
[PATCH 4/6] firmware: qcom: scm: add OCMEM lock/unlock interface
From: Rob Clark
Add support for the OCMEM lock/unlock interface that is needed by the
On Chip MEMory (OCMEM) that is present on some Snapdragon devices.
Signed-off-by: Rob Clark
[masn...@onstation.org: ported to latest kernel; minor reformatting.]
Signed-off-by: Brian Masney
---
Rob's last version of this patch:
https://patchwork.kernel.org/patch/7340711/
drivers/firmware/qcom_scm-32.c | 35 +
drivers/firmware/qcom_scm-64.c | 12 ++
drivers/firmware/qcom_scm.c| 40 ++
drivers/firmware/qcom_scm.h| 9
include/linux/qcom_scm.h | 15 +
5 files changed, 111 insertions(+)
diff --git a/drivers/firmware/qcom_scm-32.c b/drivers/firmware/qcom_scm-32.c
index 089b47124933..0100c82b9c00 100644
--- a/drivers/firmware/qcom_scm-32.c
+++ b/drivers/firmware/qcom_scm-32.c
@@ -463,6 +463,41 @@ int __qcom_scm_restore_sec_config(struct device *dev, u32
sec_id,
return 0;
}
+int __qcom_scm_ocmem_lock(struct device *dev, u32 id, u32 offset, u32 size,
+ u32 mode)
+{
+ struct ocmem_tz_lock {
+ __le32 id;
+ __le32 offset;
+ __le32 size;
+ __le32 mode;
+ } request;
+
+ request.id = cpu_to_le32(id);
+ request.offset = cpu_to_le32(offset);
+ request.size = cpu_to_le32(size);
+ request.mode = cpu_to_le32(mode);
+
+ return qcom_scm_call(dev, QCOM_SCM_OCMEM_SVC, QCOM_SCM_OCMEM_LOCK_CMD,
+&request, sizeof(request), NULL, 0);
+}
+
+int __qcom_scm_ocmem_unlock(struct device *dev, u32 id, u32 offset, u32 size)
+{
+ struct ocmem_tz_unlock {
+ __le32 id;
+ __le32 offset;
+ __le32 size;
+ } request;
+
+ request.id = cpu_to_le32(id);
+ request.offset = cpu_to_le32(offset);
+ request.size = cpu_to_le32(size);
+
+ return qcom_scm_call(dev, QCOM_SCM_OCMEM_SVC, QCOM_SCM_OCMEM_UNLOCK_CMD,
+&request, sizeof(request), NULL, 0);
+}
+
void __qcom_scm_init(void)
{
}
diff --git a/drivers/firmware/qcom_scm-64.c b/drivers/firmware/qcom_scm-64.c
index b6b78da7f9c9..2674d6d3cdde 100644
--- a/drivers/firmware/qcom_scm-64.c
+++ b/drivers/firmware/qcom_scm-64.c
@@ -247,6 +247,18 @@ int __qcom_scm_restore_sec_config(struct device *dev, u32
sec_id,
return -ENOTSUPP;
}
+int __qcom_scm_ocmem_lock(struct device *dev, uint32_t id, uint32_t offset,
+ uint32_t size, uint32_t mode)
+{
+ return -ENOTSUPP;
+}
+
+int __qcom_scm_ocmem_unlock(struct device *dev, uint32_t id, uint32_t offset,
+ uint32_t size)
+{
+ return -ENOTSUPP;
+}
+
void __qcom_scm_init(void)
{
u64 cmd;
diff --git a/drivers/firmware/qcom_scm.c b/drivers/firmware/qcom_scm.c
index 5495ef994c5d..85afb54defd4 100644
--- a/drivers/firmware/qcom_scm.c
+++ b/drivers/firmware/qcom_scm.c
@@ -193,6 +193,46 @@ int qcom_scm_restore_sec_config(struct device *dev,
}
EXPORT_SYMBOL(qcom_scm_restore_sec_config);
+/**
+ * qcom_scm_ocmem_lock_available() - is OCMEM lock/unlock interface available
+ */
+bool qcom_scm_ocmem_lock_available(void)
+{
+ return __qcom_scm_is_call_available(__scm->dev, QCOM_SCM_OCMEM_SVC,
+ QCOM_SCM_OCMEM_LOCK_CMD);
+}
+EXPORT_SYMBOL(qcom_scm_ocmem_lock_available);
+
+/**
+ * qcom_scm_ocmem_lock() - call OCMEM lock interface to assign an OCMEM
+ * region to the specified initiator
+ *
+ * @id: tz initiator id
+ * @offset: OCMEM offset
+ * @size: OCMEM size
+ * @mode: access mode (WIDE/NARROW)
+ */
+int qcom_scm_ocmem_lock(enum qcom_scm_ocmem_client id, u32 offset, u32 size,
+ u32 mode)
+{
+ return __qcom_scm_ocmem_lock(__scm->dev, id, offset, size, mode);
+}
+EXPORT_SYMBOL(qcom_scm_ocmem_lock);
+
+/**
+ * qcom_scm_ocmem_unlock() - call OCMEM unlock interface to release an OCMEM
+ * region from the specified initiator
+ *
+ * @id: tz initiator id
+ * @offset: OCMEM offset
+ * @size: OCMEM size
+ */
+int qcom_scm_ocmem_unlock(enum qcom_scm_ocmem_client id, u32 offset, u32 size)
+{
+ return __qcom_scm_ocmem_unlock(__scm->dev, id, offset, size);
+}
+EXPORT_SYMBOL(qcom_scm_ocmem_unlock);
+
/**
* qcom_scm_pas_supported() - Check if the peripheral authentication service is
* available for the given peripherial
diff --git a/drivers/firmware/qcom_scm.h b/drivers/firmware/qcom_scm.h
index bccc7d10c5c2..387e3c4e33c5 100644
--- a/drivers/firmware/qcom_scm.h
+++ b/drivers/firmware/qcom_scm.h
@@ -48,6 +48,15 @@ extern void __qcom_scm_init(void);
extern int __qcom_scm_restore_sec_config(struct device *dev, u32 sec_id,
u32 ctx_bank_num);
+#define QCOM_SCM_OCMEM_SVC 0xf
+#define QCOM_SCM_OCMEM_LOCK_CMD0x1
+#define QCO
[PATCH 5/6] soc: qcom: add OCMEM driver
From: Rob Clark
The OCMEM driver handles allocation and configuration of the On Chip
MEMory that is present on some Snapdragon SoCs.
Devices which have OCMEM do not have GMEM inside the GPU core, so the
GPU must instead use OCMEM to be functional. Since currently the GPU
is the only OCMEM user with an upstream driver, this is just a minimal
implementation sufficient for statically allocating to the GPU it's
chunk of OCMEM.
Signed-off-by: Rob Clark
Co-developed-by: Brian Masney
Signed-off-by: Brian Masney
---
Changes since Rob's last version of this patch:
https://patchwork.kernel.org/patch/7379801/
- reformatted driver to allow multiple instances
- updated logging of error paths during device probing
- remove unused psgsc_ctrl
- remove _clk from clock names
- propagate error code from devm_ioremap_resource()
- use device_get_match_data()
- SPDX license tags
- remove QCOM_SMD in Kconfig
- select ARCH_QCOM in Kconfig
- select QCOM_SCM in Kconfig
- longer description in Kconfig
drivers/soc/qcom/Kconfig | 10 +
drivers/soc/qcom/Makefile| 1 +
drivers/soc/qcom/ocmem.c | 402 +++
drivers/soc/qcom/ocmem.xml.h | 86
include/soc/qcom/ocmem.h | 34 +++
5 files changed, 533 insertions(+)
create mode 100644 drivers/soc/qcom/ocmem.c
create mode 100644 drivers/soc/qcom/ocmem.xml.h
create mode 100644 include/soc/qcom/ocmem.h
diff --git a/drivers/soc/qcom/Kconfig b/drivers/soc/qcom/Kconfig
index 880cf0290962..998d94d60a3c 100644
--- a/drivers/soc/qcom/Kconfig
+++ b/drivers/soc/qcom/Kconfig
@@ -62,6 +62,16 @@ config QCOM_MDT_LOADER
tristate
select QCOM_SCM
+config QCOM_OCMEM
+ tristate "Qualcomm On Chip Memory (OCMEM) driver"
+ depends on ARCH_QCOM
+ select QCOM_SCM
+ help
+ The On Chip Memory (OCMEM) allocator allows various clients to
+ allocate memory from OCMEM based on performance, latency and power
+ requirements. This is typically used by the GPU, camera/video, and
+ audio components on some Snapdragon SoCs.
+
config QCOM_PM
bool "Qualcomm Power Management"
depends on ARCH_QCOM && !ARM64
diff --git a/drivers/soc/qcom/Makefile b/drivers/soc/qcom/Makefile
index ffe519b0cb66..76ac469f548c 100644
--- a/drivers/soc/qcom/Makefile
+++ b/drivers/soc/qcom/Makefile
@@ -5,6 +5,7 @@ obj-$(CONFIG_QCOM_COMMAND_DB) += cmd-db.o
obj-$(CONFIG_QCOM_GLINK_SSR) +=glink_ssr.o
obj-$(CONFIG_QCOM_GSBI)+= qcom_gsbi.o
obj-$(CONFIG_QCOM_MDT_LOADER) += mdt_loader.o
+obj-$(CONFIG_QCOM_OCMEM) += ocmem.o
obj-$(CONFIG_QCOM_PM) += spm.o
obj-$(CONFIG_QCOM_QMI_HELPERS) += qmi_helpers.o
qmi_helpers-y += qmi_encdec.o qmi_interface.o
diff --git a/drivers/soc/qcom/ocmem.c b/drivers/soc/qcom/ocmem.c
new file mode 100644
index ..5ebf5031b6c5
--- /dev/null
+++ b/drivers/soc/qcom/ocmem.c
@@ -0,0 +1,402 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (C) 2019 Brian Masney
+ * Copyright (C) 2015 Red Hat. Author: Rob Clark
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include "ocmem.xml.h"
+
+enum region_mode {
+ WIDE_MODE = 0x0,
+ THIN_MODE,
+ MODE_DEFAULT = WIDE_MODE,
+};
+
+struct ocmem_region {
+ bool interleaved;
+ enum region_mode mode;
+ unsigned int num_macros;
+ enum ocmem_macro_state macro_state[4];
+ unsigned long macro_size;
+ unsigned long region_size;
+};
+
+struct ocmem_config {
+ uint8_t num_regions;
+ uint32_t macro_size;
+};
+
+struct ocmem {
+ struct device *dev;
+ const struct ocmem_config *config;
+ struct resource *ocmem_mem;
+ struct clk *core_clk;
+ struct clk *iface_clk;
+ void __iomem *mmio;
+ unsigned int num_ports;
+ unsigned int num_macros;
+ bool interleaved;
+ struct ocmem_region *regions;
+};
+
+#define FIELD(val, name) (((val) & name ## __MASK) >> name ## __SHIFT)
+
+static inline void ocmem_write(struct ocmem *ocmem, u32 reg, u32 data)
+{
+ writel(data, ocmem->mmio + reg);
+}
+
+static inline u32 ocmem_read(struct ocmem *ocmem, u32 reg)
+{
+ return readl(ocmem->mmio + reg);
+}
+
+static int ocmem_clk_enable(struct ocmem *ocmem)
+{
+ int ret;
+
+ ret = clk_prepare_enable(ocmem->core_clk);
+ if (ret) {
+ dev_info(ocmem->dev, "Fail to enable core clk\n");
+ return ret;
+ }
+
+ ret = clk_prepare_enable(ocmem->iface_clk);
+ if (ret) {
+ dev_info(ocmem->dev, "Fail to enable iface clk\n");
+ return ret;
+ }
+
+ return 0;
+}
+
+static void ocmem_clk_disable(struct ocmem *ocmem)
+{
+ clk_disable_unprepare(ocmem->iface_clk);
+ clk_disable_unprepare(ocmem->cor
[PATCH 2/6] dt-bindings: display: msm: gmu: add optional ocmem property
Some A3xx and A4xx Adreno GPUs do not have GMEM inside the GPU core and
must use the On Chip MEMory (OCMEM) in order to be functional. Add the
optional ocmem property to the Adreno Graphics Management Unit bindings.
Signed-off-by: Brian Masney
---
Documentation/devicetree/bindings/display/msm/gmu.txt | 4
1 file changed, 4 insertions(+)
diff --git a/Documentation/devicetree/bindings/display/msm/gmu.txt
b/Documentation/devicetree/bindings/display/msm/gmu.txt
index 90af5b0a56a9..c746b95e95d4 100644
--- a/Documentation/devicetree/bindings/display/msm/gmu.txt
+++ b/Documentation/devicetree/bindings/display/msm/gmu.txt
@@ -31,6 +31,10 @@ Required properties:
- iommus: phandle to the adreno iommu
- operating-points-v2: phandle to the OPP operating points
+Optional properties:
+- ocmem: phandle to the On Chip Memory (OCMEM) that's present on some
Snapdragon
+ SoCs. See Documentation/devicetree/bindings/soc/qcom/qcom,ocmem.yaml.
+
Example:
/ {
--
2.20.1
[PATCH 3/6] firmware: qcom: scm: add support to restore secure config
From: Rob Clark
Add support to restore the secure configuration that is needed by the
On Chip MEMory (OCMEM) that is present on some Snapdragon devices.
Signed-off-by: Rob Clark
[masn...@onstation.org: ported to latest kernel; minor reformatting.]
Signed-off-by: Brian Masney
---
Rob's last version of this patch:
https://patchwork.kernel.org/patch/7340701/
drivers/firmware/qcom_scm-32.c | 21 +
drivers/firmware/qcom_scm-64.c | 6 ++
drivers/firmware/qcom_scm.c| 23 +++
drivers/firmware/qcom_scm.h| 6 ++
include/linux/qcom_scm.h | 13 +
5 files changed, 69 insertions(+)
diff --git a/drivers/firmware/qcom_scm-32.c b/drivers/firmware/qcom_scm-32.c
index 215061c581e1..089b47124933 100644
--- a/drivers/firmware/qcom_scm-32.c
+++ b/drivers/firmware/qcom_scm-32.c
@@ -442,6 +442,27 @@ int __qcom_scm_hdcp_req(struct device *dev, struct
qcom_scm_hdcp_req *req,
req, req_cnt * sizeof(*req), resp, sizeof(*resp));
}
+int __qcom_scm_restore_sec_config(struct device *dev, u32 sec_id,
+ u32 ctx_bank_num)
+{
+ struct msm_scm_sec_cfg {
+ __le32 id;
+ __le32 ctx_bank_num;
+ } cfg;
+ int ret, scm_ret = 0;
+
+ cfg.id = cpu_to_le32(sec_id);
+ cfg.ctx_bank_num = cpu_to_le32(sec_id);
+
+ ret = qcom_scm_call(dev, QCOM_SCM_MP_SVC, QCOM_SCM_MP_RESTORE_SEC_CFG,
+ &cfg, sizeof(cfg), &scm_ret, sizeof(scm_ret));
+
+ if (ret || scm_ret)
+ return ret ? ret : -EINVAL;
+
+ return 0;
+}
+
void __qcom_scm_init(void)
{
}
diff --git a/drivers/firmware/qcom_scm-64.c b/drivers/firmware/qcom_scm-64.c
index 91d5ad7cf58b..b6b78da7f9c9 100644
--- a/drivers/firmware/qcom_scm-64.c
+++ b/drivers/firmware/qcom_scm-64.c
@@ -241,6 +241,12 @@ int __qcom_scm_hdcp_req(struct device *dev, struct
qcom_scm_hdcp_req *req,
return ret;
}
+int __qcom_scm_restore_sec_config(struct device *dev, u32 sec_id,
+ u32 ctx_bank_num)
+{
+ return -ENOTSUPP;
+}
+
void __qcom_scm_init(void)
{
u64 cmd;
diff --git a/drivers/firmware/qcom_scm.c b/drivers/firmware/qcom_scm.c
index 2ddc118dba1b..5495ef994c5d 100644
--- a/drivers/firmware/qcom_scm.c
+++ b/drivers/firmware/qcom_scm.c
@@ -170,6 +170,29 @@ int qcom_scm_hdcp_req(struct qcom_scm_hdcp_req *req, u32
req_cnt, u32 *resp)
}
EXPORT_SYMBOL(qcom_scm_hdcp_req);
+/**
+ * qcom_scm_restore_sec_config_available() - Check if secure environment
+ * supports restore security config interface.
+ *
+ * Return true if restore-cfg interface is supported, false if not.
+ */
+bool qcom_scm_restore_sec_config_available(void)
+{
+ return __qcom_scm_is_call_available(__scm->dev, QCOM_SCM_MP_SVC,
+ QCOM_SCM_MP_RESTORE_SEC_CFG);
+}
+EXPORT_SYMBOL(qcom_scm_restore_sec_config_available);
+
+/**
+ * qcom_scm_restore_sec_config() - call restore-cfg interface
+ */
+int qcom_scm_restore_sec_config(struct device *dev,
+ enum qcom_scm_sec_dev_id sec_id)
+{
+ return __qcom_scm_restore_sec_config(dev, sec_id, 0);
+}
+EXPORT_SYMBOL(qcom_scm_restore_sec_config);
+
/**
* qcom_scm_pas_supported() - Check if the peripheral authentication service is
* available for the given peripherial
diff --git a/drivers/firmware/qcom_scm.h b/drivers/firmware/qcom_scm.h
index 99506bd873c0..bccc7d10c5c2 100644
--- a/drivers/firmware/qcom_scm.h
+++ b/drivers/firmware/qcom_scm.h
@@ -42,6 +42,12 @@ extern int __qcom_scm_hdcp_req(struct device *dev,
extern void __qcom_scm_init(void);
+#define QCOM_SCM_MP_SVC0xc
+#define QCOM_SCM_MP_RESTORE_SEC_CFG0x2
+
+extern int __qcom_scm_restore_sec_config(struct device *dev, u32 sec_id,
+u32 ctx_bank_num);
+
#define QCOM_SCM_SVC_PIL 0x2
#define QCOM_SCM_PAS_INIT_IMAGE_CMD0x1
#define QCOM_SCM_PAS_MEM_SETUP_CMD 0x2
diff --git a/include/linux/qcom_scm.h b/include/linux/qcom_scm.h
index 3f12cc77fb58..b5c0afaca955 100644
--- a/include/linux/qcom_scm.h
+++ b/include/linux/qcom_scm.h
@@ -24,6 +24,16 @@ struct qcom_scm_vmperm {
int perm;
};
+enum qcom_scm_sec_dev_id {
+ QCOM_SCM_MDSS_DEV_ID= 1,
+ QCOM_SCM_OCMEM_DEV_ID = 5,
+ QCOM_SCM_PCIE0_DEV_ID = 11,
+ QCOM_SCM_PCIE1_DEV_ID = 12,
+ QCOM_SCM_GFX_DEV_ID = 18,
+ QCOM_SCM_UFS_DEV_ID = 19,
+ QCOM_SCM_ICE_DEV_ID = 20,
+};
+
#define QCOM_SCM_VMID_HLOS 0x3
#define QCOM_SCM_VMID_MSS_MSA0xF
#define QCOM_SCM_VMID_WLAN 0x18
@@ -41,6 +51,9 @@ extern bool qcom_scm_is_available(void);
extern bool qcom_scm_hdcp_available(void);
extern int qcom_scm_hdcp_req(struct qcom_scm_hdcp_req *req, u32 req_cnt,
u32 *resp);
+extern bool qcom_scm_restore_sec_confi
[PATCH 1/6] dt-bindings: soc: qcom: add On Chip MEMory (OCMEM) bindings
Add device tree bindings for the On Chip Memory (OCMEM) that is present
on some Qualcomm Snapdragon SoCs.
Signed-off-by: Brian Masney
---
.../bindings/soc/qcom/qcom,ocmem.yaml | 66 +++
1 file changed, 66 insertions(+)
create mode 100644 Documentation/devicetree/bindings/soc/qcom/qcom,ocmem.yaml
diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,ocmem.yaml
b/Documentation/devicetree/bindings/soc/qcom/qcom,ocmem.yaml
new file mode 100644
index ..5e3ae6311a16
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/qcom/qcom,ocmem.yaml
@@ -0,0 +1,66 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/soc/qcom/qcom,ocmem.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: On Chip Memory (OCMEM) that is present on some Qualcomm Snapdragon SoCs.
+
+maintainers:
+ - Brian Masney
+
+description: |
+ The On Chip Memory (OCMEM) allocator allows various clients to allocate
memory
+ from OCMEM based on performance, latency and power requirements. This is
+ typically used by the GPU, camera/video, and audio components on some
+ Snapdragon SoCs.
+
+properties:
+ compatible:
+const: qcom,ocmem-msm8974
+
+ reg:
+items:
+ - description: Control registers
+ - description: OCMEM address range
+
+ reg-names:
+items:
+ - const: ocmem_ctrl_physical
+ - const: ocmem_physical
+
+ clocks:
+items:
+ - description: Core clock
+ - description: Interface clock
+
+ clock-names:
+items:
+ - const: core
+ - const: iface
+
+required:
+ - compatible
+ - reg
+ - reg-names
+ - clocks
+ - clock-names
+
+examples:
+ - |
+ #include
+ #include
+
+ ocmem: ocmem@fdd0 {
+compatible = "qcom,ocmem-msm8974";
+
+reg = <0xfdd0 0x2000>,
+ <0xfec0 0x18>;
+reg-names = "ocmem_ctrl_physical",
+"ocmem_physical";
+
+clocks = <&rpmcc RPM_SMD_OCMEMGX_CLK>,
+ <&mmcc OCMEMCX_OCMEMNOC_CLK>;
+clock-names = "core",
+ "iface";
+ };
--
2.20.1
[PATCH 0/6] qcom: add OCMEM support
This patch series adds support for Qualcomm's On Chip MEMory (OCMEM) that is needed in order to support some A3xx and A4xx based GPUs upstream. This is based on Rob Clark's patch series that he submitted in October 2015 and I am resubmitting updated patches with his permission. This was tested with the GPU on a LG Nexus 5 (hammerhead) phone and this will work on other msm8974-based systems. For a summary of what currently works upstream on the Nexus 5, see my status page at https://masneyb.github.io/nexus-5-upstream/. Brian Masney (3): dt-bindings: soc: qcom: add On Chip MEMory (OCMEM) bindings dt-bindings: display: msm: gmu: add optional ocmem property drm/msm/gpu: add ocmem init/cleanup functions Rob Clark (3): firmware: qcom: scm: add support to restore secure config firmware: qcom: scm: add OCMEM lock/unlock interface soc: qcom: add OCMEM driver .../devicetree/bindings/display/msm/gmu.txt | 4 + .../bindings/soc/qcom/qcom,ocmem.yaml | 66 +++ drivers/firmware/qcom_scm-32.c| 56 +++ drivers/firmware/qcom_scm-64.c| 18 + drivers/firmware/qcom_scm.c | 63 +++ drivers/firmware/qcom_scm.h | 15 + drivers/gpu/drm/msm/adreno/a3xx_gpu.c | 33 +- drivers/gpu/drm/msm/adreno/a3xx_gpu.h | 3 +- drivers/gpu/drm/msm/adreno/a4xx_gpu.c | 30 +- drivers/gpu/drm/msm/adreno/a4xx_gpu.h | 3 +- drivers/gpu/drm/msm/adreno/adreno_gpu.c | 41 ++ drivers/gpu/drm/msm/adreno/adreno_gpu.h | 10 + drivers/soc/qcom/Kconfig | 10 + drivers/soc/qcom/Makefile | 1 + drivers/soc/qcom/ocmem.c | 402 ++ drivers/soc/qcom/ocmem.xml.h | 86 include/linux/qcom_scm.h | 28 ++ include/soc/qcom/ocmem.h | 34 ++ 18 files changed, 857 insertions(+), 46 deletions(-) create mode 100644 Documentation/devicetree/bindings/soc/qcom/qcom,ocmem.yaml create mode 100644 drivers/soc/qcom/ocmem.c create mode 100644 drivers/soc/qcom/ocmem.xml.h create mode 100644 include/soc/qcom/ocmem.h -- 2.20.1
Re: [PATCH 6/6] drm/msm/gpu: add ocmem init/cleanup functions
Hi Bjorn,
On Sun, Jun 16, 2019 at 11:06:33AM -0700, Bjorn Andersson wrote:
> > diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> > b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> > index 6f7f4114afcf..e0a9409c8a32 100644
> > --- a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> > +++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> > @@ -29,6 +29,10 @@
> > #include "msm_gem.h"
> > #include "msm_mmu.h"
> >
> > +#ifdef CONFIG_QCOM_OCMEM
> > +# include
> > +#endif
>
> This file exists (after the previous patch), so no need to make its
> inclusion conditional.
>
> > +
> > static bool zap_available = true;
> >
> > static int zap_shader_load_mdt(struct msm_gpu *gpu, const char *fwname,
> > @@ -897,6 +901,43 @@ static int adreno_get_pwrlevels(struct device *dev,
> > return 0;
> > }
> >
> > +int adreno_gpu_ocmem_init(struct device *dev, struct adreno_gpu
> > *adreno_gpu,
> > + struct adreno_ocmem *adreno_ocmem)
> > +{
> > +#ifdef CONFIG_QCOM_OCMEM
>
> No need to make this conditional.
I have these #ifdefs for the a5xx and a6xx GPUs that don't have ocmem
in the SoC. Without the #ifdefs, those systems would need to have the
ocmem driver in their kernel.
Thanks for the quick review on the patch set!
Brian
Re: [PATCH 5/6] soc: qcom: add OCMEM driver
Hi Rob Clark, On Sun, Jun 16, 2019 at 10:41:06AM -0700, Bjorn Andersson wrote: > > diff --git a/drivers/soc/qcom/ocmem.xml.h b/drivers/soc/qcom/ocmem.xml.h > > I would prefer that these lived at the top of the c file, rather than > being generated. I think it would be nice to make this change as well. Rob C: Your original file ocmem.xml.h was licensed under the MIT license. I just wanted confirmation from you that it's OK to put the contents of that file into ocmem.c which has the GPL 2.0 only SPDX license tag. This will relicense the work. I imagine it's not an issue but I just wanted to get confirmation so there is no ambiguity regarding the licensing in the future. Brian > > > new file mode 100644 > > index ..b4bfb85d1e33 > > --- /dev/null > > +++ b/drivers/soc/qcom/ocmem.xml.h > > @@ -0,0 +1,86 @@ > > +/* SPDX-License-Identifier: MIT */ > > + > > +#ifndef OCMEM_XML > > +#define OCMEM_XML > > + > > +/* Autogenerated file, DO NOT EDIT manually! > > + > > +This file was generated by the rules-ng-ng headergen tool in this git > > repository: > > +http://github.com/freedreno/envytools/ > > +git clone https://github.com/freedreno/envytools.git > > + > > +The rules-ng-ng source files this header was generated from are: > > +- /home/robclark/src/freedreno/envytools/rnndb/adreno/ocmem.xml ( > > 1773 bytes, from 2015-09-24 17:30:00) > > + > > +Copyright (C) 2013-2015 by the following authors: > > +- Rob Clark (robclark) > > +*/
[PATCH v2 6/6] drm/msm/gpu: add ocmem init/cleanup functions
The files a3xx_gpu.c and a4xx_gpu.c have ifdefs for the OCMEM support
that was missing upstream. Add two new functions (adreno_gpu_ocmem_init
and adreno_gpu_ocmem_cleanup) that removes some duplicated code. We also
need to change the ifdef check for CONFIG_MSM_OCMEM to CONFIG_QCOM_OCMEM
now that OCMEM support is upstream.
Signed-off-by: Brian Masney
---
Changes since v1:
- remove CONFIG_QCOM_OCMEM #ifdefs
- use unsigned long for memory addresses instead of uint32_t
- add 'depends on QCOM_OCMEM || QCOM_OCMEM=n' to Kconfig
drivers/gpu/drm/msm/Kconfig | 1 +
drivers/gpu/drm/msm/adreno/a3xx_gpu.c | 33 ---
drivers/gpu/drm/msm/adreno/a3xx_gpu.h | 3 +--
drivers/gpu/drm/msm/adreno/a4xx_gpu.c | 30 +++--
drivers/gpu/drm/msm/adreno/a4xx_gpu.h | 3 +--
drivers/gpu/drm/msm/adreno/adreno_gpu.c | 36 +
drivers/gpu/drm/msm/adreno/adreno_gpu.h | 10 +++
7 files changed, 70 insertions(+), 46 deletions(-)
diff --git a/drivers/gpu/drm/msm/Kconfig b/drivers/gpu/drm/msm/Kconfig
index 9c37e4de5896..b3d3b2172659 100644
--- a/drivers/gpu/drm/msm/Kconfig
+++ b/drivers/gpu/drm/msm/Kconfig
@@ -7,6 +7,7 @@ config DRM_MSM
depends on OF && COMMON_CLK
depends on MMU
depends on INTERCONNECT || !INTERCONNECT
+ depends on QCOM_OCMEM || QCOM_OCMEM=n
select QCOM_MDT_LOADER if ARCH_QCOM
select REGULATOR
select DRM_KMS_HELPER
diff --git a/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
b/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
index c3b4bc6e4155..72720bb2aca1 100644
--- a/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
@@ -17,10 +17,6 @@
* this program. If not, see <http://www.gnu.org/licenses/>.
*/
-#ifdef CONFIG_MSM_OCMEM
-# include
-#endif
-
#include "a3xx_gpu.h"
#define A3XX_INT0_MASK \
@@ -206,9 +202,9 @@ static int a3xx_hw_init(struct msm_gpu *gpu)
gpu_write(gpu, REG_A3XX_RBBM_GPR0_CTL, 0x);
/* Set the OCMEM base address for A330, etc */
- if (a3xx_gpu->ocmem_hdl) {
+ if (a3xx_gpu->ocmem.hdl) {
gpu_write(gpu, REG_A3XX_RB_GMEM_BASE_ADDR,
- (unsigned int)(a3xx_gpu->ocmem_base >> 14));
+ (unsigned int)(a3xx_gpu->ocmem.base >> 14));
}
/* Turn on performance counters: */
@@ -329,10 +325,7 @@ static void a3xx_destroy(struct msm_gpu *gpu)
adreno_gpu_cleanup(adreno_gpu);
-#ifdef CONFIG_MSM_OCMEM
- if (a3xx_gpu->ocmem_base)
- ocmem_free(OCMEM_GRAPHICS, a3xx_gpu->ocmem_hdl);
-#endif
+ adreno_gpu_ocmem_cleanup(&a3xx_gpu->ocmem);
kfree(a3xx_gpu);
}
@@ -507,17 +500,10 @@ struct msm_gpu *a3xx_gpu_init(struct drm_device *dev)
/* if needed, allocate gmem: */
if (adreno_is_a330(adreno_gpu)) {
-#ifdef CONFIG_MSM_OCMEM
- /* TODO this is different/missing upstream: */
- struct ocmem_buf *ocmem_hdl =
- ocmem_allocate(OCMEM_GRAPHICS,
adreno_gpu->gmem);
-
- a3xx_gpu->ocmem_hdl = ocmem_hdl;
- a3xx_gpu->ocmem_base = ocmem_hdl->addr;
- adreno_gpu->gmem = ocmem_hdl->len;
- DBG("using %dK of OCMEM at 0x%08x", adreno_gpu->gmem / 1024,
- a3xx_gpu->ocmem_base);
-#endif
+ ret = adreno_gpu_ocmem_init(&adreno_gpu->base.pdev->dev,
+ adreno_gpu, &a3xx_gpu->ocmem);
+ if (ret)
+ goto fail;
}
if (!gpu->aspace) {
@@ -530,11 +516,14 @@ struct msm_gpu *a3xx_gpu_init(struct drm_device *dev)
*/
DRM_DEV_ERROR(dev->dev, "No memory protection without IOMMU\n");
ret = -ENXIO;
- goto fail;
+ goto fail_cleanup_ocmem;
}
return gpu;
+fail_cleanup_ocmem:
+ adreno_gpu_ocmem_cleanup(&a3xx_gpu->ocmem);
+
fail:
if (a3xx_gpu)
a3xx_destroy(&a3xx_gpu->base.base);
diff --git a/drivers/gpu/drm/msm/adreno/a3xx_gpu.h
b/drivers/gpu/drm/msm/adreno/a3xx_gpu.h
index ab60dc9e344e..727c34f38f9e 100644
--- a/drivers/gpu/drm/msm/adreno/a3xx_gpu.h
+++ b/drivers/gpu/drm/msm/adreno/a3xx_gpu.h
@@ -30,8 +30,7 @@ struct a3xx_gpu {
struct adreno_gpu base;
/* if OCMEM is used for GMEM: */
- uint32_t ocmem_base;
- void *ocmem_hdl;
+ struct adreno_ocmem ocmem;
};
#define to_a3xx_gpu(x) container_of(x, struct a3xx_gpu, base)
diff --git a/drivers/gpu/drm/msm/adreno/a4xx_gpu.c
b/drivers/gpu/drm/msm/adreno/a4xx_gpu.c
index ab2b752566d8..b8f825107796 100644
--- a/drivers/gpu/drm/msm/adreno/a4xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a4xx_gpu.c
@@ -2,9 +2,6 @@
/* Copyright
[PATCH v2 5/6] soc: qcom: add OCMEM driver
The OCMEM driver handles allocation and configuration of the On Chip
MEMory that is present on some Snapdragon SoCs.
Devices which have OCMEM do not have GMEM inside the GPU core, so the
GPU must instead use OCMEM to be functional. Since currently the GPU
is the only OCMEM user with an upstream driver, this is just a minimal
implementation sufficient for statically allocating to the GPU it's
chunk of OCMEM.
Signed-off-by: Brian Masney
Co-developed-by: Rob Clark
Signed-off-by: Rob Clark
---
Pay attention to qcom_scm_restore_sec_cfg() in the probe function,
specifically the 0 as the third paramter. I'm honestly not sure what
to put here. In the previous version, this function would set the id
and ctx_bank_num to the device_id. The GPU works either way. I couldn't
find this in the downstream MSM kernel sources.
Changes since v1:
- ocmem_allocate(): check for alignment and minimum allocation size.
The 64K values came from the downstream MSM kernel sources.
- add locking to memory allocations based on the client
- use clk_bulk_*() functions
- rename qcom,ocmem-msm8974 to qcom,msm8974-ocmem
- rename reg-names to ctrl and mem
- remove ocmem.xml.h file; use FIELD_PREP() instead for some nice cleanups
- add static inline noop versions of public-facing functions when ocmem
is disabled to remove #ifdefs in adrenu_gpu.c
- use unsigned long for memory addresses
- move ocmem_dev_remove() below _probe() function
- remove error check from platform_get_resource_byname for ctrl resource
- add MODULE_DESCRIPTION() and MODULE_LICENSE()
- add description to top of ocmem.[ch]
- correct thin mode bit in update_ocmem()
- add 'WARN_ON(client != OCMEM_GRAPHICS)' to device_address()
- make of_get_ocmem return error codes via ERR_PTR instead of NULL
- ocmem_{allocate,free} - WARN_ON() if client != OCMEM_GRAPHICS.
Simplify if statements.
- allow NULL to be passed into ocmem_free
- remove unnecessary initialization of i in update_ocmem()
- add dev_dbg to ocmem_allocate
Changes since Rob's last version of this patch from 2015:
https://patchwork.kernel.org/patch/7379801/
- reformatted driver to allow multiple instances
- updated logging of error paths during device probing
- remove unused psgsc_ctrl
- remove _clk from clock names
- propagate error code from devm_ioremap_resource()
- use device_get_match_data()
- SPDX license tags
- remove QCOM_SMD in Kconfig
- select ARCH_QCOM in Kconfig
- select ARCH_QCOM in Kconfig
- select QCOM_SCM in Kconfig
- longer description in Kconfig
drivers/soc/qcom/Kconfig | 10 +
drivers/soc/qcom/Makefile | 1 +
drivers/soc/qcom/ocmem.c | 433 ++
include/soc/qcom/ocmem.h | 62 ++
4 files changed, 506 insertions(+)
create mode 100644 drivers/soc/qcom/ocmem.c
create mode 100644 include/soc/qcom/ocmem.h
diff --git a/drivers/soc/qcom/Kconfig b/drivers/soc/qcom/Kconfig
index a6d1bfb17279..d18eb83b10da 100644
--- a/drivers/soc/qcom/Kconfig
+++ b/drivers/soc/qcom/Kconfig
@@ -74,6 +74,16 @@ config QCOM_MDT_LOADER
tristate
select QCOM_SCM
+config QCOM_OCMEM
+ tristate "Qualcomm On Chip Memory (OCMEM) driver"
+ depends on ARCH_QCOM
+ select QCOM_SCM
+ help
+ The On Chip Memory (OCMEM) allocator allows various clients to
+ allocate memory from OCMEM based on performance, latency and power
+ requirements. This is typically used by the GPU, camera/video, and
+ audio components on some Snapdragon SoCs.
+
config QCOM_PM
bool "Qualcomm Power Management"
depends on ARCH_QCOM && !ARM64
diff --git a/drivers/soc/qcom/Makefile b/drivers/soc/qcom/Makefile
index eeb088beb15f..dfc378014a33 100644
--- a/drivers/soc/qcom/Makefile
+++ b/drivers/soc/qcom/Makefile
@@ -6,6 +6,7 @@ obj-$(CONFIG_QCOM_COMMAND_DB) += cmd-db.o
obj-$(CONFIG_QCOM_GLINK_SSR) +=glink_ssr.o
obj-$(CONFIG_QCOM_GSBI)+= qcom_gsbi.o
obj-$(CONFIG_QCOM_MDT_LOADER) += mdt_loader.o
+obj-$(CONFIG_QCOM_OCMEM) += ocmem.o
obj-$(CONFIG_QCOM_PM) += spm.o
obj-$(CONFIG_QCOM_QMI_HELPERS) += qmi_helpers.o
qmi_helpers-y += qmi_encdec.o qmi_interface.o
diff --git a/drivers/soc/qcom/ocmem.c b/drivers/soc/qcom/ocmem.c
new file mode 100644
index ..91256e160b9b
--- /dev/null
+++ b/drivers/soc/qcom/ocmem.c
@@ -0,0 +1,433 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * The On Chip Memory (OCMEM) allocator allows various clients to allocate
+ * memory from OCMEM based on performance, latency and power requirements.
+ * This is typically used by the GPU, camera/video, and audio components on
+ * some Snapdragon SoCs.
+ *
+ * Copyright (C) 2019 Brian Masney
+ * Copyright (C) 2015 Red Hat. Author: Rob Clark
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+enum region_mode {
+ WIDE_MODE = 0x0,
+ THIN_MODE,
+
[PATCH v2 4/6] firmware: qcom: scm: add support to restore secure config to qcm_scm-32
From: Rob Clark
Add support to restore the secure configuration for qcm_scm-32.c. This
is needed by the On Chip MEMory (OCMEM) that is present on some
Snapdragon devices.
Signed-off-by: Rob Clark
[masn...@onstation.org: ported to latest kernel; set ctx_bank_num to
spare parameter.]
Signed-off-by: Brian Masney
---
Changes since v1:
- Use existing __qcom_scm_restore_sec_cfg() function stub in
qcom_scm-32.c that was unimplemented
- Set the cfg.ctx_bank_num to the spare function parameter. It was
previously set to the device_id.
drivers/firmware/qcom_scm-32.c | 17 -
drivers/firmware/qcom_scm.c| 13 +
include/linux/qcom_scm.h | 11 +++
3 files changed, 40 insertions(+), 1 deletion(-)
diff --git a/drivers/firmware/qcom_scm-32.c b/drivers/firmware/qcom_scm-32.c
index 4c2514e5e249..5d90b7f5ab5a 100644
--- a/drivers/firmware/qcom_scm-32.c
+++ b/drivers/firmware/qcom_scm-32.c
@@ -617,7 +617,22 @@ int __qcom_scm_assign_mem(struct device *dev, phys_addr_t
mem_region,
int __qcom_scm_restore_sec_cfg(struct device *dev, u32 device_id,
u32 spare)
{
- return -ENODEV;
+ struct msm_scm_sec_cfg {
+ __le32 id;
+ __le32 ctx_bank_num;
+ } cfg;
+ int ret, scm_ret = 0;
+
+ cfg.id = cpu_to_le32(device_id);
+ cfg.ctx_bank_num = cpu_to_le32(spare);
+
+ ret = qcom_scm_call(dev, QCOM_SCM_SVC_MP, QCOM_SCM_RESTORE_SEC_CFG,
+ &cfg, sizeof(cfg), &scm_ret, sizeof(scm_ret));
+
+ if (ret || scm_ret)
+ return ret ? ret : -EINVAL;
+
+ return 0;
}
int __qcom_scm_iommu_secure_ptbl_size(struct device *dev, u32 spare,
diff --git a/drivers/firmware/qcom_scm.c b/drivers/firmware/qcom_scm.c
index 2e12ea56c34c..54532331ddc1 100644
--- a/drivers/firmware/qcom_scm.c
+++ b/drivers/firmware/qcom_scm.c
@@ -366,6 +366,19 @@ static const struct reset_control_ops
qcom_scm_pas_reset_ops = {
.deassert = qcom_scm_pas_reset_deassert,
};
+/**
+ * qcom_scm_restore_sec_cfg_available() - Check if secure environment
+ * supports restore security config interface.
+ *
+ * Return true if restore-cfg interface is supported, false if not.
+ */
+bool qcom_scm_restore_sec_cfg_available(void)
+{
+ return __qcom_scm_is_call_available(__scm->dev, QCOM_SCM_SVC_MP,
+ QCOM_SCM_RESTORE_SEC_CFG);
+}
+EXPORT_SYMBOL(qcom_scm_restore_sec_cfg_available);
+
int qcom_scm_restore_sec_cfg(u32 device_id, u32 spare)
{
return __qcom_scm_restore_sec_cfg(__scm->dev, device_id, spare);
diff --git a/include/linux/qcom_scm.h b/include/linux/qcom_scm.h
index 521b089be1c9..8a24f7eb2588 100644
--- a/include/linux/qcom_scm.h
+++ b/include/linux/qcom_scm.h
@@ -34,6 +34,16 @@ enum qcom_scm_ocmem_client {
QCOM_SCM_OCMEM_DEBUG_ID,
};
+enum qcom_scm_sec_dev_id {
+ QCOM_SCM_MDSS_DEV_ID= 1,
+ QCOM_SCM_OCMEM_DEV_ID = 5,
+ QCOM_SCM_PCIE0_DEV_ID = 11,
+ QCOM_SCM_PCIE1_DEV_ID = 12,
+ QCOM_SCM_GFX_DEV_ID = 18,
+ QCOM_SCM_UFS_DEV_ID = 19,
+ QCOM_SCM_ICE_DEV_ID = 20,
+};
+
#define QCOM_SCM_VMID_HLOS 0x3
#define QCOM_SCM_VMID_MSS_MSA0xF
#define QCOM_SCM_VMID_WLAN 0x18
@@ -69,6 +79,7 @@ extern int qcom_scm_assign_mem(phys_addr_t mem_addr, size_t
mem_sz,
extern void qcom_scm_cpu_power_down(u32 flags);
extern u32 qcom_scm_get_version(void);
extern int qcom_scm_set_remote_state(u32 state, u32 id);
+extern bool qcom_scm_restore_sec_cfg_available(void);
extern int qcom_scm_restore_sec_cfg(u32 device_id, u32 spare);
extern int qcom_scm_iommu_secure_ptbl_size(u32 spare, size_t *size);
extern int qcom_scm_iommu_secure_ptbl_init(u64 addr, u32 size, u32 spare);
--
2.20.1
[PATCH v2 2/6] dt-bindings: display: msm: gmu: add optional ocmem property
Some A3xx and A4xx Adreno GPUs do not have GMEM inside the GPU core and
must use the On Chip MEMory (OCMEM) in order to be functional. Add the
optional ocmem property to the Adreno Graphics Management Unit bindings.
Signed-off-by: Brian Masney
---
Changes since v1:
- None
Documentation/devicetree/bindings/display/msm/gmu.txt | 4
1 file changed, 4 insertions(+)
diff --git a/Documentation/devicetree/bindings/display/msm/gmu.txt
b/Documentation/devicetree/bindings/display/msm/gmu.txt
index 90af5b0a56a9..c746b95e95d4 100644
--- a/Documentation/devicetree/bindings/display/msm/gmu.txt
+++ b/Documentation/devicetree/bindings/display/msm/gmu.txt
@@ -31,6 +31,10 @@ Required properties:
- iommus: phandle to the adreno iommu
- operating-points-v2: phandle to the OPP operating points
+Optional properties:
+- ocmem: phandle to the On Chip Memory (OCMEM) that's present on some
Snapdragon
+ SoCs. See Documentation/devicetree/bindings/soc/qcom/qcom,ocmem.yaml.
+
Example:
/ {
--
2.20.1
[PATCH v2 3/6] firmware: qcom: scm: add OCMEM lock/unlock interface
From: Rob Clark
Add support for the OCMEM lock/unlock interface that is needed by the
On Chip MEMory (OCMEM) that is present on some Snapdragon devices.
Signed-off-by: Rob Clark
[masn...@onstation.org: ported to latest kernel; minor reformatting.]
Signed-off-by: Brian Masney
Reviewed-by: Bjorn Andersson
---
Rob's last version of this patch:
https://patchwork.kernel.org/patch/7340711/
Changes since v1:
- None
drivers/firmware/qcom_scm-32.c | 35 +
drivers/firmware/qcom_scm-64.c | 12 ++
drivers/firmware/qcom_scm.c| 40 ++
drivers/firmware/qcom_scm.h| 9
include/linux/qcom_scm.h | 15 +
5 files changed, 111 insertions(+)
diff --git a/drivers/firmware/qcom_scm-32.c b/drivers/firmware/qcom_scm-32.c
index 215061c581e1..4c2514e5e249 100644
--- a/drivers/firmware/qcom_scm-32.c
+++ b/drivers/firmware/qcom_scm-32.c
@@ -442,6 +442,41 @@ int __qcom_scm_hdcp_req(struct device *dev, struct
qcom_scm_hdcp_req *req,
req, req_cnt * sizeof(*req), resp, sizeof(*resp));
}
+int __qcom_scm_ocmem_lock(struct device *dev, u32 id, u32 offset, u32 size,
+ u32 mode)
+{
+ struct ocmem_tz_lock {
+ __le32 id;
+ __le32 offset;
+ __le32 size;
+ __le32 mode;
+ } request;
+
+ request.id = cpu_to_le32(id);
+ request.offset = cpu_to_le32(offset);
+ request.size = cpu_to_le32(size);
+ request.mode = cpu_to_le32(mode);
+
+ return qcom_scm_call(dev, QCOM_SCM_OCMEM_SVC, QCOM_SCM_OCMEM_LOCK_CMD,
+&request, sizeof(request), NULL, 0);
+}
+
+int __qcom_scm_ocmem_unlock(struct device *dev, u32 id, u32 offset, u32 size)
+{
+ struct ocmem_tz_unlock {
+ __le32 id;
+ __le32 offset;
+ __le32 size;
+ } request;
+
+ request.id = cpu_to_le32(id);
+ request.offset = cpu_to_le32(offset);
+ request.size = cpu_to_le32(size);
+
+ return qcom_scm_call(dev, QCOM_SCM_OCMEM_SVC, QCOM_SCM_OCMEM_UNLOCK_CMD,
+&request, sizeof(request), NULL, 0);
+}
+
void __qcom_scm_init(void)
{
}
diff --git a/drivers/firmware/qcom_scm-64.c b/drivers/firmware/qcom_scm-64.c
index 91d5ad7cf58b..c3a3d9874def 100644
--- a/drivers/firmware/qcom_scm-64.c
+++ b/drivers/firmware/qcom_scm-64.c
@@ -241,6 +241,18 @@ int __qcom_scm_hdcp_req(struct device *dev, struct
qcom_scm_hdcp_req *req,
return ret;
}
+int __qcom_scm_ocmem_lock(struct device *dev, uint32_t id, uint32_t offset,
+ uint32_t size, uint32_t mode)
+{
+ return -ENOTSUPP;
+}
+
+int __qcom_scm_ocmem_unlock(struct device *dev, uint32_t id, uint32_t offset,
+ uint32_t size)
+{
+ return -ENOTSUPP;
+}
+
void __qcom_scm_init(void)
{
u64 cmd;
diff --git a/drivers/firmware/qcom_scm.c b/drivers/firmware/qcom_scm.c
index 2ddc118dba1b..2e12ea56c34c 100644
--- a/drivers/firmware/qcom_scm.c
+++ b/drivers/firmware/qcom_scm.c
@@ -190,6 +190,46 @@ bool qcom_scm_pas_supported(u32 peripheral)
}
EXPORT_SYMBOL(qcom_scm_pas_supported);
+/**
+ * qcom_scm_ocmem_lock_available() - is OCMEM lock/unlock interface available
+ */
+bool qcom_scm_ocmem_lock_available(void)
+{
+ return __qcom_scm_is_call_available(__scm->dev, QCOM_SCM_OCMEM_SVC,
+ QCOM_SCM_OCMEM_LOCK_CMD);
+}
+EXPORT_SYMBOL(qcom_scm_ocmem_lock_available);
+
+/**
+ * qcom_scm_ocmem_lock() - call OCMEM lock interface to assign an OCMEM
+ * region to the specified initiator
+ *
+ * @id: tz initiator id
+ * @offset: OCMEM offset
+ * @size: OCMEM size
+ * @mode: access mode (WIDE/NARROW)
+ */
+int qcom_scm_ocmem_lock(enum qcom_scm_ocmem_client id, u32 offset, u32 size,
+ u32 mode)
+{
+ return __qcom_scm_ocmem_lock(__scm->dev, id, offset, size, mode);
+}
+EXPORT_SYMBOL(qcom_scm_ocmem_lock);
+
+/**
+ * qcom_scm_ocmem_unlock() - call OCMEM unlock interface to release an OCMEM
+ * region from the specified initiator
+ *
+ * @id: tz initiator id
+ * @offset: OCMEM offset
+ * @size: OCMEM size
+ */
+int qcom_scm_ocmem_unlock(enum qcom_scm_ocmem_client id, u32 offset, u32 size)
+{
+ return __qcom_scm_ocmem_unlock(__scm->dev, id, offset, size);
+}
+EXPORT_SYMBOL(qcom_scm_ocmem_unlock);
+
/**
* qcom_scm_pas_init_image() - Initialize peripheral authentication service
*state machine for a given peripheral, using the
diff --git a/drivers/firmware/qcom_scm.h b/drivers/firmware/qcom_scm.h
index 99506bd873c0..ef293ee67ec1 100644
--- a/drivers/firmware/qcom_scm.h
+++ b/drivers/firmware/qcom_scm.h
@@ -42,6 +42,15 @@ extern int __qcom_scm_hdcp_req(struct device *dev,
extern void __qcom_scm_init(void);
+#define QCOM_SCM_OCMEM_SVC 0xf
+#define QCOM_SCM_OCMEM_LOCK_CMD
[PATCH v2 0/6] qcom: add OCMEM support
This patch series adds support for Qualcomm's On Chip MEMory (OCMEM) that is needed in order to support some A3xx and A4xx based GPUs upstream. This is based on Rob Clark's patch series that he submitted in October 2015 and I am resubmitting updated patches with his permission. See the individual patches for the changelog. This was tested with the GPU on a LG Nexus 5 (hammerhead) phone and this will work on other msm8974-based systems. For a summary of what currently works upstream on the Nexus 5, see my status page at https://masneyb.github.io/nexus-5-upstream/. Brian Masney (4): dt-bindings: soc: qcom: add On Chip MEMory (OCMEM) bindings dt-bindings: display: msm: gmu: add optional ocmem property soc: qcom: add OCMEM driver drm/msm/gpu: add ocmem init/cleanup functions Rob Clark (2): firmware: qcom: scm: add OCMEM lock/unlock interface firmware: qcom: scm: add support to restore secure config to qcm_scm-32 .../devicetree/bindings/display/msm/gmu.txt | 4 + .../bindings/sram/qcom/qcom,ocmem.yaml| 64 +++ drivers/firmware/qcom_scm-32.c| 52 ++- drivers/firmware/qcom_scm-64.c| 12 + drivers/firmware/qcom_scm.c | 53 +++ drivers/firmware/qcom_scm.h | 9 + drivers/gpu/drm/msm/Kconfig | 1 + drivers/gpu/drm/msm/adreno/a3xx_gpu.c | 33 +- drivers/gpu/drm/msm/adreno/a3xx_gpu.h | 3 +- drivers/gpu/drm/msm/adreno/a4xx_gpu.c | 30 +- drivers/gpu/drm/msm/adreno/a4xx_gpu.h | 3 +- drivers/gpu/drm/msm/adreno/adreno_gpu.c | 36 ++ drivers/gpu/drm/msm/adreno/adreno_gpu.h | 10 + drivers/soc/qcom/Kconfig | 10 + drivers/soc/qcom/Makefile | 1 + drivers/soc/qcom/ocmem.c | 433 ++ include/linux/qcom_scm.h | 26 ++ include/soc/qcom/ocmem.h | 62 +++ 18 files changed, 795 insertions(+), 47 deletions(-) create mode 100644 Documentation/devicetree/bindings/sram/qcom/qcom,ocmem.yaml create mode 100644 drivers/soc/qcom/ocmem.c create mode 100644 include/soc/qcom/ocmem.h -- 2.20.1
[PATCH v2 1/6] dt-bindings: soc: qcom: add On Chip MEMory (OCMEM) bindings
Add device tree bindings for the On Chip Memory (OCMEM) that is present
on some Qualcomm Snapdragon SoCs.
Signed-off-by: Brian Masney
---
Changes since v1:
- Rename qcom,ocmem-msm8974 to qcom,msm8974-ocmem
- Renamed reg-names to ctrl and mem
- update hardware description
- moved from soc to sram namespace in the device tree bindings
.../bindings/sram/qcom/qcom,ocmem.yaml| 64 +++
1 file changed, 64 insertions(+)
create mode 100644 Documentation/devicetree/bindings/sram/qcom/qcom,ocmem.yaml
diff --git a/Documentation/devicetree/bindings/sram/qcom/qcom,ocmem.yaml
b/Documentation/devicetree/bindings/sram/qcom/qcom,ocmem.yaml
new file mode 100644
index ..1bd15824968e
--- /dev/null
+++ b/Documentation/devicetree/bindings/sram/qcom/qcom,ocmem.yaml
@@ -0,0 +1,64 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sram/qcom/qcom,ocmem.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: On Chip Memory (OCMEM) that is present on some Qualcomm Snapdragon SoCs.
+
+maintainers:
+ - Brian Masney
+
+description: |
+ The On Chip Memory (OCMEM) is typically used by the GPU, camera/video, and
+ audio components on some Snapdragon SoCs.
+
+properties:
+ compatible:
+const: qcom,msm8974-ocmem
+
+ reg:
+items:
+ - description: Control registers
+ - description: OCMEM address range
+
+ reg-names:
+items:
+ - const: ctrl
+ - const: mem
+
+ clocks:
+items:
+ - description: Core clock
+ - description: Interface clock
+
+ clock-names:
+items:
+ - const: core
+ - const: iface
+
+required:
+ - compatible
+ - reg
+ - reg-names
+ - clocks
+ - clock-names
+
+examples:
+ - |
+ #include
+ #include
+
+ ocmem: ocmem@fdd0 {
+compatible = "qcom,msm8974-ocmem";
+
+reg = <0xfdd0 0x2000>,
+ <0xfec0 0x18>;
+reg-names = "ctrl",
+"mem";
+
+clocks = <&rpmcc RPM_SMD_OCMEMGX_CLK>,
+ <&mmcc OCMEMCX_OCMEMNOC_CLK>;
+clock-names = "core",
+ "iface";
+ };
--
2.20.1
Re: [PATCH v2 5/6] soc: qcom: add OCMEM driver
On Tue, Jun 18, 2019 at 10:32:08PM -0400, Brian Masney wrote:
> +++ b/include/soc/qcom/ocmem.h
> @@ -0,0 +1,62 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +/*
> + * The On Chip Memory (OCMEM) allocator allows various clients to allocate
> + * memory from OCMEM based on performance, latency and power requirements.
> + * This is typically used by the GPU, camera/video, and audio components on
> + * some Snapdragon SoCs.
> + *
> + * Copyright (C) 2019 Brian Masney
> + * Copyright (C) 2015 Red Hat. Author: Rob Clark
> + */
> +
> +#ifndef __OCMEM_H__
> +#define __OCMEM_H__
> +
> +enum ocmem_client {
> + /* GMEM clients */
> + OCMEM_GRAPHICS = 0x0,
> + /*
> + * TODO add more once ocmem_allocate() is clever enough to
> + * deal with multiple clients.
> + */
> + OCMEM_CLIENT_MAX,
> +};
> +
> +struct ocmem;
> +
> +struct ocmem_buf {
> + unsigned long offset;
> + unsigned long addr;
> + unsigned long len;
> +};
> +
> +#if IS_ENABLED(CONFIG_QCOM_OCMEM)
> +
> +struct ocmem *of_get_ocmem(struct device *dev);
> +struct ocmem_buf *ocmem_allocate(struct ocmem *ocmem, enum ocmem_client
> client,
> + unsigned long size);
> +void ocmem_free(struct ocmem *ocmem, enum ocmem_client client,
> + struct ocmem_buf *buf);
> +
> +#else /* IS_ENABLED(CONFIG_QCOM_OCMEM) */
> +
> +static inline struct ocmem *of_get_ocmem(struct device *dev)
> +{
> + return NULL;
This, along with ocmem_allocate() below, need to return ERR_PTR(-ENOSYS).
adreno_gpu_ocmem_init() needs to check for this error code:
ocmem = of_get_ocmem(dev);
if (IS_ERR(ocmem)) {
if (PTR_ERR(ocmem) == -ENXIO || PTR_ERR(ocmem) == -ENOSYS) {
/*
* Return success since either the ocmem property was
* not specified in device tree, or ocmem support is
* not compiled into the kernel.
*/
return 0;
}
return PTR_ERR(ocmem);
}
Brian
> +}
> +
> +static inline struct ocmem_buf *ocmem_allocate(struct ocmem *ocmem,
> +enum ocmem_client client,
> +unsigned long size)
> +{
> + return NULL;
> +}
> +
> +static inline void ocmem_free(struct ocmem *ocmem, enum ocmem_client client,
> + struct ocmem_buf *buf)
> +{
> +}
> +
> +#endif /* IS_ENABLED(CONFIG_QCOM_OCMEM) */
> +
> +#endif /* __OCMEM_H__ */
> --
> 2.20.1
Re: [PATCH 2/6] dt-bindings: display: msm: gmu: add optional ocmem property
On Wed, Jun 19, 2019 at 01:21:20PM -0700, Rob Clark wrote:
> On Wed, Jun 19, 2019 at 1:17 PM Rob Herring wrote:
> >
> > On Sun, Jun 16, 2019 at 7:29 AM Brian Masney wrote:
> > >
> > > Some A3xx and A4xx Adreno GPUs do not have GMEM inside the GPU core and
> > > must use the On Chip MEMory (OCMEM) in order to be functional. Add the
> > > optional ocmem property to the Adreno Graphics Management Unit bindings.
> > >
> > > Signed-off-by: Brian Masney
> > > ---
> > > Documentation/devicetree/bindings/display/msm/gmu.txt | 4
> > > 1 file changed, 4 insertions(+)
> > >
> > > diff --git a/Documentation/devicetree/bindings/display/msm/gmu.txt
> > > b/Documentation/devicetree/bindings/display/msm/gmu.txt
> > > index 90af5b0a56a9..c746b95e95d4 100644
> > > --- a/Documentation/devicetree/bindings/display/msm/gmu.txt
> > > +++ b/Documentation/devicetree/bindings/display/msm/gmu.txt
> > > @@ -31,6 +31,10 @@ Required properties:
> > > - iommus: phandle to the adreno iommu
> > > - operating-points-v2: phandle to the OPP operating points
> > >
> > > +Optional properties:
> > > +- ocmem: phandle to the On Chip Memory (OCMEM) that's present on some
> > > Snapdragon
> > > + SoCs. See
> > > Documentation/devicetree/bindings/soc/qcom/qcom,ocmem.yaml.
> >
> > We already have a couple of similar properties. Lets standardize on
> > 'sram' as that is what TI already uses.
> >
> > Also, is the whole OCMEM allocated to the GMU? If not you should have
> > child nodes to subdivide the memory.
> >
>
> iirc, downstream a large chunk of OCMEM is statically allocated for
> GPU.. the remainder is dynamically allocated for different use-cases.
> The upstream driver Brian is proposing only handles the static
> allocation case
It appears that the GPU expects to use a specific region of ocmem,
specifically starting at 0. The freedreno driver allocates 1MB of
ocmem on the Nexus 5 starting at ocmem address 0. As a test, I
changed the starting address to 0.5MB and kmscube shows only half the
cube, and four wide black bars across the screen:
https://www.flickr.com/photos/masneyb/48100534381/
> (and I don't think we have upstream support for the various audio and
> video use-cases that used dynamic OCMEM allocation downstream)
That's my understanding as well.
> Although maybe we should still have a child node to separate the
> statically and dynamically allocated parts? I'm not sure what would
> make the most sense..
Given that the GPU is expecting a fixed address in ocmem, perhaps it
makes sense to have the child node. How about this based on the
sram/sram.txt bindings?
ocmem: ocmem@fdd0 {
compatible = "qcom,msm8974-ocmem";
reg = <0xfdd0 0x2000>, <0xfec0 0x18>;
reg-names = "ctrl", "mem";
clocks = <&rpmcc RPM_SMD_OCMEMGX_CLK>, <&mmcc OCMEMCX_OCMEMNOC_CLK>;
clock-names = "core", "iface";
gmu-sram@0 {
reg = <0x0 0x10>;
pool;
};
misc-sram@0 {
reg = <0x10 0x08>;
export;
};
};
I marked the misc pool as export since I've seen in the downstream ocmem
sources a reference to their closed libsensors that runs in userspace.
Looking at the sram bindings led me to the genalloc API
(Documentation/core-api/genalloc.rst). I wonder if this is the way that
this should be done?
Brian
[PATCH v3 6/6] drm/msm/gpu: add ocmem init/cleanup functions
The files a3xx_gpu.c and a4xx_gpu.c have ifdefs for the OCMEM support
that was missing upstream. Add two new functions (adreno_gpu_ocmem_init
and adreno_gpu_ocmem_cleanup) that removes some duplicated code.
Signed-off-by: Brian Masney
---
Changes since v2:
- Check for -ENODEV error of_get_ocmem()
- remove fail_cleanup_ocmem label in a[34]xx_gpu_init
Changes since v1:
- remove CONFIG_QCOM_OCMEM #ifdefs
- use unsigned long for memory addresses instead of uint32_t
- add 'depends on QCOM_OCMEM || QCOM_OCMEM=n' to Kconfig
drivers/gpu/drm/msm/Kconfig | 1 +
drivers/gpu/drm/msm/adreno/a3xx_gpu.c | 28 +
drivers/gpu/drm/msm/adreno/a3xx_gpu.h | 3 +-
drivers/gpu/drm/msm/adreno/a4xx_gpu.c | 25
drivers/gpu/drm/msm/adreno/a4xx_gpu.h | 3 +-
drivers/gpu/drm/msm/adreno/adreno_gpu.c | 40 +
drivers/gpu/drm/msm/adreno/adreno_gpu.h | 10 +++
7 files changed, 66 insertions(+), 44 deletions(-)
diff --git a/drivers/gpu/drm/msm/Kconfig b/drivers/gpu/drm/msm/Kconfig
index 9c37e4de5896..b3d3b2172659 100644
--- a/drivers/gpu/drm/msm/Kconfig
+++ b/drivers/gpu/drm/msm/Kconfig
@@ -7,6 +7,7 @@ config DRM_MSM
depends on OF && COMMON_CLK
depends on MMU
depends on INTERCONNECT || !INTERCONNECT
+ depends on QCOM_OCMEM || QCOM_OCMEM=n
select QCOM_MDT_LOADER if ARCH_QCOM
select REGULATOR
select DRM_KMS_HELPER
diff --git a/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
b/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
index c3b4bc6e4155..b3ef06a39653 100644
--- a/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
@@ -17,10 +17,6 @@
* this program. If not, see <http://www.gnu.org/licenses/>.
*/
-#ifdef CONFIG_MSM_OCMEM
-# include
-#endif
-
#include "a3xx_gpu.h"
#define A3XX_INT0_MASK \
@@ -206,9 +202,9 @@ static int a3xx_hw_init(struct msm_gpu *gpu)
gpu_write(gpu, REG_A3XX_RBBM_GPR0_CTL, 0x);
/* Set the OCMEM base address for A330, etc */
- if (a3xx_gpu->ocmem_hdl) {
+ if (a3xx_gpu->ocmem.hdl) {
gpu_write(gpu, REG_A3XX_RB_GMEM_BASE_ADDR,
- (unsigned int)(a3xx_gpu->ocmem_base >> 14));
+ (unsigned int)(a3xx_gpu->ocmem.base >> 14));
}
/* Turn on performance counters: */
@@ -329,10 +325,7 @@ static void a3xx_destroy(struct msm_gpu *gpu)
adreno_gpu_cleanup(adreno_gpu);
-#ifdef CONFIG_MSM_OCMEM
- if (a3xx_gpu->ocmem_base)
- ocmem_free(OCMEM_GRAPHICS, a3xx_gpu->ocmem_hdl);
-#endif
+ adreno_gpu_ocmem_cleanup(&a3xx_gpu->ocmem);
kfree(a3xx_gpu);
}
@@ -507,17 +500,10 @@ struct msm_gpu *a3xx_gpu_init(struct drm_device *dev)
/* if needed, allocate gmem: */
if (adreno_is_a330(adreno_gpu)) {
-#ifdef CONFIG_MSM_OCMEM
- /* TODO this is different/missing upstream: */
- struct ocmem_buf *ocmem_hdl =
- ocmem_allocate(OCMEM_GRAPHICS,
adreno_gpu->gmem);
-
- a3xx_gpu->ocmem_hdl = ocmem_hdl;
- a3xx_gpu->ocmem_base = ocmem_hdl->addr;
- adreno_gpu->gmem = ocmem_hdl->len;
- DBG("using %dK of OCMEM at 0x%08x", adreno_gpu->gmem / 1024,
- a3xx_gpu->ocmem_base);
-#endif
+ ret = adreno_gpu_ocmem_init(&adreno_gpu->base.pdev->dev,
+ adreno_gpu, &a3xx_gpu->ocmem);
+ if (ret)
+ goto fail;
}
if (!gpu->aspace) {
diff --git a/drivers/gpu/drm/msm/adreno/a3xx_gpu.h
b/drivers/gpu/drm/msm/adreno/a3xx_gpu.h
index ab60dc9e344e..727c34f38f9e 100644
--- a/drivers/gpu/drm/msm/adreno/a3xx_gpu.h
+++ b/drivers/gpu/drm/msm/adreno/a3xx_gpu.h
@@ -30,8 +30,7 @@ struct a3xx_gpu {
struct adreno_gpu base;
/* if OCMEM is used for GMEM: */
- uint32_t ocmem_base;
- void *ocmem_hdl;
+ struct adreno_ocmem ocmem;
};
#define to_a3xx_gpu(x) container_of(x, struct a3xx_gpu, base)
diff --git a/drivers/gpu/drm/msm/adreno/a4xx_gpu.c
b/drivers/gpu/drm/msm/adreno/a4xx_gpu.c
index ab2b752566d8..b01388a9e89e 100644
--- a/drivers/gpu/drm/msm/adreno/a4xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a4xx_gpu.c
@@ -2,9 +2,6 @@
/* Copyright (c) 2014 The Linux Foundation. All rights reserved.
*/
#include "a4xx_gpu.h"
-#ifdef CONFIG_MSM_OCMEM
-# include
-#endif
#define A4XX_INT0_MASK \
(A4XX_INT0_RBBM_AHB_ERROR |\
@@ -188,7 +185,7 @@ static int a4xx_hw_init(struct msm_gpu *gpu)
(1 << 30) | 0x);
gpu_write(gpu, REG_A4XX_RB_GMEM_BASE_ADDR,
- (unsigned int)(a4xx_gpu->ocmem_base >> 14));
+ (unsigned int)(a4xx_gpu->ocmem.base >
[PATCH v3 0/6] qcom: add OCMEM support
This patch series adds support for Qualcomm's On Chip MEMory (OCMEM) that is needed in order to support some a3xx and a4xx-based GPUs upstream. This is based on Rob Clark's patch series that he submitted in October 2015 and I am resubmitting updated patches with his permission. See the individual patches for the changelog. This was tested with the GPU on a LG Nexus 5 (hammerhead) phone and this will work on other msm8974-based systems. For a summary of what currently works upstream on the Nexus 5, see my status page at https://masneyb.github.io/nexus-5-upstream/. Brian Masney (4): dt-bindings: soc: qcom: add On Chip MEMory (OCMEM) bindings dt-bindings: display: msm: gmu: add optional ocmem property soc: qcom: add OCMEM driver drm/msm/gpu: add ocmem init/cleanup functions Rob Clark (2): firmware: qcom: scm: add OCMEM lock/unlock interface firmware: qcom: scm: add support to restore secure config to qcm_scm-32 .../devicetree/bindings/display/msm/gmu.txt | 50 ++ .../bindings/sram/qcom/qcom,ocmem.yaml| 84 drivers/firmware/qcom_scm-32.c| 52 ++- drivers/firmware/qcom_scm-64.c| 12 + drivers/firmware/qcom_scm.c | 53 +++ drivers/firmware/qcom_scm.h | 9 + drivers/gpu/drm/msm/Kconfig | 1 + drivers/gpu/drm/msm/adreno/a3xx_gpu.c | 28 +- drivers/gpu/drm/msm/adreno/a3xx_gpu.h | 3 +- drivers/gpu/drm/msm/adreno/a4xx_gpu.c | 25 +- drivers/gpu/drm/msm/adreno/a4xx_gpu.h | 3 +- drivers/gpu/drm/msm/adreno/adreno_gpu.c | 40 ++ drivers/gpu/drm/msm/adreno/adreno_gpu.h | 10 + drivers/soc/qcom/Kconfig | 10 + drivers/soc/qcom/Makefile | 1 + drivers/soc/qcom/ocmem.c | 433 ++ include/linux/qcom_scm.h | 26 ++ include/soc/qcom/ocmem.h | 62 +++ 18 files changed, 857 insertions(+), 45 deletions(-) create mode 100644 Documentation/devicetree/bindings/sram/qcom/qcom,ocmem.yaml create mode 100644 drivers/soc/qcom/ocmem.c create mode 100644 include/soc/qcom/ocmem.h -- 2.20.1
[PATCH v3 3/6] firmware: qcom: scm: add OCMEM lock/unlock interface
From: Rob Clark
Add support for the OCMEM lock/unlock interface that is needed by the
On Chip MEMory (OCMEM) that is present on some Snapdragon devices.
Signed-off-by: Rob Clark
[masn...@onstation.org: ported to latest kernel; minor reformatting.]
Signed-off-by: Brian Masney
Reviewed-by: Bjorn Andersson
---
Rob's last version of this patch:
https://patchwork.kernel.org/patch/7340711/
Changes since v2:
- None
Changes since v1:
- None
drivers/firmware/qcom_scm-32.c | 35 +
drivers/firmware/qcom_scm-64.c | 12 ++
drivers/firmware/qcom_scm.c| 40 ++
drivers/firmware/qcom_scm.h| 9
include/linux/qcom_scm.h | 15 +
5 files changed, 111 insertions(+)
diff --git a/drivers/firmware/qcom_scm-32.c b/drivers/firmware/qcom_scm-32.c
index 215061c581e1..4c2514e5e249 100644
--- a/drivers/firmware/qcom_scm-32.c
+++ b/drivers/firmware/qcom_scm-32.c
@@ -442,6 +442,41 @@ int __qcom_scm_hdcp_req(struct device *dev, struct
qcom_scm_hdcp_req *req,
req, req_cnt * sizeof(*req), resp, sizeof(*resp));
}
+int __qcom_scm_ocmem_lock(struct device *dev, u32 id, u32 offset, u32 size,
+ u32 mode)
+{
+ struct ocmem_tz_lock {
+ __le32 id;
+ __le32 offset;
+ __le32 size;
+ __le32 mode;
+ } request;
+
+ request.id = cpu_to_le32(id);
+ request.offset = cpu_to_le32(offset);
+ request.size = cpu_to_le32(size);
+ request.mode = cpu_to_le32(mode);
+
+ return qcom_scm_call(dev, QCOM_SCM_OCMEM_SVC, QCOM_SCM_OCMEM_LOCK_CMD,
+&request, sizeof(request), NULL, 0);
+}
+
+int __qcom_scm_ocmem_unlock(struct device *dev, u32 id, u32 offset, u32 size)
+{
+ struct ocmem_tz_unlock {
+ __le32 id;
+ __le32 offset;
+ __le32 size;
+ } request;
+
+ request.id = cpu_to_le32(id);
+ request.offset = cpu_to_le32(offset);
+ request.size = cpu_to_le32(size);
+
+ return qcom_scm_call(dev, QCOM_SCM_OCMEM_SVC, QCOM_SCM_OCMEM_UNLOCK_CMD,
+&request, sizeof(request), NULL, 0);
+}
+
void __qcom_scm_init(void)
{
}
diff --git a/drivers/firmware/qcom_scm-64.c b/drivers/firmware/qcom_scm-64.c
index 91d5ad7cf58b..c3a3d9874def 100644
--- a/drivers/firmware/qcom_scm-64.c
+++ b/drivers/firmware/qcom_scm-64.c
@@ -241,6 +241,18 @@ int __qcom_scm_hdcp_req(struct device *dev, struct
qcom_scm_hdcp_req *req,
return ret;
}
+int __qcom_scm_ocmem_lock(struct device *dev, uint32_t id, uint32_t offset,
+ uint32_t size, uint32_t mode)
+{
+ return -ENOTSUPP;
+}
+
+int __qcom_scm_ocmem_unlock(struct device *dev, uint32_t id, uint32_t offset,
+ uint32_t size)
+{
+ return -ENOTSUPP;
+}
+
void __qcom_scm_init(void)
{
u64 cmd;
diff --git a/drivers/firmware/qcom_scm.c b/drivers/firmware/qcom_scm.c
index 2ddc118dba1b..2e12ea56c34c 100644
--- a/drivers/firmware/qcom_scm.c
+++ b/drivers/firmware/qcom_scm.c
@@ -190,6 +190,46 @@ bool qcom_scm_pas_supported(u32 peripheral)
}
EXPORT_SYMBOL(qcom_scm_pas_supported);
+/**
+ * qcom_scm_ocmem_lock_available() - is OCMEM lock/unlock interface available
+ */
+bool qcom_scm_ocmem_lock_available(void)
+{
+ return __qcom_scm_is_call_available(__scm->dev, QCOM_SCM_OCMEM_SVC,
+ QCOM_SCM_OCMEM_LOCK_CMD);
+}
+EXPORT_SYMBOL(qcom_scm_ocmem_lock_available);
+
+/**
+ * qcom_scm_ocmem_lock() - call OCMEM lock interface to assign an OCMEM
+ * region to the specified initiator
+ *
+ * @id: tz initiator id
+ * @offset: OCMEM offset
+ * @size: OCMEM size
+ * @mode: access mode (WIDE/NARROW)
+ */
+int qcom_scm_ocmem_lock(enum qcom_scm_ocmem_client id, u32 offset, u32 size,
+ u32 mode)
+{
+ return __qcom_scm_ocmem_lock(__scm->dev, id, offset, size, mode);
+}
+EXPORT_SYMBOL(qcom_scm_ocmem_lock);
+
+/**
+ * qcom_scm_ocmem_unlock() - call OCMEM unlock interface to release an OCMEM
+ * region from the specified initiator
+ *
+ * @id: tz initiator id
+ * @offset: OCMEM offset
+ * @size: OCMEM size
+ */
+int qcom_scm_ocmem_unlock(enum qcom_scm_ocmem_client id, u32 offset, u32 size)
+{
+ return __qcom_scm_ocmem_unlock(__scm->dev, id, offset, size);
+}
+EXPORT_SYMBOL(qcom_scm_ocmem_unlock);
+
/**
* qcom_scm_pas_init_image() - Initialize peripheral authentication service
*state machine for a given peripheral, using the
diff --git a/drivers/firmware/qcom_scm.h b/drivers/firmware/qcom_scm.h
index 99506bd873c0..ef293ee67ec1 100644
--- a/drivers/firmware/qcom_scm.h
+++ b/drivers/firmware/qcom_scm.h
@@ -42,6 +42,15 @@ extern int __qcom_scm_hdcp_req(struct device *dev,
extern void __qcom_scm_init(void);
+#define QCOM_SCM_OCMEM_SVC 0xf
+#define Q
[PATCH v3 5/6] soc: qcom: add OCMEM driver
The OCMEM driver handles allocation and configuration of the On Chip
MEMory that is present on some Snapdragon SoCs. Devices which have
OCMEM do not have GMEM inside the GPU core, so the GPU must instead
use OCMEM to be functional. Since the GPU is currently the only OCMEM
user with an upstream driver, this is just a minimal implementation
sufficient for statically allocating to the GPU it's chunk of OCMEM.
This driver currently does not read the gmu-sram node that is described
in the device tree bindings. The starting memory address of the GPU's
reserved memory region is hardcoded to zero to match what the hardware
expects. The driver can be updated to read the reserved memory regions
from device tree once other users of OCMEM are added upstream.
Signed-off-by: Brian Masney
Co-developed-by: Rob Clark
Signed-off-by: Rob Clark
---
Changes since v2
- Changed static inline stubs return -ENODEV when OCMEM is not
configured into the kernel.
Changes since v1:
- ocmem_allocate(): check for alignment and minimum allocation size.
The 64K values came from the downstream MSM kernel sources.
- add locking to memory allocations based on the client
- use clk_bulk_*() functions
- rename qcom,ocmem-msm8974 to qcom,msm8974-ocmem
- rename reg-names to ctrl and mem
- remove ocmem.xml.h file; use FIELD_PREP() instead for some nice cleanups
- add static inline noop versions of public-facing functions when ocmem
is disabled to remove #ifdefs in adrenu_gpu.c
- use unsigned long for memory addresses
- move ocmem_dev_remove() below _probe() function
- remove error check from platform_get_resource_byname for ctrl resource
- add MODULE_DESCRIPTION() and MODULE_LICENSE()
- add description to top of ocmem.[ch]
- correct thin mode bit in update_ocmem()
- add 'WARN_ON(client != OCMEM_GRAPHICS)' to device_address()
- make of_get_ocmem return error codes via ERR_PTR instead of NULL
- ocmem_{allocate,free} - WARN_ON() if client != OCMEM_GRAPHICS.
Simplify if statements.
- allow NULL to be passed into ocmem_free
- remove unnecessary initialization of i in update_ocmem()
- add dev_dbg to ocmem_allocate
Changes since Rob's last version of this patch from 2015:
https://patchwork.kernel.org/patch/7379801/
- reformatted driver to allow multiple instances
- updated logging of error paths during device probing
- remove unused psgsc_ctrl
- remove _clk from clock names
- propagate error code from devm_ioremap_resource()
- use device_get_match_data()
- SPDX license tags
- remove QCOM_SMD in Kconfig
- select ARCH_QCOM in Kconfig
- select ARCH_QCOM in Kconfig
- select QCOM_SCM in Kconfig
- longer description in Kconfig
drivers/soc/qcom/Kconfig | 10 +
drivers/soc/qcom/Makefile | 1 +
drivers/soc/qcom/ocmem.c | 433 ++
include/soc/qcom/ocmem.h | 62 ++
4 files changed, 506 insertions(+)
create mode 100644 drivers/soc/qcom/ocmem.c
create mode 100644 include/soc/qcom/ocmem.h
diff --git a/drivers/soc/qcom/Kconfig b/drivers/soc/qcom/Kconfig
index a6d1bfb17279..d18eb83b10da 100644
--- a/drivers/soc/qcom/Kconfig
+++ b/drivers/soc/qcom/Kconfig
@@ -74,6 +74,16 @@ config QCOM_MDT_LOADER
tristate
select QCOM_SCM
+config QCOM_OCMEM
+ tristate "Qualcomm On Chip Memory (OCMEM) driver"
+ depends on ARCH_QCOM
+ select QCOM_SCM
+ help
+ The On Chip Memory (OCMEM) allocator allows various clients to
+ allocate memory from OCMEM based on performance, latency and power
+ requirements. This is typically used by the GPU, camera/video, and
+ audio components on some Snapdragon SoCs.
+
config QCOM_PM
bool "Qualcomm Power Management"
depends on ARCH_QCOM && !ARM64
diff --git a/drivers/soc/qcom/Makefile b/drivers/soc/qcom/Makefile
index eeb088beb15f..dfc378014a33 100644
--- a/drivers/soc/qcom/Makefile
+++ b/drivers/soc/qcom/Makefile
@@ -6,6 +6,7 @@ obj-$(CONFIG_QCOM_COMMAND_DB) += cmd-db.o
obj-$(CONFIG_QCOM_GLINK_SSR) +=glink_ssr.o
obj-$(CONFIG_QCOM_GSBI)+= qcom_gsbi.o
obj-$(CONFIG_QCOM_MDT_LOADER) += mdt_loader.o
+obj-$(CONFIG_QCOM_OCMEM) += ocmem.o
obj-$(CONFIG_QCOM_PM) += spm.o
obj-$(CONFIG_QCOM_QMI_HELPERS) += qmi_helpers.o
qmi_helpers-y += qmi_encdec.o qmi_interface.o
diff --git a/drivers/soc/qcom/ocmem.c b/drivers/soc/qcom/ocmem.c
new file mode 100644
index ..7c28ad3108a6
--- /dev/null
+++ b/drivers/soc/qcom/ocmem.c
@@ -0,0 +1,433 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * The On Chip Memory (OCMEM) allocator allows various clients to allocate
+ * memory from OCMEM based on performance, latency and power requirements.
+ * This is typically used by the GPU, camera/video, and audio components on
+ * some Snapdragon SoCs.
+ *
+ * Copyright (C) 2019 Brian Masney
+ * Copyright (C) 2015 Red Hat. Author: Rob Clark
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
[PATCH v3 2/6] dt-bindings: display: msm: gmu: add optional ocmem property
Some A3xx and A4xx Adreno GPUs do not have GMEM inside the GPU core and
must use the On Chip MEMory (OCMEM) in order to be functional. Add the
optional ocmem property to the Adreno Graphics Management Unit bindings.
Signed-off-by: Brian Masney
---
Changes since v2:
- Add a3xx example with OCMEM
Changes since v1:
- None
.../devicetree/bindings/display/msm/gmu.txt | 50 +++
1 file changed, 50 insertions(+)
diff --git a/Documentation/devicetree/bindings/display/msm/gmu.txt
b/Documentation/devicetree/bindings/display/msm/gmu.txt
index 90af5b0a56a9..e5596994df7b 100644
--- a/Documentation/devicetree/bindings/display/msm/gmu.txt
+++ b/Documentation/devicetree/bindings/display/msm/gmu.txt
@@ -31,6 +31,10 @@ Required properties:
- iommus: phandle to the adreno iommu
- operating-points-v2: phandle to the OPP operating points
+Optional properties:
+- ocmem: phandle to the On Chip Memory (OCMEM) that's present on some
Snapdragon
+ SoCs. See Documentation/devicetree/bindings/soc/qcom/qcom,ocmem.yaml.
+
Example:
/ {
@@ -63,3 +67,49 @@ Example:
operating-points-v2 = <&gmu_opp_table>;
};
};
+
+a3xx example with OCMEM support:
+
+/ {
+ ...
+
+ gpu: adreno@fdb0 {
+ compatible = "qcom,adreno-330.2",
+"qcom,adreno";
+ reg = <0xfdb0 0x1>;
+ reg-names = "kgsl_3d0_reg_memory";
+ interrupts = ;
+ interrupt-names = "kgsl_3d0_irq";
+ clock-names = "core",
+ "iface",
+ "mem_iface";
+ clocks = <&mmcc OXILI_GFX3D_CLK>,
+<&mmcc OXILICX_AHB_CLK>,
+<&mmcc OXILICX_AXI_CLK>;
+ ocmem = <&ocmem>;
+ power-domains = <&mmcc OXILICX_GDSC>;
+ operating-points-v2 = <&gpu_opp_table>;
+ iommus = <&gpu_iommu 0>;
+ };
+
+ ocmem: ocmem@fdd0 {
+ compatible = "qcom,msm8974-ocmem";
+
+ reg = <0xfdd0 0x2000>,
+ <0xfec0 0x18>;
+ reg-names = "ctrl",
+"mem";
+
+ clocks = <&rpmcc RPM_SMD_OCMEMGX_CLK>,
+<&mmcc OCMEMCX_OCMEMNOC_CLK>;
+ clock-names = "core",
+ "iface";
+
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ gmu-sram@0 {
+ reg = <0x0 0x10>;
+ };
+ };
+};
--
2.20.1
[PATCH v3 1/6] dt-bindings: soc: qcom: add On Chip MEMory (OCMEM) bindings
Add device tree bindings for the On Chip Memory (OCMEM) that is present
on some Qualcomm Snapdragon SoCs.
Signed-off-by: Brian Masney
---
Changes since v2:
- Add *-sram node and gmu-sram to example.
Changes since v1:
- Rename qcom,ocmem-msm8974 to qcom,msm8974-ocmem
- Renamed reg-names to ctrl and mem
- update hardware description
- moved from soc to sram namespace in the device tree bindings
.../bindings/sram/qcom/qcom,ocmem.yaml| 84 +++
1 file changed, 84 insertions(+)
create mode 100644 Documentation/devicetree/bindings/sram/qcom/qcom,ocmem.yaml
diff --git a/Documentation/devicetree/bindings/sram/qcom/qcom,ocmem.yaml
b/Documentation/devicetree/bindings/sram/qcom/qcom,ocmem.yaml
new file mode 100644
index ..a0bf0af4860a
--- /dev/null
+++ b/Documentation/devicetree/bindings/sram/qcom/qcom,ocmem.yaml
@@ -0,0 +1,84 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sram/qcom/qcom,ocmem.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: On Chip Memory (OCMEM) that is present on some Qualcomm Snapdragon SoCs.
+
+maintainers:
+ - Brian Masney
+
+description: |
+ The On Chip Memory (OCMEM) is typically used by the GPU, camera/video, and
+ audio components on some Snapdragon SoCs.
+
+properties:
+ compatible:
+const: qcom,msm8974-ocmem
+
+ reg:
+items:
+ - description: Control registers
+ - description: OCMEM address range
+
+ reg-names:
+items:
+ - const: ctrl
+ - const: mem
+
+ clocks:
+items:
+ - description: Core clock
+ - description: Interface clock
+
+ clock-names:
+items:
+ - const: core
+ - const: iface
+
+required:
+ - compatible
+ - reg
+ - reg-names
+ - clocks
+ - clock-names
+
+patternProperties:
+ "^.+-sram$":
+type: object
+description: |
+ A region of reserved memory.
+
+properties:
+ reg:
+maxItems: 1
+
+required:
+ - reg
+
+examples:
+ - |
+ #include
+ #include
+
+ ocmem: ocmem@fdd0 {
+compatible = "qcom,msm8974-ocmem";
+
+reg = <0xfdd0 0x2000>,
+ <0xfec0 0x18>;
+reg-names = "ctrl",
+"mem";
+
+clocks = <&rpmcc RPM_SMD_OCMEMGX_CLK>,
+ <&mmcc OCMEMCX_OCMEMNOC_CLK>;
+clock-names = "core",
+ "iface";
+
+#address-cells = <1>;
+#size-cells = <1>;
+
+gmu-sram@0 {
+reg = <0x0 0x10>;
+};
+ };
--
2.20.1
[PATCH v3 4/6] firmware: qcom: scm: add support to restore secure config to qcm_scm-32
From: Rob Clark
Add support to restore the secure configuration for qcm_scm-32.c. This
is needed by the On Chip MEMory (OCMEM) that is present on some
Snapdragon devices.
Signed-off-by: Rob Clark
[masn...@onstation.org: ported to latest kernel; set ctx_bank_num to
spare parameter.]
Signed-off-by: Brian Masney
---
Changes since v2:
- None
Changes since v1:
- Use existing __qcom_scm_restore_sec_cfg() function stub in
qcom_scm-32.c that was unimplemented
- Set the cfg.ctx_bank_num to the spare function parameter. It was
previously set to the device_id.
drivers/firmware/qcom_scm-32.c | 17 -
drivers/firmware/qcom_scm.c| 13 +
include/linux/qcom_scm.h | 11 +++
3 files changed, 40 insertions(+), 1 deletion(-)
diff --git a/drivers/firmware/qcom_scm-32.c b/drivers/firmware/qcom_scm-32.c
index 4c2514e5e249..5d90b7f5ab5a 100644
--- a/drivers/firmware/qcom_scm-32.c
+++ b/drivers/firmware/qcom_scm-32.c
@@ -617,7 +617,22 @@ int __qcom_scm_assign_mem(struct device *dev, phys_addr_t
mem_region,
int __qcom_scm_restore_sec_cfg(struct device *dev, u32 device_id,
u32 spare)
{
- return -ENODEV;
+ struct msm_scm_sec_cfg {
+ __le32 id;
+ __le32 ctx_bank_num;
+ } cfg;
+ int ret, scm_ret = 0;
+
+ cfg.id = cpu_to_le32(device_id);
+ cfg.ctx_bank_num = cpu_to_le32(spare);
+
+ ret = qcom_scm_call(dev, QCOM_SCM_SVC_MP, QCOM_SCM_RESTORE_SEC_CFG,
+ &cfg, sizeof(cfg), &scm_ret, sizeof(scm_ret));
+
+ if (ret || scm_ret)
+ return ret ? ret : -EINVAL;
+
+ return 0;
}
int __qcom_scm_iommu_secure_ptbl_size(struct device *dev, u32 spare,
diff --git a/drivers/firmware/qcom_scm.c b/drivers/firmware/qcom_scm.c
index 2e12ea56c34c..54532331ddc1 100644
--- a/drivers/firmware/qcom_scm.c
+++ b/drivers/firmware/qcom_scm.c
@@ -366,6 +366,19 @@ static const struct reset_control_ops
qcom_scm_pas_reset_ops = {
.deassert = qcom_scm_pas_reset_deassert,
};
+/**
+ * qcom_scm_restore_sec_cfg_available() - Check if secure environment
+ * supports restore security config interface.
+ *
+ * Return true if restore-cfg interface is supported, false if not.
+ */
+bool qcom_scm_restore_sec_cfg_available(void)
+{
+ return __qcom_scm_is_call_available(__scm->dev, QCOM_SCM_SVC_MP,
+ QCOM_SCM_RESTORE_SEC_CFG);
+}
+EXPORT_SYMBOL(qcom_scm_restore_sec_cfg_available);
+
int qcom_scm_restore_sec_cfg(u32 device_id, u32 spare)
{
return __qcom_scm_restore_sec_cfg(__scm->dev, device_id, spare);
diff --git a/include/linux/qcom_scm.h b/include/linux/qcom_scm.h
index 521b089be1c9..8a24f7eb2588 100644
--- a/include/linux/qcom_scm.h
+++ b/include/linux/qcom_scm.h
@@ -34,6 +34,16 @@ enum qcom_scm_ocmem_client {
QCOM_SCM_OCMEM_DEBUG_ID,
};
+enum qcom_scm_sec_dev_id {
+ QCOM_SCM_MDSS_DEV_ID= 1,
+ QCOM_SCM_OCMEM_DEV_ID = 5,
+ QCOM_SCM_PCIE0_DEV_ID = 11,
+ QCOM_SCM_PCIE1_DEV_ID = 12,
+ QCOM_SCM_GFX_DEV_ID = 18,
+ QCOM_SCM_UFS_DEV_ID = 19,
+ QCOM_SCM_ICE_DEV_ID = 20,
+};
+
#define QCOM_SCM_VMID_HLOS 0x3
#define QCOM_SCM_VMID_MSS_MSA0xF
#define QCOM_SCM_VMID_WLAN 0x18
@@ -69,6 +79,7 @@ extern int qcom_scm_assign_mem(phys_addr_t mem_addr, size_t
mem_sz,
extern void qcom_scm_cpu_power_down(u32 flags);
extern u32 qcom_scm_get_version(void);
extern int qcom_scm_set_remote_state(u32 state, u32 id);
+extern bool qcom_scm_restore_sec_cfg_available(void);
extern int qcom_scm_restore_sec_cfg(u32 device_id, u32 spare);
extern int qcom_scm_iommu_secure_ptbl_size(u32 spare, size_t *size);
extern int qcom_scm_iommu_secure_ptbl_init(u64 addr, u32 size, u32 spare);
--
2.20.1
[PATCH] drm/msm: correct NULL pointer dereference in context_init
Correct attempted NULL pointer dereference in context_init() when
running without an IOMMU.
Signed-off-by: Brian Masney
Fixes: 295b22ae596c ("drm/msm: Pass the MMU domain index in struct
msm_file_private")
---
The no IOMMU case seems like functionality that we may want to keep
based on this comment:
https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/msm/adreno/a3xx_gpu.c#L523
Once I get the msm8974 interconnect driver done, I'm going to look into
what needs to be done to get the IOMMU working on the Nexus 5.
Alternatively, for development purposes, maybe we could have a NOOP
IOMMU driver that would allow us to remove these NULL checks that are
sprinkled throughout the code. I haven't looked into this in detail.
Thoughts?
drivers/gpu/drm/msm/msm_drv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
index 451bd4508793..83047cb2c735 100644
--- a/drivers/gpu/drm/msm/msm_drv.c
+++ b/drivers/gpu/drm/msm/msm_drv.c
@@ -619,7 +619,7 @@ static int context_init(struct drm_device *dev, struct
drm_file *file)
msm_submitqueue_init(dev, ctx);
- ctx->aspace = priv->gpu->aspace;
+ ctx->aspace = priv->gpu ? priv->gpu->aspace : NULL;
file->driver_priv = ctx;
return 0;
--
2.20.1
[PATCH] drm/msm/phy/dsi_phy: silence -EPROBE_DEFER warnings
The following errors show up when booting the Nexus 5:
msm_dsi_phy fd922a00.dsi-phy: [drm:dsi_phy_driver_probe] *ERROR*
dsi_phy_regulator_init: failed to init regulator, ret=-517
msm_dsi_phy fd922a00.dsi-phy: [drm:dsi_phy_driver_probe] *ERROR*
dsi_phy_driver_probe: failed to init regulator
dsi_phy_regulator_init() already logs the error, so no need to log
the same error a second time in dsi_phy_driver_probe(). This patch
also changes dsi_phy_regulator_init() to not log the error if the
error code is -EPROBE_DEFER to reduce noise in dmesg.
Signed-off-by: Brian Masney
---
drivers/gpu/drm/msm/dsi/phy/dsi_phy.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/msm/dsi/phy/dsi_phy.c
b/drivers/gpu/drm/msm/dsi/phy/dsi_phy.c
index 4097eca1b3ef..d0e1cc6728dc 100644
--- a/drivers/gpu/drm/msm/dsi/phy/dsi_phy.c
+++ b/drivers/gpu/drm/msm/dsi/phy/dsi_phy.c
@@ -396,8 +396,11 @@ static int dsi_phy_regulator_init(struct msm_dsi_phy *phy)
ret = devm_regulator_bulk_get(dev, num, s);
if (ret < 0) {
- DRM_DEV_ERROR(dev, "%s: failed to init regulator, ret=%d\n",
- __func__, ret);
+ if (ret != -EPROBE_DEFER)
+ DRM_DEV_ERROR(dev,
+ "%s: failed to init regulator, ret=%d\n",
+ __func__, ret);
+
return ret;
}
@@ -584,10 +587,8 @@ static int dsi_phy_driver_probe(struct platform_device
*pdev)
}
ret = dsi_phy_regulator_init(phy);
- if (ret) {
- DRM_DEV_ERROR(dev, "%s: failed to init regulator\n", __func__);
+ if (ret)
goto fail;
- }
phy->ahb_clk = msm_clk_get(pdev, "iface");
if (IS_ERR(phy->ahb_clk)) {
--
2.20.1
Re: [PATCH 1/2] dt-bindings: drm/panel: simple: add lg,acx467akm-7 panel
Hi Linus, On Tue, Mar 05, 2019 at 11:42:15PM +0100, Linus Walleij wrote: > On Sat, Nov 24, 2018 at 9:06 PM Brian Masney wrote: > > > Add binding for the LG ACX467AKM-7 4.95" 1080×1920 LCD panel that is > > found on the LG Nexus 5 (hammerhead) phone. This appears to be a JDI > > panel based on some Internet searches, however a specific model number > > could not be found. I disassembled an old Nexus 5 with a broken > > screen and the LG part number is the only model number present on the > > back of the panel, so I think that is probably the best ID to use. > > > > Signed-off-by: Brian Masney > > Reviewed-by: Linus Walleij > > Tell me if you need me to merge this to the DRM misc tree. It would be great if you could take this patch, plus the corresponding change to panel-simple.c [1] [1] https://lore.kernel.org/lkml/20181124200628.24393-2-masn...@onstation.org/ Thanks, Brian ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 1/3] backlight: lm3630a: return 0 on success in update_status functions
lm3630a_bank_a_update_status() and lm3630a_bank_b_update_status()
both return the brightness value if the brightness was successfully
updated. Writing to these attributes via sysfs would cause a 'Bad
address' error to be returned. These functions should return 0 on
success, so let's change it to correct that error.
Signed-off-by: Brian Masney
Fixes: 28e64a68a2ef ("backlight: lm3630: apply chip revision")
---
drivers/video/backlight/lm3630a_bl.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/video/backlight/lm3630a_bl.c
b/drivers/video/backlight/lm3630a_bl.c
index 2030a6b77a09..ef2553f452ca 100644
--- a/drivers/video/backlight/lm3630a_bl.c
+++ b/drivers/video/backlight/lm3630a_bl.c
@@ -201,7 +201,7 @@ static int lm3630a_bank_a_update_status(struct
backlight_device *bl)
LM3630A_LEDA_ENABLE, LM3630A_LEDA_ENABLE);
if (ret < 0)
goto out_i2c_err;
- return bl->props.brightness;
+ return 0;
out_i2c_err:
dev_err(pchip->dev, "i2c failed to access\n");
@@ -278,7 +278,7 @@ static int lm3630a_bank_b_update_status(struct
backlight_device *bl)
LM3630A_LEDB_ENABLE, LM3630A_LEDB_ENABLE);
if (ret < 0)
goto out_i2c_err;
- return bl->props.brightness;
+ return 0;
out_i2c_err:
dev_err(pchip->dev, "i2c failed to access REG_CTRL\n");
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 0/3] backlight: lm3630a: bug fix and device tree support
Here is a patch series that fixes a single bug and adds device tree support to the lm3630a driver. This work was tested on a LG Nexus 5 (hammerhead) phone. My status page at https://masneyb.github.io/nexus-5-upstream/ describes what is working so far with the upstream kernel. Changes since v1 (from November): - Don't use a trivial binding and expose some of the settings available in the platform data. Sorry for the long delay sending out v2. I got busy with other projects. Brian Masney (3): backlight: lm3630a: return 0 on success in update_status functions dt-bindings: backlight: add lm3630a bindings backlight: lm3630a: add device tree supprt .../leds/backlight/lm3630a-backlight.yaml | 112 ++ drivers/video/backlight/lm3630a_bl.c | 73 +++- 2 files changed, 183 insertions(+), 2 deletions(-) create mode 100644 Documentation/devicetree/bindings/leds/backlight/lm3630a-backlight.yaml -- 2.20.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 2/3] dt-bindings: backlight: add lm3630a bindings
Add new backlight bindings for the TI LM3630A dual-string white LED.
Signed-off-by: Brian Masney
---
.../leds/backlight/lm3630a-backlight.yaml | 112 ++
1 file changed, 112 insertions(+)
create mode 100644
Documentation/devicetree/bindings/leds/backlight/lm3630a-backlight.yaml
diff --git
a/Documentation/devicetree/bindings/leds/backlight/lm3630a-backlight.yaml
b/Documentation/devicetree/bindings/leds/backlight/lm3630a-backlight.yaml
new file mode 100644
index ..42a8c59d237a
--- /dev/null
+++ b/Documentation/devicetree/bindings/leds/backlight/lm3630a-backlight.yaml
@@ -0,0 +1,112 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/leds/backlight/lm3630a-backlight.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: TI LM3630A High-Efficiency Dual-String White LED
+
+maintainers:
+ - Lee Jones
+ - Daniel Thompson
+ - Jingoo Han
+
+description: |
+ The LM3630A is a current-mode boost converter which supplies the power and
+ controls the current in up to two strings of 10 LEDs per string.
+ https://www.ti.com/product/LM3630A
+
+properties:
+ compatible:
+const: ti,lm3630a
+
+ reg:
+maxItems: 1
+
+ ti,linear-mapping-mode:
+description: |
+ Enable linear mapping mode. If disabled, then it will use exponential
+ mapping mode in which the ramp up/down appears to have a more uniform
+ tranisiton to the human eye.
+type: boolean
+
+required:
+ - compatible
+ - reg
+
+patternProperties:
+ "^led*$":
+type: object
+description: |
+ Properties for a string of connected LEDs.
+
+properties:
+ label:
+description: |
+ The label for this LED. If omitted, the label is taken from the node
+ name (excluding the unit address). It has to uniquely identify a
+ device, i.e. no other LED class device can be assigned the same
label.
+
+ led-sources:
+description: |
+ List of device current outputs the LED is connected to.
+allOf:
+ - $ref: /schemas/types.yaml#/definitions/uint32-array
+ - minItems: 1
+maxItems: 2
+items:
+ minimum: 0
+ maximum: 1
+
+ default-brightness:
+description: Default brightness level on boot.
+minimum: 0
+maximum: 255
+
+ max-brightness:
+description: Maximum brightness level on boot.
+minimum: 0
+maximum: 255
+
+examples:
+ - |
+i2c {
+#address-cells = <1>;
+#size-cells = <0>;
+
+lm3630a_bl@38 {
+compatible = "ti,lm3630a";
+status = "ok";
+reg = <0x38>;
+
+led {
+label = "main-lcd";
+led-sources = <0 1>;
+default-brightness = <200>;
+max-brightness = <255>;
+};
+};
+};
+ - |
+i2c {
+#address-cells = <1>;
+#size-cells = <0>;
+
+lm3630a_bl@38 {
+compatible = "ti,lm3630a";
+status = "ok";
+reg = <0x38>;
+
+led-bank-a {
+led-sources = <0>;
+default-brightness = <150>;
+ti,linear-mapping-mode;
+};
+
+led-bank-b {
+led-sources = <1>;
+default-brightness = <225>;
+ti,linear-mapping-mode;
+};
+};
+};
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 3/3] backlight: lm3630a: add device tree supprt
Add device tree support to the lm3630a driver and allow configuring
independently on both banks the mapping mode (linear or exponential),
initial and maximum LED brightness.
Driver was tested on a LG Nexus 5 (hammerhead) phone.
Signed-off-by: Brian Masney
---
drivers/video/backlight/lm3630a_bl.c | 69
1 file changed, 69 insertions(+)
diff --git a/drivers/video/backlight/lm3630a_bl.c
b/drivers/video/backlight/lm3630a_bl.c
index ef2553f452ca..96fbc1273dda 100644
--- a/drivers/video/backlight/lm3630a_bl.c
+++ b/drivers/video/backlight/lm3630a_bl.c
@@ -35,6 +35,9 @@
#define REG_MAX0x50
#define INT_DEBOUNCE_MSEC 10
+
+#define LM3630A_MAX_SOURCES2
+
struct lm3630a_chip {
struct device *dev;
struct delayed_work work;
@@ -364,6 +367,64 @@ static const struct regmap_config lm3630a_regmap = {
.max_register = REG_MAX,
};
+static void lm3630a_parse_dt(struct lm3630a_chip *pchip)
+{
+ u32 sources[LM3630A_MAX_SOURCES], val;
+ struct device_node *child_node;
+ int num_sources, ret, i;
+ bool linear;
+
+ for_each_available_child_of_node(pchip->dev->of_node, child_node) {
+ num_sources = of_property_count_u32_elems(child_node,
+ "led-sources");
+ if (num_sources < 0)
+ continue;
+
+ if (num_sources > LM3630A_MAX_SOURCES)
+ num_sources = LM3630A_MAX_SOURCES;
+
+ ret = of_property_read_u32_array(child_node, "led-sources",
+sources, num_sources);
+ if (ret) {
+ dev_err(pchip->dev,
+ "Error parsing led-sources node: %d\n", ret);
+ return;
+ }
+
+ linear = of_property_read_bool(child_node,
+ "ti,linear-mapping-mode");
+
+ for (i = 0; i < num_sources; i++) {
+ if (sources[i] == 0)
+ pchip->pdata->leda_ctrl = linear ?
+ LM3630A_LEDA_ENABLE_LINEAR :
+ LM3630A_LEDA_ENABLE;
+ else if (sources[i] == 1)
+ pchip->pdata->ledb_ctrl = linear ?
+ LM3630A_LEDB_ENABLE_LINEAR :
+ LM3630A_LEDB_ENABLE;
+
+ ret = of_property_read_u32(child_node,
+ "default-brightness", &val);
+ if (!ret) {
+ if (sources[i] == 0)
+ pchip->pdata->leda_init_brt = val;
+ else if (sources[i] == 1)
+ pchip->pdata->ledb_init_brt = val;
+ }
+
+ ret = of_property_read_u32(child_node, "max-brightness",
+ &val);
+ if (!ret) {
+ if (sources[i] == 0)
+ pchip->pdata->leda_max_brt = val;
+ else if (sources[i] == 1)
+ pchip->pdata->ledb_max_brt = val;
+ }
+ }
+ };
+}
+
static int lm3630a_probe(struct i2c_client *client,
const struct i2c_device_id *id)
{
@@ -405,6 +466,7 @@ static int lm3630a_probe(struct i2c_client *client,
pdata->ledb_init_brt = LM3630A_MAX_BRIGHTNESS;
}
pchip->pdata = pdata;
+ lm3630a_parse_dt(pchip);
/* chip initialize */
rval = lm3630a_chip_init(pchip);
@@ -470,11 +532,18 @@ static const struct i2c_device_id lm3630a_id[] = {
{}
};
+static const struct of_device_id lm3630a_match_table[] = {
+ { .compatible = "ti,lm3630a", },
+ { },
+};
+
+
MODULE_DEVICE_TABLE(i2c, lm3630a_id);
static struct i2c_driver lm3630a_i2c_driver = {
.driver = {
.name = LM3630A_NAME,
+ .of_match_table = lm3630a_match_table,
},
.probe = lm3630a_probe,
.remove = lm3630a_remove,
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 2/3] dt-bindings: backlight: add lm3630a bindings
On Mon, Apr 01, 2019 at 11:39:26PM +0200, Pavel Machek wrote: > On Mon 2019-04-01 06:30:33, Brian Masney wrote: > > Add new backlight bindings for the TI LM3630A dual-string white LED. > > > > Signed-off-by: Brian Masney > > --- > > .../leds/backlight/lm3630a-backlight.yaml | 112 > ++ > > What is that? Is it future of all the bindings? > > Up to device tree people, I guess, but... Yes, this is the future format of the bindings so that automated validation can be performed. See Documentation/devicetree/writing-schema.md. Brian ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 3/3] backlight: lm3630a: add device tree supprt
On Mon, Apr 01, 2019 at 11:48:47PM +0200, Pavel Machek wrote:
> So ... we can have multiple LEDs, each can have up to two
> sources.. and the settings are really per source, not per LED.
>
> But you do not test for overlaps. What prevents me from having
>
>foo {
>led_sources = <0>;
>ti,linear-mapping-mode;
>}
>bar {
>led_sources = <0>;
>}
>
> (I.e. conflicting settings for a source?)
In this case, it will go with the settings for 'bar'. I didn't check for
the conflicting settings since I was going for consistency with the
other two backlight drivers that already have the led-sources property:
arcxcnn_bl.c and sky81452-backlight.c. I can add the additional check
to fail if a source has already been encountered.
> Plus I do not see parsing of led labels etc...
OK... I can fix that up plus your other two comments.
Thanks,
Brian
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 2/3] dt-bindings: backlight: add lm3630a bindings
On Tue, Apr 02, 2019 at 07:56:55AM -0500, Dan Murphy wrote:
> This would connect control bank B to control bank A. Or just use a flag to
> denote to connect them
> and not use led-sources. But led-sources is the property of choice.
>
> led@0 {
> reg = <0>;
> led-sources = < 0 1 >;
> label = "main-lcd";
> default-brightness = <200>;
> max-brightness = <255>;
> };
OK, I see. I wondered how we could do that in device tree.
> > +properties:
> > + label:
> > +description: |
> > + The label for this LED. If omitted, the label is taken from the
> > node
> > + name (excluding the unit address). It has to uniquely identify a
> > + device, i.e. no other LED class device can be assigned the same
> > label.
> > +
> > + led-sources:
> > +description: |
> > + List of device current outputs the LED is connected to.
> > +allOf:
> > + - $ref: /schemas/types.yaml#/definitions/uint32-array
> > + - minItems: 1
> > +maxItems: 2
> > +items:
> > + minimum: 0
> > + maximum: 1
> > +
>
> label and led-sources are already defined in the common.txt no need to
> redefine them here.
If I'm going to use the new-style bindings, then I'll need to convert
common.txt over to use the new format as well so that the automated
schema validations will work. I'm willing to do that work if there is
interest from the LED / backlight maintainers. The main issue is that
there are 62 references to the file common.txt in the directory
Documentation/devicetree/bindings/leds/. Would the maintainers prefer:
- Once common.txt is converted to common.yaml, make common.txt only
have a line stating that the common bindings were moved into
common.yaml. We can remove this file once all of the other bindings
are converted to the new-style format.
- Update all references to common.txt to common.yaml. (1 patch or 62
patches?)
- Or, just go with the older-style binding format for now.
Thanks Dan for your other comments. They make sense and I'll incorporate
those changes into my next version.
Brian
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
drm/msm: 'pp done time out' errors after async commit changes
Hey Rob,
Since commit 2d99ced787e3 ("drm/msm: async commit support"), the frame
buffer console on my Nexus 5 began throwing these errors:
msm fd90.mdss: pp done time out, lm=0
The display still works.
I see that mdp5_flush_commit() was introduced in commit 9f6b65642bd2
("drm/msm: add kms->flush_commit()") with a TODO comment and the commit
description mentions flushing registers. I assume that this is the
proper fix. If so, can you point me to where these registers are
defined and I can work on the mdp5 implementation.
Thanks,
Brian
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
