Re: [PATCH v6 9/9] usb: misc: onboard_dev: add support for XMOS XVF3500

2024-02-29 Thread Matthias Kaehlcke
s.com/xvf3500/ > > Signed-off-by: Javier Carrasco Acked-by: Matthias Kaehlcke

Re: [PATCH v6 7/9] usb: misc: onboard_dev: add support for non-hub devices

2024-02-29 Thread Matthias Kaehlcke
-12,60 +12,70 @@ struct onboard_dev_pdata { > unsigned long reset_us; /* reset pulse width in us */ > unsigned int num_supplies; /* number of supplies */ > const char * const supply_names[MAX_SUPPLIES]; > + bool is_hub;/* true if the device is a HUB */ nit: either drop the comment (the variable name is pretty self explaining), or s/HUB/hub/ ('hub' isn't an acronym). Acked-by: Matthias Kaehlcke

Re: [PATCH v6 6/9] ARM: multi_v7_defconfig: update ONBOARD_USB_HUB to ONBOAD_USB_DEV

2024-02-29 Thread Matthias Kaehlcke
ned-off-by: Javier Carrasco Reviewed-by: Matthias Kaehlcke

Re: [PATCH v6 5/9] arm64: defconfig: update ONBOARD_USB_HUB to ONBOARD_USB_DEV

2024-02-29 Thread Matthias Kaehlcke
On Thu, Feb 29, 2024 at 09:34:48AM +0100, Javier Carrasco wrote: > The onboard_usb_hub driver has been updated to support non-hub devices, > which has led to some renaming. > > Update to the new name (ONBOARD_USB_DEV) accordingly. > > Signed-off-by: Javier Carrasco Rev

Re: [PATCH v6 4/9] drm: ci: arm64.config: update ONBOARD_USB_HUB to ONBOARD_USB_DEV

2024-02-29 Thread Matthias Kaehlcke
f-by: Javier Carrasco Reviewed-by: Matthias Kaehlcke

Re: [PATCH v6 3/9] usb: misc: onboard_hub: rename to onboard_dev

2024-02-29 Thread Matthias Kaehlcke
es in cases where more than 80 characters are used. > > No new functionality has been added. > > Signed-off-by: Javier Carrasco Acked-by: Matthias Kaehlcke This should land together with "usb: misc: onboard_dev: add support for non-hub devices". > diff --git a/drivers/usb/mis

Re: [PATCH v6 2/9] usb: misc: onboard_hub: use device supply names

2024-02-29 Thread Matthias Kaehlcke
> names for existing devices to keep backward compatibility. > > Signed-off-by: Javier Carrasco Acked-by: Matthias Kaehlcke

Re: [PATCH v6 1/9] usb: misc: onboard_hub: use pointer consistently in the probe function

2024-02-29 Thread Matthias Kaehlcke
o keep code > consistency. > > Signed-off-by: Javier Carrasco Acked-by: Matthias Kaehlcke

Re: [PATCH v5 6/8] usb: misc: onboard_dev: add support for non-hub devices

2024-02-28 Thread Matthias Kaehlcke
On Wed, Feb 28, 2024 at 09:50:22PM +0100, Javier Carrasco wrote: > On 28.02.24 21:41, Matthias Kaehlcke wrote: > > On Wed, Feb 28, 2024 at 09:21:00PM +0100, Javier Carrasco wrote: > >> On 28.02.24 19:10, Matthias Kaehlcke wrote: > >>> On Wed, Feb 28, 2024 at 02:51:33P

Re: [PATCH v5 6/8] usb: misc: onboard_dev: add support for non-hub devices

2024-02-28 Thread Matthias Kaehlcke
On Wed, Feb 28, 2024 at 09:21:00PM +0100, Javier Carrasco wrote: > On 28.02.24 19:10, Matthias Kaehlcke wrote: > > On Wed, Feb 28, 2024 at 02:51:33PM +0100, Javier Carrasco wrote: > >> Most of the functionality this driver provides can be used by non-hub > >> devices as

Re: [PATCH v5 8/8] usb: misc: onboard_hub: add support for XMOS XVF3500

2024-02-28 Thread Matthias Kaehlcke
no longer exists as such with the other patches of this series. > Once in normal operation, the XVF3500 registers itself as a USB device, > and it does not require any device-specific operations in the driver. > > [1] https://www.xmos.com/xvf3500/ > > Signed-off-by: Jav

Re: [PATCH v5 2/8] usb: misc: onboard_hub: rename to onboard_dev

2024-02-28 Thread Matthias Kaehlcke
On Wed, Feb 28, 2024 at 02:51:29PM +0100, Javier Carrasco wrote: > This patch prepares onboad_hub to support non-hub devices by renaming > the driver files and their content, the headers and their references. > > The comments and descriptions have been slightly modified to keep > coherence and acc

Re: [PATCH v5 6/8] usb: misc: onboard_dev: add support for non-hub devices

2024-02-28 Thread Matthias Kaehlcke
On Wed, Feb 28, 2024 at 02:51:33PM +0100, Javier Carrasco wrote: > Most of the functionality this driver provides can be used by non-hub > devices as well. > > To account for the hub-specific code, add a flag to the device data > structure and check its value for hub-specific code. > > The 'alway

Re: [PATCH v5 1/8] usb: misc: onboard_hub: use device supply names

2024-02-28 Thread Matthias Kaehlcke
On Wed, Feb 28, 2024 at 05:02:10PM +0100, Javier Carrasco wrote: > On 28.02.24 16:37, Matthias Kaehlcke wrote: > > Hi Javier, > > > > Thanks for moving this patch to the front of the series! > > > > A few more comments inline. > > > > On Wed, Feb

Re: [PATCH v5 1/8] usb: misc: onboard_hub: use device supply names

2024-02-28 Thread Matthias Kaehlcke
Hi Javier, Thanks for moving this patch to the front of the series! A few more comments inline. On Wed, Feb 28, 2024 at 02:51:28PM +0100, Javier Carrasco wrote: > The current implementation uses generic names for the power supplies, > which conflicts with proper name definitions in the device bi

Re: [PATCH v4 6/8] usb: misc: onboard_dev: use device supply names

2024-02-27 Thread Matthias Kaehlcke
On Tue, Feb 20, 2024 at 03:05:50PM +0100, Javier Carrasco wrote: > The current mechanism uses generic names for the power supplies, which > conflicts with proper name definitions in the device bindings. > > Add a per-device property to include real supply names and keep generic > names as a fallba

Re: [PATCH v4 2/8] usb: misc: onboard_dev: add support for non-hub devices

2024-02-27 Thread Matthias Kaehlcke
On Thu, Feb 22, 2024 at 03:42:26PM +0100, Javier Carrasco wrote: > On 21.02.24 20:24, Matthias Kaehlcke wrote: > > On Tue, Feb 20, 2024 at 03:05:46PM +0100, Javier Carrasco wrote: > >> Most of the functionality this driver provides can be used by non-hub > >> devices as

Re: [PATCH v4 6/8] usb: misc: onboard_dev: use device supply names

2024-02-21 Thread Matthias Kaehlcke
On Wed, Feb 21, 2024 at 10:33:53PM +0100, Javier Carrasco wrote: > On 21.02.24 22:18, Matthias Kaehlcke wrote: > >>>> +/* > >>>> + * Fallback supply names for backwards compatibility. If the device > >>>> requires > >>>> + * more

Re: [PATCH v4 6/8] usb: misc: onboard_dev: use device supply names

2024-02-21 Thread Matthias Kaehlcke
Hi Javier, On Wed, Feb 21, 2024 at 09:40:38PM +0100, Javier Carrasco wrote: > On 21.02.24 21:25, Matthias Kaehlcke wrote: > > On Tue, Feb 20, 2024 at 03:05:50PM +0100, Javier Carrasco wrote: > >> The current mechanism uses generic names for the power supplies, which > >

Re: [PATCH v4 6/8] usb: misc: onboard_dev: use device supply names

2024-02-21 Thread Matthias Kaehlcke
On Tue, Feb 20, 2024 at 03:05:50PM +0100, Javier Carrasco wrote: > The current mechanism uses generic names for the power supplies, which > conflicts with proper name definitions in the device bindings. > > Add a per-device property to include real supply names and keep generic > names as a fallba

Re: [PATCH v4 2/8] usb: misc: onboard_dev: add support for non-hub devices

2024-02-21 Thread Matthias Kaehlcke
On Tue, Feb 20, 2024 at 03:05:46PM +0100, Javier Carrasco wrote: > Most of the functionality this driver provides can be used by non-hub > devices as well. > > To account for the hub-specific code, add a flag to the device data > structure and check its value for hub-specific code. Please mention

Re: [PATCH v4 1/8] usb: misc: onboard_hub: rename to onboard_dev

2024-02-21 Thread Matthias Kaehlcke
- a/Documentation/ABI/testing/sysfs-bus-platform-onboard-usb-hub > +++ b/Documentation/ABI/testing/sysfs-bus-platform-onboard-usb-dev > @@ -4,5 +4,5 @@ KernelVersion:5.20 > Contact: Matthias Kaehlcke > linux-...@vger.kernel.org > Description: > -

[PATCH] drm/panel-edp: Fix AUO B133UAN01 panel id

2022-03-30 Thread Matthias Kaehlcke
ned-off-by: Matthias Kaehlcke --- drivers/gpu/drm/panel/panel-edp.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/panel/panel-edp.c b/drivers/gpu/drm/panel/panel-edp.c index db4eea1d7f67..1732b4f56e38 100644 --- a/drivers/gpu/drm/panel/panel-edp.c +++ b/drive

[PATCH v2] panel-edp: drm/panel-edp: Add AUO B133UAN01

2022-03-24 Thread Matthias Kaehlcke
Add support for the AUO B133UAN01 13.3" WUXGA panel. Signed-off-by: Matthias Kaehlcke --- Changes in v2: - autodetect and configure the panel based on the EDID data instead of relying on a compatible string and hardcoded mode settings. drivers/gpu/drm/panel/panel-edp.c | 1 + 1 file ch

Re: [PATCH 2/2] drm/panel-edp: Add AUO B133UAN01

2022-03-24 Thread Matthias Kaehlcke
Hi Doug, On Thu, Mar 24, 2022 at 11:27:46AM -0700, Doug Anderson wrote: > Hi, > > On Thu, Mar 24, 2022 at 11:14 AM Matthias Kaehlcke wrote: > > > > Add support for the AUO B133UAN01 13.3" WUXGA panel. > > > > Signed-off-by: Matthias Kaehlcke > > ---

[PATCH 2/2] drm/panel-edp: Add AUO B133UAN01

2022-03-24 Thread Matthias Kaehlcke
Add support for the AUO B133UAN01 13.3" WUXGA panel. Signed-off-by: Matthias Kaehlcke --- output of edid-decode: Block 0, Base EDID: EDID Structure Version & Revision: 1.4 Vendor & Product Identification: Manufacturer: AUO Model: 34196 Made in: 2020

[PATCH 1/2] dt-bindings: display: simple: Add AUO B133UAN01 panel

2022-03-24 Thread Matthias Kaehlcke
Add binding for the AUO B133UAN01 panel. It is 13.3" TFT LCD panel with WUXGA (1920x1200) resolution. Signed-off-by: Matthias Kaehlcke --- .../devicetree/bindings/display/panel/panel-simple.yaml | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bin

Re: [PATCH v2 2/4] arm64: dts: qcom: sc7280: Add support for eDP panel on CRD

2022-02-08 Thread Matthias Kaehlcke
On Tue, Feb 08, 2022 at 08:48:43PM +0530, Sankeerth Billakanti wrote: > Enable the eDP display panel support without HPD on sc7280 platform. > > Signed-off-by: Sankeerth Billakanti > --- > > Changes in v2: > - sort node references alphabetically > - improve readability > - move the pwm pin

Re: [PATCH v1 3/4] arm64: dts: qcom: sc7280: Add DSI display nodes

2021-08-18 Thread Matthias Kaehlcke
dsi_phy: dsi-phy@ae94400 { > + compatible = "qcom,sc7280-dsi-phy-7nm"; > + reg = <0 0x0ae94400 0 0x200>, > + <0 0x0ae94600 0 0x280>, > + <0 0x0ae94900 0 0x280>; > + reg-names = "dsi_phy", > + "dsi_phy_lane", > + "dsi_pll"; > + > + #clock-cells = <1>; > + #phy-cells = <0>; > + > + clocks = <&dispcc DISP_CC_MDSS_AHB_CLK>, > + <&rpmhcc RPMH_CXO_CLK>; > + clock-names = "iface", "ref"; > + > + status = "disabled"; > + }; I'm not an expect, but this looks sane to me and it's very similar to the SC7180 config. Reviewed-by: Matthias Kaehlcke

Re: [PATCH v1 4/4] arm64: dts: qcom: sc7280: add edp display dt nodes

2021-08-18 Thread Matthias Kaehlcke
On Wed, Aug 18, 2021 at 03:57:04PM +0530, Krishna Manikandan wrote: > From: Sankeerth Billakanti > > Add edp controller and phy DT nodes for sc7280. > > Signed-off-by: Sankeerth Billakanti > --- > arch/arm64/boot/dts/qcom/sc7280.dtsi | 127 > ++- > 1 file chang

Re: [PATCH v1 2/2] dt-bindings: Add SC7280 compatible string

2021-08-16 Thread Matthias Kaehlcke
On Thu, Aug 12, 2021 at 05:38:02AM +0530, Sankeerth Billakanti wrote: > The Qualcomm SC7280 platform supports an eDP controller, add > compatible string for it to msm/binding. > > Signed-off-by: Sankeerth Billakanti > --- > Documentation/devicetree/bindings/display/msm/dp-controller.yaml | 3 +++

Re: [PATCH v1 1/2] drm/msm/dp: Add support for SC7280 eDP

2021-08-16 Thread Matthias Kaehlcke
On Thu, Aug 12, 2021 at 05:38:01AM +0530, Sankeerth Billakanti wrote: > The eDP controller on SC7280 is similar to the eDP/DP controllers > supported by the current driver implementation. > > SC7280 supports one EDP and one DP controller which can operate > concurrently. > > The following are som

Re: [v1] drm/msm/disp/dpu1: icc path needs to be set before dpu runtime resume

2021-03-22 Thread Matthias Kaehlcke
35] gcc_disp_hf_axi_clk already unprepared Tested-by: Matthias Kaehlcke ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC PATCH 1/3] dt-bindings: display: simple: Add the panel on sc7180-trogdor-pompom

2021-03-17 Thread Matthias Kaehlcke
GPM940B0 3.0" QVGA TFT LCD panel >- giantplus,gpm940b0 > +# A panel connected to a google,pompom board. Panel is guaranteed to > +# confirm to google,pompom-panel power sequencing requirements and > then s/confirm/conform/ ? > +# the s

Re: [PATCH 1/2] arm64: dts: qcom: sc7180: Add gpu cooling support

2020-10-15 Thread Matthias Kaehlcke
Hi, On Thu, Oct 15, 2020 at 12:07:01AM +0530, man...@codeaurora.org wrote: > On 2020-10-14 18:59, Akhil P Oommen wrote: > > On 10/9/2020 10:27 PM, Matthias Kaehlcke wrote: > > > On Fri, Oct 09, 2020 at 08:05:10AM -0700, Doug Anderson wrote: > > > > Hi, > > &g

Re: [PATCH 1/2] arm64: dts: qcom: sc7180: Add gpu cooling support

2020-10-09 Thread Matthias Kaehlcke
On Fri, Oct 09, 2020 at 08:05:10AM -0700, Doug Anderson wrote: > Hi, > > On Thu, Oct 8, 2020 at 10:10 AM Akhil P Oommen wrote: > > > > Add cooling-cells property and the cooling maps for the gpu tzones > > to support GPU cooling. > > > > Signed-off-by: Akhil P Oommen > > --- > > arch/arm64/boot

Re: [PATCH] drm: msm: a6xx: fix gpu failure after system resume

2020-07-14 Thread Matthias Kaehlcke
r a few iterations without this patch. Reported-by: Matthias Kaehlcke Tested-by: Matthias Kaehlcke On which tree is this patch based on? I had to apply it manually because 'git am' is unhappy when I try to apply it: error: sha1 information is lacking or useless (drivers/gpu/drm/msm/ad

Re: [v1] drm/msm/dpu: add support for clk and bw scaling for display

2020-07-14 Thread Matthias Kaehlcke
On Tue, Jul 14, 2020 at 04:39:47PM +0530, kalya...@codeaurora.org wrote: > On 2020-07-14 06:42, Matthias Kaehlcke wrote: > > On Thu, Jun 18, 2020 at 07:38:41PM +0530, Kalyan Thota wrote: > > > This change adds support to scale src clk and bandwidth as > > > p

Re: [v1] drm/msm/dpu: add support for clk and bw scaling for display

2020-07-13 Thread Matthias Kaehlcke
On Thu, Jun 18, 2020 at 07:38:41PM +0530, Kalyan Thota wrote: > This change adds support to scale src clk and bandwidth as > per composition requirements. > > Interconnect registration for bw has been moved to mdp > device node from mdss to facilitate the scaling. > > Changes in v1: > - Address

Re: [PATCH v2 2/4] drm/msm: dsi: Use OPP API to set clk/perf state

2020-07-06 Thread Matthias Kaehlcke
lkname(&pdev->dev, "byte"); > + if (IS_ERR(msm_host->opp_table)) > + return PTR_ERR(msm_host->opp_table); > + /* OPP table is optional */ > + ret = dev_pm_opp_of_add_table(&pdev->dev); > + if (!ret) { > +

Re: [PATCH] drm/msm: handle for EPROBE_DEFER for of_icc_get

2020-07-01 Thread Matthias Kaehlcke
On Wed, Jul 01, 2020 at 01:13:34PM -0400, Jonathan Marek wrote: > On 7/1/20 1:12 PM, Matthias Kaehlcke wrote: > > Hi Jonathan, > > > > On Tue, Jun 30, 2020 at 11:08:41PM -0400, Jonathan Marek wrote: > > > Check for EPROBE_DEFER instead of silently not using icc

Re: [PATCH] drm/msm: handle for EPROBE_DEFER for of_icc_get

2020-07-01 Thread Matthias Kaehlcke
Hi Jonathan, On Tue, Jun 30, 2020 at 11:08:41PM -0400, Jonathan Marek wrote: > Check for EPROBE_DEFER instead of silently not using icc if the msm driver > probes before the interconnect driver. Agreed with supporting deferred ICC probing. > Only check for EPROBE_DEFER because of_icc_get can ret

Re: [PATCH 2/4] drm/msm: dsi: Use OPP API to set clk/perf state

2020-07-01 Thread Matthias Kaehlcke
On Tue, Jun 30, 2020 at 05:26:14PM +0530, Rajendra Nayak wrote: > On SDM845 DSI needs to express a perforamnce state nit: performance > requirement on a power domain depending on the clock rates. > Use OPP table from DT to register with OPP framework and use > dev_pm_opp_set_rate() to set the clk

Re: [PATCH 4/4] arm64: dts: sc7180: Add DSI and MDP OPP tables and power-domains

2020-07-01 Thread Matthias Kaehlcke
On Tue, Jun 30, 2020 at 05:26:16PM +0530, Rajendra Nayak wrote: > Add the OPP tables for DSI and MDP based on the perf state/clk > requirements, and add the power-domains property to specify the > scalable power domain. > > Signed-off-by: Rajendra Nayak Reviewed-by: Ma

Re: [PATCH 3/4] arm64: dts: sdm845: Add DSI and MDP OPP tables and power-domains

2020-07-01 Thread Matthias Kaehlcke
"core", > "iface", > "bus"; > + operating-points-v2 = <&dsi_opp_table>; > + power-dom

Re: [PATCH v3 2/6] drm: msm: a6xx: send opp instead of a frequency

2020-06-24 Thread Matthias Kaehlcke
Hi, On Thu, Jun 18, 2020 at 10:52:09AM -0700, Rob Clark wrote: > On Fri, Jun 5, 2020 at 9:26 PM Sharat Masetty wrote: > > > > This patch changes the plumbing to send the devfreq recommended opp rather > > than the frequency. Also consolidate and rearrange the code in a6xx to set > > the GPU frequ

Re: [PATCH 5/6] drm: msm: a6xx: use dev_pm_opp_set_bw to set DDR bandwidth

2020-05-14 Thread Matthias Kaehlcke
On Thu, May 14, 2020 at 04:24:18PM +0530, Sharat Masetty wrote: > This patches replaces the previously used static DDR vote and uses > dev_pm_opp_set_bw() to scale GPU->DDR bandwidth along with scaling > GPU frequency. > > Signed-off-by: Sharat Masetty > --- > drivers/gpu/drm/msm/adreno/a6xx_gmu

Re: [PATCH 4/6] drm: msm: a6xx: send opp instead of a frequency

2020-05-14 Thread Matthias Kaehlcke
On Thu, May 14, 2020 at 05:39:57PM -0700, Matthias Kaehlcke wrote: > On Thu, May 14, 2020 at 04:24:17PM +0530, Sharat Masetty wrote: > > This patch changes the plumbing to send the devfreq recommended opp rather > > than the frequency. Also consolidate and rearrange the code in a6xx

Re: [PATCH 4/6] drm: msm: a6xx: send opp instead of a frequency

2020-05-14 Thread Matthias Kaehlcke
On Thu, May 14, 2020 at 04:24:17PM +0530, Sharat Masetty wrote: > This patch changes the plumbing to send the devfreq recommended opp rather > than the frequency. Also consolidate and rearrange the code in a6xx to set > the GPU frequency and the icc vote in preparation for the upcoming > changes fo

Re: [PATCH 3/6] OPP: Add and export helper to set bandwidth

2020-05-14 Thread Matthias Kaehlcke
On Thu, May 14, 2020 at 04:24:16PM +0530, Sharat Masetty wrote: > From: Sibi Sankar > > Add and export 'dev_pm_opp_set_bw' to set the bandwidth > levels associated with an OPP for a given frequency. Wait, this looks very much like Sibi's patch from v4 of the "DDR/L3 Scaling support on SDM845 and

Re: [PATCH 0/6] Add support for GPU DDR BW scaling

2020-05-14 Thread Matthias Kaehlcke
On Thu, May 14, 2020 at 04:24:13PM +0530, Sharat Masetty wrote: > Subject: [PATCH 0/6] Add support for GPU DDR BW scaling For anything but the first version the subject (for all patches) should include the version (i.e. [v2, 0/6], etc for this series). > This is a rework of my previous series [1

Re: [PATCH 2/6] arm64: dts: qcom: sc7180: Add opp-peak-kBps to GPU opp

2020-05-14 Thread Matthias Kaehlcke
p-level = > ; > + opp-peak-kBps = <3072000>; > }; ditto > opp-18000 { > opp-hz = /bits/ 64 <18000>; >

Re: [PATCH 1/6] arm64: dts: qcom: sc7180: Add interconnect bindings for GPU

2020-05-14 Thread Matthias Kaehlcke
Hi Sharat, On Thu, May 14, 2020 at 04:24:14PM +0530, Sharat Masetty wrote: > Subject: arm64: dts: qcom: sc7180: Add interconnect bindings for GPU > > This patch adds the interconnect bindings to the GPU node. This enables > the GPU->DDR path bandwidth voting. This patch doesn't add any bindings,

Re: [v2] arm64: dts: sc7180: add dsi controller and phy entries for idp dts

2020-05-06 Thread Matthias Kaehlcke
On Fri, Feb 14, 2020 at 10:49:37AM -0800, Matthias Kaehlcke wrote: > On Tue, Feb 11, 2020 at 05:07:35PM +0530, Harigovindan P wrote: > > > subject: arm64: dts: sc7180: add dsi controller and phy entries for idp dts > > nit: 'dts' at the end is redundant, the prefixes

Re: [PATCH v5 1/3] dt-bindings: phy: qcom,qmp: Convert QMP PHY bindings to yaml

2020-04-29 Thread Matthias Kaehlcke
Hi Sandeep, On Thu, Apr 23, 2020 at 10:14:36AM -0700, Matthias Kaehlcke wrote: > Hi Sandeep, > > On Tue, Apr 14, 2020 at 02:21:17PM -0700, Stephen Boyd wrote: > > Quoting Sandeep Maheswaram (2020-04-01 23:38:52) > > > Convert QMP PHY bindings to DT schema

Re: [PATCH v3 05/17] drm/msm/dpu: Use OPP API to set clk/perf state

2020-04-28 Thread Matthias Kaehlcke
te(dev, 0); > rc = msm_dss_enable_clk(mp->clk_config, mp->num_clk, false); > if (rc) > DPU_ERROR("clock disable failed rc:%d\n", rc); > diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h > b/drivers/gpu/d

Re: [PATCH v5 1/3] dt-bindings: phy: qcom,qmp: Convert QMP PHY bindings to yaml

2020-04-23 Thread Matthias Kaehlcke
Hi Sandeep, On Tue, Apr 14, 2020 at 02:21:17PM -0700, Stephen Boyd wrote: > Quoting Sandeep Maheswaram (2020-04-01 23:38:52) > > Convert QMP PHY bindings to DT schema format using json-schema. > > > > Signed-off-by: Sandeep Maheswaram > > --- > > .../devicetree/bindings/phy/qcom,qmp-phy.yaml

Re: [PATCH v11 1/2] drm/panel: add support for rm69299 visionox panel driver

2020-04-21 Thread Matthias Kaehlcke
ror: corrupt patch at line 379 Patch failed at 0001 drm/panel: add support for rm69299 visionox panel driver Besides the broken format: Reviewed-by: Matthias Kaehlcke ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 05/17] drm/msm/dpu: Use OPP API to set clk/perf state

2020-04-17 Thread Matthias Kaehlcke
Hi Rajendra, I have essentially the same comments as for "tty: serial: qcom_geni_serial: Use OPP API to set clk/perf state" (https://patchwork.kernel.org/patch/11495209/). about error handling of 'dev_pm_opp_of_add_table' and misleading struct member names 'opp'/'opp_table'. Please apply the requ

Re: [PATCH v7 2/2] drm/panel: add support for rm69299 visionox panel driver

2020-04-15 Thread Matthias Kaehlcke
Hi, checkpatch finds multiple errors with this patch, as Sam reported on https://patchwork.kernel.org/cover/11461945/. Please fix those and send a new version (not sure which version number this should be (v11?), this series is a bit confusing in this aspect). Please also double check if there is

Re: [PATCH v5 3/5] thermal: devfreq_cooling: Use PM QoS to set frequency limits

2020-04-03 Thread Matthias Kaehlcke
Hi Daniel, On Fri, Apr 03, 2020 at 06:43:20PM +0200, Daniel Lezcano wrote: > On 18/03/2020 12:45, Lukasz Luba wrote: > > From: Matthias Kaehlcke > > > > Now that devfreq supports limiting the frequency range of a device > > through PM QoS make use of it instead of

Re: [v1 3/3] arm64: dts: sc7180: define interconnects for sc7180 target

2020-04-01 Thread Matthias Kaehlcke
On Wed, Apr 01, 2020 at 02:47:45PM +0530, Krishna Manikandan wrote: > Subject: arm64: dts: sc7180: define interconnects for sc7180 target Please be more specific about which interconnect entries are added. Also no need to repeat 'sc7180', it is already clear from the prefix. _

Re: [PATCH v10 0/2] Add support for rm69299 Visionox panel driver and add devicetree bindings for visionox panel

2020-03-31 Thread Matthias Kaehlcke
On Mon, Mar 30, 2020 at 09:25:11PM +0200, Sam Ravnborg wrote: > Hi Matthias. > > On Sun, Mar 29, 2020 at 10:44:17AM -0700, Matthias Kaehlcke wrote: > > Hi Sam, > > > > On Sat, Mar 28, 2020 at 09:40:47PM +0100, Sam Ravnborg wrote: > > > Hi Harigovindan > &

Re: [PATCH v10 0/2] Add support for rm69299 Visionox panel driver and add devicetree bindings for visionox panel

2020-03-29 Thread Matthias Kaehlcke
Hi Sam, On Sat, Mar 28, 2020 at 09:40:47PM +0100, Sam Ravnborg wrote: > Hi Harigovindan > > On Fri, Mar 27, 2020 at 01:06:34PM +0530, Harigovindan P wrote: > > Adding support for visionox rm69299 panel driver and adding bindings for > > the same panel. > > > > Harigovindan P (2): > > dt-bindi

Re: [PATCH v7 2/2] drm/panel: add support for rm69299 visionox panel driver

2020-03-16 Thread Matthias Kaehlcke
On Mon, Mar 16, 2020 at 09:46:47AM +0530, Harigovindan P wrote: > Add support for Visionox panel driver. > > Signed-off-by: Harigovindan P Reviewed-by: Matthias Kaehlcke ___ dri-devel mailing list dri-devel@lists.freedesktop.

Re: [PATCH v6 2/2] drm/panel: add support for rm69299 visionox panel driver

2020-03-11 Thread Matthias Kaehlcke
common way to do this kind of unwinding in the kernel would be to add something like this before 'err_dsi_attach': err_set_load: mipi_dsi_detach(dsi); and then just do 'goto err_set_load' in the error paths. > + > + ret = regulator_set_load(ctx->supplies[1].consumer

Re: [PATCH v5 2/2] drm/panel: add support for rm69299 visionox panel driver

2020-03-09 Thread Matthias Kaehlcke
Hi, On Mon, Mar 09, 2020 at 10:53:04AM +0530, Harigovindan P wrote: > Add support for Visionox panel driver. > > Signed-off-by: Harigovindan P > --- > > Changes in v2: > - Dropping redundant space in Kconfig(Sam Ravnborg). > - Changing structure for include files(Sam Ravnborg). >

Re: [PATCH v4 2/2] drm/panel: add support for rm69299 visionox panel driver

2020-03-06 Thread Matthias Kaehlcke
Hi, On Fri, Mar 06, 2020 at 04:06:28PM +0530, Harigovindan P wrote: > Add support for Visionox panel driver. > > Signed-off-by: Harigovindan P > --- > > Changes in v2: > - Dropping redundant space in Kconfig(Sam Ravnborg). > - Changing structure for include files(Sam Ravnborg). >

Re: [DPU PATCH v3 3/5] drm/msm/dp: add displayPort driver support

2020-02-27 Thread Matthias Kaehlcke
On Thu, Feb 27, 2020 at 01:54:33PM -0800, Matthias Kaehlcke wrote: > On Mon, Dec 02, 2019 at 01:48:57PM +, Chandan Uddaraju wrote: > > Add the needed displayPort files to enable DP driver > > on msm target. > > > > "dp_display" module is the main module

Re: [DPU PATCH v3 4/5] drm/msm/dp: add support for DP PLL driver

2020-02-27 Thread Matthias Kaehlcke
On Mon, Dec 02, 2019 at 01:48:27PM +, Chandan Uddaraju wrote: > Add the needed DP PLL specific files to support > display port interface on msm targets. > > The DP driver calls the DP PLL driver registration. > The DP driver sets the link and pixel clock sources. > > Changes in v2: > -- Updat

Re: [DPU PATCH v3 3/5] drm/msm/dp: add displayPort driver support

2020-02-27 Thread Matthias Kaehlcke
On Mon, Dec 02, 2019 at 01:48:57PM +, Chandan Uddaraju wrote: > Add the needed displayPort files to enable DP driver > on msm target. > > "dp_display" module is the main module that calls into > other sub-modules. "dp_drm" file represents the interface > between DRM framework and DP driver. >

Re: [PATCH] dt-bindings: arm-smmu: update the list of clocks

2020-02-20 Thread Matthias Kaehlcke
On Thu, Feb 20, 2020 at 01:42:22PM +0530, Sharat Masetty wrote: > This patch adds a clock definition needed for powering on the GPU TBUs > and the GPU TCU. > > Signed-off-by: Sharat Masetty > --- > Documentation/devicetree/bindings/iommu/arm,smmu.yaml | 3 +++ > 1 file changed, 3 insertions(+) >

Re: [v2] arm64: dts: sc7180: add dsi controller and phy entries for idp dts

2020-02-14 Thread Matthias Kaehlcke
On Tue, Feb 11, 2020 at 05:07:35PM +0530, Harigovindan P wrote: > subject: arm64: dts: sc7180: add dsi controller and phy entries for idp dts nit: 'dts' at the end is redundant, the prefixes make it clear that this is about DT entries. Also the message isn't really concise. The main entries for

Re: [PATCH v2 1/7] iommu/arm-smmu: Pass io_pgtable_cfg to impl specific init_context

2020-01-31 Thread Matthias Kaehlcke
Hi, On Thu, Jan 02, 2020 at 04:32:07PM +0530, Sharat Masetty wrote: > From: Jordan Crouse > > Pass the propposed io_pgtable_cfg to the implementation specific > init_context() function to give the implementation an opportunity to > to modify it before it gets passed to io-pgtable. > > Signed-of

Re: [v4] arm64: dts: sc7180: add display dt nodes

2020-01-28 Thread Matthias Kaehlcke
Hi, On Tue, Jan 28, 2020 at 06:54:44PM +0530, Harigovindan P wrote: > Add display, DSI hardware DT nodes for sc7180. > > Signed-off-by: Harigovindan P > --- > > Changes in v1: > -Added display DT nodes for sc7180 > Changes in v2: > -Renamed node names > -Corrected code alignme

Re: [v1] arm64: dts: sc7180: add dsi controller and phy entries for idp dts

2020-01-28 Thread Matthias Kaehlcke
Hi, On Tue, Jan 28, 2020 at 07:06:57PM +0530, Harigovindan P wrote: > Adding dsi controller and phy entries for idp dt. > > Signed-off-by: Harigovindan P > --- > arch/arm64/boot/dts/qcom/sc7180-idp.dts | 56 > + > 1 file changed, 56 insertions(+) > > diff --git

Re: [PATCH] drm/msm: Fix a6xx GMU shutdown sequence

2020-01-23 Thread Matthias Kaehlcke
Hi Jordan, On Thu, Jan 23, 2020 at 09:42:36AM -0700, Jordan Crouse wrote: > Commit e812744c5f95 ("drm: msm: a6xx: Add support for A618") missed > updating the VBIF flush in a6xx_gmu_shutdown and instead > inserted the new sequence into a6xx_pm_suspend along with a redundant > GMU idle. > > Move a

Re: [PATCH v2 1/2] dt-bindings: display: add sc7180 panel variant

2020-01-13 Thread Matthias Kaehlcke
Hi, On Tue, Jan 07, 2020 at 04:59:56PM +0530, Harigovindan P wrote: > Subject: dt-bindings: display: add sc7180 panel variant > > Add a compatible string to support sc7180 panel version. The sc7180 is a SoC, I suppose you are referring to the sc7180-idp, a board based on this SoC. But even with t

Re: [PATCH 5/5] arm: dts: sc7180: Add A618 gpu dt blob

2019-12-04 Thread Matthias Kaehlcke
Hi Sharat, on which tree is this patch based on? It does not apply against qcom/arm64-for-5.6-to-be-rebased. In one of my repos which has a non-upstream Qualcomm tree as remote git can make sense of the hashes in the index line, however the parent of your patch looks quite different from the mai

Re: [PATCH v1] drm/msm: add support for 2.4.1 DSI version for sc7180 soc

2019-12-03 Thread Matthias Kaehlcke
Hi, On Fri, Nov 29, 2019 at 12:35:05PM +0530, Harigovindan P wrote: > Changes in v1: > -Modify commit text to indicate DSI version and SOC detail(Jeffrey > Hugo). > -Splitting visionox panel driver code out into a >different patch(set), since panel drivers are merged into >

[PATCH] backlight: pwm_bl: Add missing curly branches in else branch

2019-10-03 Thread Matthias Kaehlcke
Add curly braces to an 'else' branch in pwm_backlight_update_status() to match the corresponding 'if' branch. Signed-off-by: Matthias Kaehlcke --- drivers/video/backlight/pwm_bl.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/video/backligh

[PATCH v2] drm/bridge: dw-hdmi: Refuse DDC/CI transfers on the internal I2C controller

2019-10-02 Thread Matthias Kaehlcke
used. The I2C transfers complete without errors, however the data in the response is garbage. Abort transfers to/from slave address 0x37 (DDC) with -EOPNOTSUPP, to make it evident that the communication is failing. Signed-off-by: Matthias Kaehlcke Reviewed-by: Douglas Anderson Reviewed-by: Sean

[PATCH v2] backlight: pwm_bl: Don't assign levels table repeatedly

2019-10-02 Thread Matthias Kaehlcke
pwm_backlight_probe() re-assigns pb->levels for every brightness level. This is not needed and was likely not intended, since neither side of the assignment changes during the loop. Assign the field only once. Signed-off-by: Matthias Kaehlcke --- Changes in v2: - removed curly braces from

Re: [PATCH] backlight: pwm_bl: Don't assign levels table repeatedly

2019-10-02 Thread Matthias Kaehlcke
On Wed, Oct 02, 2019 at 11:07:37AM +0100, Daniel Thompson wrote: > On Tue, Oct 01, 2019 at 04:29:24PM -0700, Matthias Kaehlcke wrote: > > pwm_backlight_probe() re-assigns pb->levels for every brightness > > level. This is not needed and was likely not intended, since >

[PATCH] backlight: pwm_bl: Don't assign levels table repeatedly

2019-10-01 Thread Matthias Kaehlcke
pwm_backlight_probe() re-assigns pb->levels for every brightness level. This is not needed and was likely not intended, since neither side of the assignment changes during the loop. Assign the field only once. Signed-off-by: Matthias Kaehlcke --- drivers/video/backlight/pwm_bl.c | 4 ++--

Re: [PATCH v3 2/4] backlight: Expose brightness curve type through sysfs

2019-08-19 Thread Matthias Kaehlcke
Hi Daniel, On Mon, Aug 19, 2019 at 11:02:41AM +0100, Daniel Thompson wrote: > On Fri, Aug 16, 2019 at 10:53:17AM -0700, Matthias Kaehlcke wrote: > > On Fri, Aug 16, 2019 at 04:54:18PM +0100, Daniel Thompson wrote: > > > On 07/08/2019 21:15, Matthias Kaehlcke wrote: > > >

Re: [PATCH v3 2/4] backlight: Expose brightness curve type through sysfs

2019-08-16 Thread Matthias Kaehlcke
On Fri, Aug 16, 2019 at 09:47:54PM +0200, Uwe Kleine-König wrote: > On Fri, Aug 16, 2019 at 10:51:57AM -0700, Matthias Kaehlcke wrote: > > Hi Uwe, > > > > On Fri, Aug 16, 2019 at 06:51:48PM +0200, Uwe Kleine-König wrote: > > > On Tue, Jul 09, 2019 at 12:00:05PM

Re: [PATCH v3 2/4] backlight: Expose brightness curve type through sysfs

2019-08-16 Thread Matthias Kaehlcke
On Fri, Aug 16, 2019 at 04:54:18PM +0100, Daniel Thompson wrote: > On 07/08/2019 21:15, Matthias Kaehlcke wrote: > > On Tue, Jul 09, 2019 at 12:00:05PM -0700, Matthias Kaehlcke wrote: > > > Backlight brightness curves can have different shapes. The two main > > > type

Re: [PATCH v3 2/4] backlight: Expose brightness curve type through sysfs

2019-08-16 Thread Matthias Kaehlcke
Hi Uwe, On Fri, Aug 16, 2019 at 06:51:48PM +0200, Uwe Kleine-König wrote: > On Tue, Jul 09, 2019 at 12:00:05PM -0700, Matthias Kaehlcke wrote: > > Backlight brightness curves can have different shapes. The two main > > types are linear and non-linear curves. The human eye doesn

Re: [PATCH v3 2/4] backlight: Expose brightness curve type through sysfs

2019-08-07 Thread Matthias Kaehlcke
On Tue, Jul 09, 2019 at 12:00:05PM -0700, Matthias Kaehlcke wrote: > Backlight brightness curves can have different shapes. The two main > types are linear and non-linear curves. The human eye doesn't > perceive linearly increasing/decreasing brightness as linear (see >

Re: [PATCH v3 0/4] backlight: Expose brightness curve type through sysfs

2019-07-25 Thread Matthias Kaehlcke
On Thu, Jul 25, 2019 at 12:15:41PM +0100, Lee Jones wrote: > On Mon, 22 Jul 2019, Matthias Kaehlcke wrote: > > > On Tue, Jul 09, 2019 at 12:00:03PM -0700, Matthias Kaehlcke wrote: > > > Backlight brightness curves can have different shapes. The two main > > > t

Re: [PATCH v3 0/4] backlight: Expose brightness curve type through sysfs

2019-07-22 Thread Matthias Kaehlcke
On Tue, Jul 09, 2019 at 12:00:03PM -0700, Matthias Kaehlcke wrote: > Backlight brightness curves can have different shapes. The two main > types are linear and non-linear curves. The human eye doesn't > perceive linearly increasing/decreasing brightness as linear (see >

Re: [PATCH v2] drm/bridge: dw-hdmi: Refuse DDC/CI transfers on the internal I2C controller

2019-07-22 Thread Matthias Kaehlcke
On Mon, Jul 22, 2019 at 04:24:26PM -0400, Sean Paul wrote: > On Mon, Jul 22, 2019 at 11:19:45AM -0700, Matthias Kaehlcke wrote: > > The DDC/CI protocol involves sending a multi-byte request to the > > display via I2C, which is typically followed by a multi-byte > > respo

Re: [PATCH v2] drm/bridge: dw-hdmi: Refuse DDC/CI transfers on the internal I2C controller

2019-07-22 Thread Matthias Kaehlcke
On Mon, Jul 22, 2019 at 01:12:40PM -0700, Doug Anderson wrote: > Hi, > > On Mon, Jul 22, 2019 at 11:19 AM Matthias Kaehlcke wrote: > > > > The DDC/CI protocol involves sending a multi-byte request to the > > display via I2C, which is typically followed by a multi-byte

[PATCH v2] drm/bridge: dw-hdmi: Refuse DDC/CI transfers on the internal I2C controller

2019-07-22 Thread Matthias Kaehlcke
used. The I2C transfers complete without errors, however the data in the response is garbage. Abort transfers to/from slave address 0x37 (DDC) with -EOPNOTSUPP, to make it evident that the communication is failing. Signed-off-by: Matthias Kaehlcke --- Changes in v2: - changed DDC_I2C_ADDR to

Re: [PATCH] drm/bridge: dw-hdmi: Refuse DDC/CI transfers on the internal I2C controller

2019-07-19 Thread Matthias Kaehlcke
On Fri, Jul 19, 2019 at 12:23:26PM -0400, Adam Jackson wrote: > On Thu, 2019-07-18 at 14:41 -0700, Matthias Kaehlcke wrote: > > > diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c > > b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c > > index 045b1b13fd0e..e49402ebd56f

[PATCH] drm/bridge: dw-hdmi: Refuse DDC/CI transfers on the internal I2C controller

2019-07-18 Thread Matthias Kaehlcke
used. The I2C transfers complete without errors, however the data in the response is garbage. Abort transfers to/from slave address 0x37 (DDC) with -EOPNOTSUPP, to make it evident that the communication is failing. Signed-off-by: Matthias Kaehlcke --- drivers/gpu/drm/bridge/synopsys/dw-hdmi.c

[PATCH v3 1/4] MAINTAINERS: Add entry for stable backlight sysfs ABI documentation

2019-07-09 Thread Matthias Kaehlcke
Add an entry for the stable backlight sysfs ABI to the MAINTAINERS file. Signed-off-by: Matthias Kaehlcke Acked-by: Daniel Thompson --- Changes in v3: - none Changes in v2: - added Daniel's 'Acked-by' tag --- MAINTAINERS | 1 + 1 file changed, 1 insertion(+) diff --git

[PATCH v3 2/4] backlight: Expose brightness curve type through sysfs

2019-07-09 Thread Matthias Kaehlcke
Export the type of the brightness curve via the new sysfs attribute 'scale'. The value of the attribute can be 'linear', 'non-linear' or 'unknown'. For devices that don't provide information about the scale of their brightness curve the value of the '

[PATCH v3 3/4] backlight: pwm_bl: Set scale type for CIE 1931 curves

2019-07-09 Thread Matthias Kaehlcke
For backlight curves calculated with the CIE 1931 algorithm set the brightness scale type to non-linear. This makes the scale type available to userspace via the 'scale' sysfs attribute. Signed-off-by: Matthias Kaehlcke Tested-by: Enric Balletbo i Serra Acked-by: Daniel Thompson ---

  1   2   3   >