Re: [PATCH v3 2/4] irqchip/qcom-pdc: Switch to using IRQCHIP_PLATFORM_DRIVER helper macros
On 8/5/20 3:19 PM, Saravana Kannan wrote: > On Wed, Aug 5, 2020 at 12:44 AM John Stultz wrote: >> >> So this is where I bashfully admit I didn't get a chance to try this >> patch series out, as I had success with a much older version of >> Saravana's macro magic. >> >> But unfortunately, now that this has landed in mainline, I'm seeing >> boot regressions on db845c. :( This is in the non-modular case, >> building the driver in. > Does that mean the modular version is working? Or you haven't tried > that yet? I'll wait for your reply before I try to fix it. I don't > have the hardware, but it should be easy to guess this issue looking > at the code delta. For what it's worth, I saw this too on the Lenovo C630 (started on -next around 20200727, but I didn't track it down as, well, there's less way to get debug output on the C630. In my testing, module or built-in doesn't matter, but reverting does allow me to boot again. > The only significant change from what your probe function is doing is > this snippet. But it'd be surprising if this only affects the builtin > case. > > + if (par_np == np) > + par_np = NULL; > + > + /* > + * If there's a parent interrupt controller and none of the parent irq > + * domains have been registered, that means the parent interrupt > + * controller has not been initialized yet. it's not time for this > + * interrupt controller to initialize. So, defer probe of this > + * interrupt controller. The actual initialization callback of this > + * interrupt controller can check for specific domains as necessary. > + */ > + if (par_np && !irq_find_matching_host(np, DOMAIN_BUS_ANY)) > + return -EPROBE_DEFER; > >> I managed to bisect it down to this patch, and reverting it avoids the >> issue. I don't see what is wrong right off, but I really need to get >> to bed, so I'll dig further tomorrow. >> >> Saravana: Apologies for not getting around to testing this beforehand! > No worries. Apologies for breaking it accidentally. > > -Saravana
Re: [PATCH v3 2/4] irqchip/qcom-pdc: Switch to using IRQCHIP_PLATFORM_DRIVER helper macros
On 8/5/20 4:16 PM, Steev Klimaszewski wrote: > On 8/5/20 3:19 PM, Saravana Kannan wrote: >> On Wed, Aug 5, 2020 at 12:44 AM John Stultz wrote: >>> >>> So this is where I bashfully admit I didn't get a chance to try this >>> patch series out, as I had success with a much older version of >>> Saravana's macro magic. >>> >>> But unfortunately, now that this has landed in mainline, I'm seeing >>> boot regressions on db845c. :( This is in the non-modular case, >>> building the driver in. >> Does that mean the modular version is working? Or you haven't tried >> that yet? I'll wait for your reply before I try to fix it. I don't >> have the hardware, but it should be easy to guess this issue looking >> at the code delta. > For what it's worth, I saw this too on the Lenovo C630 (started on -next > around 20200727, but I didn't track it down as, well, there's less way > to get debug output on the C630. > > In my testing, module or built-in doesn't matter, but reverting does > allow me to boot again. > Actually - I spoke too soon - QCOM_PDC built-in with the commit reverted boots, however, module (on the c630 at least) doesn't boot whether it's a module or built-in. >> The only significant change from what your probe function is doing is >> this snippet. But it'd be surprising if this only affects the builtin >> case. >> >> + if (par_np == np) >> + par_np = NULL; >> + >> + /* >> + * If there's a parent interrupt controller and none of the parent irq >> + * domains have been registered, that means the parent interrupt >> + * controller has not been initialized yet. it's not time for this >> + * interrupt controller to initialize. So, defer probe of this >> + * interrupt controller. The actual initialization callback of this >> + * interrupt controller can check for specific domains as necessary. >> + */ >> + if (par_np && !irq_find_matching_host(np, DOMAIN_BUS_ANY)) >> + return -EPROBE_DEFER; >> >>> I managed to bisect it down to this patch, and reverting it avoids the >>> issue. I don't see what is wrong right off, but I really need to get >>> to bed, so I'll dig further tomorrow. >>> >>> Saravana: Apologies for not getting around to testing this beforehand! >> No worries. Apologies for breaking it accidentally. >> >> -Saravana
Re: [PATCH] drm/bridge: ti-sn65dsi86: Add retries for link training
On 10/2/20 4:03 PM, Douglas Anderson wrote:
> On some panels hooked up to the ti-sn65dsi86 bridge chip we found that
> link training was failing. Specifically, we'd see:
>
> ti_sn65dsi86 2-002d: [drm:ti_sn_bridge_enable] *ERROR* Link training
> failed, link is off (-5)
>
> The panel was hooked up to a logic analyzer and it was found that, as
> part of link training, the bridge chip was writing a 0x1 to DPCD
> address 00600h and the panel responded NACK. As can be seen in header
> files, the write of 0x1 to DPCD address 0x600h means we were trying to
> write the value DP_SET_POWER_D0 to the register DP_SET_POWER. The
> panel vendor says that a NACK in this case is not unexpected and means
> "not ready, try again".
>
> In testing, we found that this panel would respond with a NACK in
> about 1/25 times. Adding the retry logic worked fine and the most
> number of tries needed was 3. Just to be safe, we'll add 10 tries
> here and we'll add a little blurb to the logs if we ever need more
> than 5.
>
> Signed-off-by: Douglas Anderson
> ---
>
> drivers/gpu/drm/bridge/ti-sn65dsi86.c | 40 +++
> 1 file changed, 29 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> index ecdf9b01340f..6e12cda69b54 100644
> --- a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> +++ b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> @@ -106,6 +106,8 @@
> #define SN_NUM_GPIOS 4
> #define SN_GPIO_PHYSICAL_OFFSET 1
>
> +#define SN_LINK_TRAINING_TRIES 10
> +
> /**
> * struct ti_sn_bridge - Platform data for ti-sn65dsi86 driver.
> * @dev: Pointer to our device.
> @@ -673,6 +675,7 @@ static int ti_sn_link_training(struct ti_sn_bridge
> *pdata, int dp_rate_idx,
> {
> unsigned int val;
> int ret;
> + int i;
>
> /* set dp clk frequency value */
> regmap_update_bits(pdata->regmap, SN_DATARATE_CONFIG_REG,
> @@ -689,19 +692,34 @@ static int ti_sn_link_training(struct ti_sn_bridge
> *pdata, int dp_rate_idx,
> goto exit;
> }
>
> - /* Semi auto link training mode */
> - regmap_write(pdata->regmap, SN_ML_TX_MODE_REG, 0x0A);
> - ret = regmap_read_poll_timeout(pdata->regmap, SN_ML_TX_MODE_REG, val,
> -val == ML_TX_MAIN_LINK_OFF ||
> -val == ML_TX_NORMAL_MODE, 1000,
> -500 * 1000);
> - if (ret) {
> - *last_err_str = "Training complete polling failed";
> - } else if (val == ML_TX_MAIN_LINK_OFF) {
> - *last_err_str = "Link training failed, link is off";
> - ret = -EIO;
> + /*
> + * We'll try to link train several times. As part of link training
> + * the bridge chip will write DP_SET_POWER_D0 to DP_SET_POWER. If
> + * the panel isn't ready quite it might respond NAK here which means
> + * we need to try again.
> + */
> + for (i = 0; i < SN_LINK_TRAINING_TRIES; i++) {
> + /* Semi auto link training mode */
> + regmap_write(pdata->regmap, SN_ML_TX_MODE_REG, 0x0A);
> + ret = regmap_read_poll_timeout(pdata->regmap,
> SN_ML_TX_MODE_REG, val,
> + val == ML_TX_MAIN_LINK_OFF ||
> + val == ML_TX_NORMAL_MODE, 1000,
> + 500 * 1000);
> + if (ret) {
> + *last_err_str = "Training complete polling failed";
> + } else if (val == ML_TX_MAIN_LINK_OFF) {
> + *last_err_str = "Link training failed, link is off";
> + ret = -EIO;
> + continue;
> + }
> +
> + break;
> }
>
> + /* If we saw quite a few retries, add a note about it */
> + if (!ret && i > SN_LINK_TRAINING_TRIES / 2)
> + DRM_DEV_INFO(pdata->dev, "Link training needed %d retries\n",
> i);
> +
> exit:
> /* Disable the PLL if we failed */
> if (ret)
Apologies for the previous HTML email, I was trying a new mail client
and... will not be switching to it.
Anyway.. again, this time in text..
Tested on the Lenovo C630, and haven’t seen the message, although I
hadn’t seen the described issue before either.
Tested-By: Steev Klimaszewski
Re: [PATCH 1/2] dt-bindings: drm/bridge: ti-sn65dsi86: Replace #pwm-cells
On 9/30/20 5:35 PM, Bjorn Andersson wrote: > While the signal on GPIO4 to drive the backlight controller indeed is > pulse width modulated its purpose is specifically to control the > brightness of a backlight. > > Drop the #pwm-cells and instead expose a new property to configure the > granularity of the backlight PWM signal. > > Signed-off-by: Bjorn Andersson > --- > .../devicetree/bindings/display/bridge/ti,sn65dsi86.yaml | 9 ++--- > 1 file changed, 6 insertions(+), 3 deletions(-) > > diff --git > a/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.yaml > b/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.yaml > index f8622bd0f61e..e380218b4646 100644 > --- a/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.yaml > +++ b/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.yaml > @@ -66,9 +66,12 @@ properties: >1-based to match the datasheet. See ../../gpio/gpio.txt for more >information. > > - '#pwm-cells': > -const: 1 > -description: See ../../pwm/pwm.yaml for description of the cell formats. > + ti,backlight-scale: > +description: > + The granularity of brightness for the PWM signal provided on GPIO4, if > + this property is specified. > + minimum: 0 > +maximum: 65535 > >ports: > type: object Tested-By: Steev Klimaszewski
Re: [PATCH 2/2] drm/bridge: ti-sn65dsi86: Expose backlight controls
> + * value.
> + */
> + pre_div = 1200 / (500 * pdata->max_brightness) + 1;
> + regmap_write(pdata->regmap, SN_PWM_PRE_DIV_REG, pre_div);
> +
> + /* Enable PWM */
> + regmap_update_bits(pdata->regmap, SN_PWM_CTL_REG,
> SN_PWM_ENABLE, SN_PWM_ENABLE);
> + } else {
> + regmap_update_bits(pdata->regmap, SN_PWM_CTL_REG,
> SN_PWM_ENABLE, 0);
> + }
> +
> + return 0;
> +}
> +
> static int __maybe_unused ti_sn_bridge_resume(struct device *dev)
> {
> struct ti_sn_bridge *pdata = dev_get_drvdata(dev);
> @@ -193,7 +258,7 @@ static int __maybe_unused ti_sn_bridge_resume(struct
> device *dev)
>
> gpiod_set_value(pdata->enable_gpio, 1);
>
> - return ret;
> + return ti_sn_backlight_update(pdata);
> }
>
> static int __maybe_unused ti_sn_bridge_suspend(struct device *dev)
> @@ -1010,7 +1075,7 @@ static int ti_sn_bridge_gpio_direction_input(struct
> gpio_chip *chip,
>unsigned int offset)
> {
> struct ti_sn_bridge *pdata = gpiochip_get_data(chip);
> - int shift = offset * 2;
> + int shift = SN_GPIO_MUX_SHIFT(offset);
> int ret;
>
> if (!test_and_clear_bit(offset, pdata->gchip_output))
> @@ -1038,7 +1103,7 @@ static int ti_sn_bridge_gpio_direction_output(struct
> gpio_chip *chip,
> unsigned int offset, int val)
> {
> struct ti_sn_bridge *pdata = gpiochip_get_data(chip);
> - int shift = offset * 2;
> + int shift = SN_GPIO_MUX_SHIFT(offset);
> int ret;
>
> if (test_and_set_bit(offset, pdata->gchip_output))
> @@ -1073,12 +1138,17 @@ static const char * const
> ti_sn_bridge_gpio_names[SN_NUM_GPIOS] = {
>
> static int ti_sn_setup_gpio_controller(struct ti_sn_bridge *pdata)
> {
> + int ngpio = SN_NUM_GPIOS;
> int ret;
>
> /* Only init if someone is going to use us as a GPIO controller */
> if (!of_property_read_bool(pdata->dev->of_node, "gpio-controller"))
> return 0;
>
> + /* If GPIO4 is used for backlight, reduce number of gpios */
> + if (pdata->max_brightness)
> + ngpio--;
> +
> pdata->gchip.label = dev_name(pdata->dev);
> pdata->gchip.parent = pdata->dev;
> pdata->gchip.owner = THIS_MODULE;
> @@ -1092,7 +1162,7 @@ static int ti_sn_setup_gpio_controller(struct
> ti_sn_bridge *pdata)
> pdata->gchip.set = ti_sn_bridge_gpio_set;
> pdata->gchip.can_sleep = true;
> pdata->gchip.names = ti_sn_bridge_gpio_names;
> - pdata->gchip.ngpio = SN_NUM_GPIOS;
> + pdata->gchip.ngpio = ngpio;
> pdata->gchip.base = -1;
> ret = devm_gpiochip_add_data(pdata->dev, >gchip, pdata);
> if (ret)
> @@ -1159,6 +1229,65 @@ static void ti_sn_bridge_parse_lanes(struct
> ti_sn_bridge *pdata,
> pdata->ln_polrs = ln_polrs;
> }
>
> +static int ti_sn_backlight_update_status(struct backlight_device *bl)
> +{
> + struct ti_sn_bridge *pdata = bl_get_data(bl);
> + int brightness = bl->props.brightness;
> +
> + if (bl->props.power != FB_BLANK_UNBLANK ||
> + bl->props.fb_blank != FB_BLANK_UNBLANK ||
> + bl->props.state & BL_CORE_FBBLANK) {
> + pdata->brightness = 0;
> + }
> +
> + pdata->brightness = brightness;
> +
> + return ti_sn_backlight_update(pdata);
> +}
> +
> +static int ti_sn_backlight_get_brightness(struct backlight_device *bl)
> +{
> + struct ti_sn_bridge *pdata = bl_get_data(bl);
> + u16 val;
> +
> + ti_sn_bridge_read_u16(pdata, SN_BACKLIGHT_REG, );
> +
> + return val;
> +}
> +
> +const struct backlight_ops ti_sn_backlight_ops = {
> + .update_status = ti_sn_backlight_update_status,
> + .get_brightness = ti_sn_backlight_get_brightness,
> +};
> +
> +static int ti_sn_backlight_init(struct ti_sn_bridge *pdata)
> +{
> + struct backlight_properties props = {};
> + struct backlight_device *bl;
> + struct device *dev = pdata->dev;
> + struct device_node *np = dev->of_node;
> + int ret;
> +
> + ret = of_property_read_u32(np, "ti,backlight-scale",
> >max_brightness);
> + if (ret == -EINVAL) {
> + return 0;
> + } else if (ret || pdata->max_brightness >= 0x) {
> + DRM_ERROR("invalid max-brightness\n");
> + return -EINVAL;
> + }
> +
> + props.type = BACKLIGHT_RAW;
> + props.max_brightness = pdata->max_brightness;
> + bl = devm_backlight_device_register(dev, "sn65dsi86", dev, pdata,
> + _sn_backlight_ops, );
> + if (IS_ERR(bl)) {
> + DRM_ERROR("failed to register backlight device\n");
> + return PTR_ERR(bl);
> + }
> +
> + return 0;
> +}
> +
> static int ti_sn_bridge_probe(struct i2c_client *client,
> const struct i2c_device_id *id)
> {
> @@ -1224,6 +1353,12 @@ static int ti_sn_bridge_probe(struct i2c_client
> *client,
>
> pm_runtime_enable(pdata->dev);
>
> + ret = ti_sn_backlight_init(pdata);
> + if (ret) {
> + pm_runtime_disable(pdata->dev);
> + return ret;
> + }
> +
> ret = ti_sn_setup_gpio_controller(pdata);
> if (ret) {
> pm_runtime_disable(pdata->dev);
Tested-By: Steev Klimaszewski
Re: [PATCH] arm64: dts: sdm845: Fixup OPP table for all qup devices
On 9/14/20 4:53 PM, John Stultz wrote:
> On Mon, Sep 7, 2020 at 1:37 PM John Stultz wrote:
>> On Mon, Aug 31, 2020 at 9:04 PM John Stultz wrote:
>>> On Wed, Aug 12, 2020 at 3:23 AM Rajendra Nayak
>>> wrote:
>>>> This OPP table was based on the clock VDD-FMAX tables seen in
>>>> downstream code, however it turns out the downstream clock
>>>> driver does update these tables based on later/production
>>>> rev of the chip and whats seen in the tables belongs to an
>>>> early engineering rev of the SoC.
>>>> Fix up the OPP tables such that it now matches with the
>>>> production rev of sdm845 SoC.
>>>>
>>>> Fixes: 13cadb34e593 ("arm64: dts: sdm845: Add OPP table for all qup
>>>> devices")
>>>> Reported-by: John Stultz
>>>> Signed-off-by: Rajendra Nayak
>>>> ---
>>> Just wanted to follow up on this, as it's still missing from 5.9-rc3
>>> and is needed to fix a bluetooth regression on db845c from 5.9-rc1.
>>>
>>> Amit has already validated it (on PocoF1 as well), but just in case its
>>> useful:
>>> Tested-by: John Stultz
>> Hey Everyone,
>> Just wanted to nag folks on this again as it is still missing from
>> upstream and resolves a bluetooth regression from 5.9-rc1.
> Hey Everyone,
> Just your weekly nag on this patch that is still missing upstream.
> This patch fixes bluetooth regressions that started w/ 5.9-rc1. It
> would be great to see it land before 5.9 is finalized.
>
> thanks
> -john
Also tested that this fixes it for the Lenovo Yoga C630
Tested-By: Steev Klimaszewski
Re: [PATCH v2 0/4] remoteproc: Improvement for the Qualcomm sysmon
On 11/4/20 10:50 PM, Bjorn Andersson wrote: > The core part of this series is the update to the sysmon driver to ensure that > notifications sent to the remote processor are consistent and always present > valid state transitions. > > In testing this I finally took the time to fix up the issue of the SMP2P based > graceful shutdown in the remoteproc drivers always timing out if sysmon has > already successfully shut down the remote processor. > > Bjorn Andersson (4): > remoteproc: sysmon: Ensure remote notification ordering > remoteproc: sysmon: Expose the shutdown result > remoteproc: qcom: q6v5: Query sysmon before graceful shutdown > remoteproc: sysmon: Improve error messages > > drivers/remoteproc/qcom_common.h| 6 ++ > drivers/remoteproc/qcom_q6v5.c | 8 +- > drivers/remoteproc/qcom_q6v5.h | 3 +- > drivers/remoteproc/qcom_q6v5_adsp.c | 2 +- > drivers/remoteproc/qcom_q6v5_mss.c | 2 +- > drivers/remoteproc/qcom_q6v5_pas.c | 2 +- > drivers/remoteproc/qcom_q6v5_wcss.c | 2 +- > drivers/remoteproc/qcom_sysmon.c| 121 +--- > 8 files changed, 109 insertions(+), 37 deletions(-) > Entire series tested on Lenovo Yoga C630 Tested-by: Steev Klimaszewski
Re: [PATCH v5 0/3] iommu/arm-smmu-qcom: Support maintaining bootloader mappings
On 10/19/20 1:23 PM, Bjorn Andersson wrote: > This is the revised fourth attempt of inheriting the stream mapping for > the framebuffer on many Qualcomm platforms, in order to not hit > catastrophic faults during arm-smmu initialization. > > The new approach does, based on Robin's suggestion, take a much more > direct approach with the allocation of a context bank for bypass > emulation and use of this context bank pretty much isolated to the > Qualcomm specific implementation. > > The patchset has been tested to boot DB845c and RB5 (with splash screen) > and Lenovo Yoga C630 (with EFI framebuffer). > > Bjorn Andersson (3): > iommu/arm-smmu: Allow implementation specific write_s2cr > iommu/arm-smmu-qcom: Read back stream mappings > iommu/arm-smmu-qcom: Implement S2CR quirk > > drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c | 90 ++ > drivers/iommu/arm/arm-smmu/arm-smmu.c | 13 +++- > drivers/iommu/arm/arm-smmu/arm-smmu.h | 1 + > 3 files changed, 101 insertions(+), 3 deletions(-) > Tested series here on my Lenovo C630. Tested-by: Steev Klimaszewski
Re: [PATCH v2] venus: venc: Fix setting of profile and level
On 10/27/20 4:19 AM, Stanimir Varbanov wrote:
> The profile and level in op_set_ctrl was recently changed but during
> v4l2_ctrl_handler_setup profile and level control values are mangled.
>
> Fixes: 435c53c3698f ("media: venus: venc: Use helper to set profile and
> level")
> Signed-off-by: Stanimir Varbanov
> ---
>
> v2: Fixed kernel test robot WARNING
>
> drivers/media/platform/qcom/venus/core.h | 15 +++--
> drivers/media/platform/qcom/venus/venc.c | 31 ++-
> .../media/platform/qcom/venus/venc_ctrls.c| 14 +++--
> 3 files changed, 55 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/media/platform/qcom/venus/core.h
> b/drivers/media/platform/qcom/venus/core.h
> index 7b79a33dc9d6..05c9fbd51f0c 100644
> --- a/drivers/media/platform/qcom/venus/core.h
> +++ b/drivers/media/platform/qcom/venus/core.h
> @@ -243,8 +243,19 @@ struct venc_controls {
>
> u32 header_mode;
>
> - u32 profile;
> - u32 level;
> + struct {
> + u32 h264;
> + u32 mpeg4;
> + u32 hevc;
> + u32 vp8;
> + u32 vp9;
> + } profile;
> + struct {
> + u32 h264;
> + u32 mpeg4;
> + u32 hevc;
> + u32 vp9;
> + } level;
> };
>
> struct venus_buffer {
> diff --git a/drivers/media/platform/qcom/venus/venc.c
> b/drivers/media/platform/qcom/venus/venc.c
> index f8b1484e7dcd..47246528ac7e 100644
> --- a/drivers/media/platform/qcom/venus/venc.c
> +++ b/drivers/media/platform/qcom/venus/venc.c
> @@ -537,6 +537,7 @@ static int venc_set_properties(struct venus_inst *inst)
> struct hfi_quantization quant;
> struct hfi_quantization_range quant_range;
> u32 ptype, rate_control, bitrate;
> + u32 profile, level;
> int ret;
>
> ret = venus_helper_set_work_mode(inst, VIDC_WORK_MODE_2);
> @@ -684,7 +685,35 @@ static int venc_set_properties(struct venus_inst *inst)
> if (ret)
> return ret;
>
> - ret = venus_helper_set_profile_level(inst, ctr->profile, ctr->level);
> + switch (inst->hfi_codec) {
> + case HFI_VIDEO_CODEC_H264:
> + profile = ctr->profile.h264;
> + level = ctr->level.h264;
> + break;
> + case HFI_VIDEO_CODEC_MPEG4:
> + profile = ctr->profile.mpeg4;
> + level = ctr->level.mpeg4;
> + break;
> + case HFI_VIDEO_CODEC_VP8:
> + profile = ctr->profile.vp8;
> + level = 0;
> + break;
> + case HFI_VIDEO_CODEC_VP9:
> + profile = ctr->profile.vp9;
> + level = ctr->level.vp9;
> + break;
> + case HFI_VIDEO_CODEC_HEVC:
> + profile = ctr->profile.hevc;
> + level = ctr->level.hevc;
> + break;
> + case HFI_VIDEO_CODEC_MPEG2:
> + default:
> + profile = 0;
> + level = 0;
> + break;
> + }
> +
> + ret = venus_helper_set_profile_level(inst, profile, level);
> if (ret)
> return ret;
>
> diff --git a/drivers/media/platform/qcom/venus/venc_ctrls.c
> b/drivers/media/platform/qcom/venus/venc_ctrls.c
> index 0708b3b89d0c..cf860e6446c0 100644
> --- a/drivers/media/platform/qcom/venus/venc_ctrls.c
> +++ b/drivers/media/platform/qcom/venus/venc_ctrls.c
> @@ -103,15 +103,25 @@ static int venc_op_s_ctrl(struct v4l2_ctrl *ctrl)
> ctr->h264_entropy_mode = ctrl->val;
> break;
> case V4L2_CID_MPEG_VIDEO_MPEG4_PROFILE:
> + ctr->profile.mpeg4 = ctrl->val;
> + break;
> case V4L2_CID_MPEG_VIDEO_H264_PROFILE:
> + ctr->profile.h264 = ctrl->val;
> + break;
> case V4L2_CID_MPEG_VIDEO_HEVC_PROFILE:
> + ctr->profile.hevc = ctrl->val;
> + break;
> case V4L2_CID_MPEG_VIDEO_VP8_PROFILE:
> - ctr->profile = ctrl->val;
> + ctr->profile.vp8 = ctrl->val;
> break;
> case V4L2_CID_MPEG_VIDEO_MPEG4_LEVEL:
> + ctr->level.mpeg4 = ctrl->val;
> + break;
> case V4L2_CID_MPEG_VIDEO_H264_LEVEL:
> + ctr->level.h264 = ctrl->val;
> + break;
> case V4L2_CID_MPEG_VIDEO_HEVC_LEVEL:
> - ctr->level = ctrl->val;
> + ctr->level.hevc = ctrl->val;
> break;
> case V4L2_CID_MPEG_VIDEO_H264_I_FRAME_QP:
> ctr->h264_i_qp = ctrl->val;
Hi Stanimir,
When I apply this patch on top of my 5.10rc1 tree - (
https://github.com/steev/linux/commits/c630-5.10-rc1... my c630 no
longer boots. Unfortunately... nothing shows up in the logs, and I have
no idea how to get debug output from the c630.
-- Steev
Re: [PATCH] arm64: dts: qcom: c630: Define eDP bridge and panel
On 11/27/20 9:42 PM, Bjorn Andersson wrote:
> The Lenovo Yoga C630 drives the Boe NV133FHM-N61 eDP display from DSI
> using a TI SN65DSI86 bridge chip on I2C 10. Define the bridge and eDP
> panel and enable the display blocks.
>
> Signed-off-by: Bjorn Andersson
> ---
> .../boot/dts/qcom/sdm850-lenovo-yoga-c630.dts | 100 ++
> 1 file changed, 100 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/sdm850-lenovo-yoga-c630.dts
> b/arch/arm64/boot/dts/qcom/sdm850-lenovo-yoga-c630.dts
> index f956dbf664c1..bdd5d92ee6c3 100644
> --- a/arch/arm64/boot/dts/qcom/sdm850-lenovo-yoga-c630.dts
> +++ b/arch/arm64/boot/dts/qcom/sdm850-lenovo-yoga-c630.dts
> @@ -44,6 +44,26 @@ mode {
> linux,code = ;
> };
> };
> +
> + panel {
> + compatible = "boe,nv133fhm-n61";
> + no-hpd;
> +
> + ports {
> + port {
> + panel_in_edp: endpoint {
> + remote-endpoint = <_out>;
> + };
> + };
> + };
> + };
> +
> + sn65dsi86_refclk: sn65dsi86-refclk {
> + compatible = "fixed-clock";
> + #clock-cells = <0>;
> +
> + clock-frequency = <1920>;
> + };
> };
>
> _pas {
> @@ -260,6 +280,25 @@ _pas {
> status = "okay";
> };
>
> + {
> + status = "okay";
> + vdda-supply = <_l26a_1p2>;
> +
> + ports {
> + port@1 {
> + endpoint {
> + remote-endpoint = <_in_a>;
> + data-lanes = <0 1 2 3>;
> + };
> + };
> + };
> +};
> +
> +_phy {
> + status = "okay";
> + vdds-supply = <_l1a_0p875>;
> +};
> +
> {
> protected-clocks = ,
> ,
> @@ -328,6 +367,45 @@ tsc1: hid@10 {
> };
> };
>
> + {
> + status = "okay";
> + clock-frequency = <40>;
> +
> + sn65dsi86: bridge@2c {
> + compatible = "ti,sn65dsi86";
> + reg = <0x2c>;
> + pinctrl-names = "default";
> + pinctrl-0 = <_pin_active>;
> +
> + enable-gpios = < 96 GPIO_ACTIVE_HIGH>;
> +
> + vpll-supply = <_l14a_1p88>;
> + vccio-supply = <_l14a_1p88>;
> +
> + clocks = <_refclk>;
> + clock-names = "refclk";
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + reg = <0>;
> + sn65dsi86_in_a: endpoint {
> + remote-endpoint = <_out>;
> + };
> + };
> +
> + port@1 {
> + reg = <1>;
> + sn65dsi86_out: endpoint {
> + remote-endpoint = <_in_edp>;
> + };
> + };
> + };
> + };
> +};
> +
> {
> status = "okay";
> clock-frequency = <40>;
> @@ -344,10 +422,26 @@ ecsh: hid@5c {
> };
> };
>
> + {
> + status = "okay";
> +};
> +
> +_mdp {
> + status = "okay";
> +};
> +
> _pil {
> firmware-name = "qcom/LENOVO/81JL/qcdsp1v2850.mbn",
> "qcom/LENOVO/81JL/qcdsp2850.mbn";
> };
>
> +_i2c10_default {
> + pinconf {
> + pins = "gpio55", "gpio56";
> + drive-strength = <2>;
> + bias-disable;
> + };
> +};
> +
> _i2c12_default {
> drive-strength = <2>;
> bias-disable;
> @@ -454,6 +548,12 @@ codec {
> {
> gpio-reserved-ranges = <0 4>, <81 4>;
>
> + sn65dsi86_pin_active: sn65dsi86-enable {
> + pins = "gpio96";
> + drive-strength = <2>;
> + bias-disable;
> + };
> +
> i2c3_hid_active: i2c2-hid-active {
> pins = "gpio37";
> function = "gpio";
Tested-by: Steev Klimaszewski
Re: [PATCH] arm64: dts: qcom: c630: Expose LID events
On 11/25/20 12:08 AM, Bjorn Andersson wrote:
> The LID state can be read from GPIO 124 and the "tablet mode" from GPIO
> 95, expose these to the system using gpio-keys and mark the falling edge
> of the LID state as a wakeup-source - to wake the system from suspend.
>
> Signed-off-by: Bjorn Andersson
> ---
> .../boot/dts/qcom/sdm850-lenovo-yoga-c630.dts | 39 +++
> 1 file changed, 39 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/sdm850-lenovo-yoga-c630.dts
> b/arch/arm64/boot/dts/qcom/sdm850-lenovo-yoga-c630.dts
> index bb314973eb0c..f956dbf664c1 100644
> --- a/arch/arm64/boot/dts/qcom/sdm850-lenovo-yoga-c630.dts
> +++ b/arch/arm64/boot/dts/qcom/sdm850-lenovo-yoga-c630.dts
> @@ -8,6 +8,8 @@
> /dts-v1/;
>
> #include
> +#include
> +#include
> #include
> #include
> #include
> @@ -21,6 +23,27 @@ / {
> aliases {
> hsuart0 =
> };
> +
> + gpio-keys {
> + compatible = "gpio-keys";
> +
> + pinctrl-names = "default";
> + pinctrl-0 = <_pin_active>, <_pin_active>;
> +
> + lid {
> + gpios = < 124 GPIO_ACTIVE_HIGH>;
> + linux,input-type = ;
> + linux,code = ;
> + wakeup-source;
> + wakeup-event-action = ;
> + };
> +
> + mode {
> + gpios = < 95 GPIO_ACTIVE_HIGH>;
> + linux,input-type = ;
> + linux,code = ;
> + };
> + };
> };
>
> _pas {
> @@ -466,6 +489,22 @@ wcd_intr_default: wcd_intr_default {
> bias-pull-down;
> drive-strength = <2>;
> };
> +
> + lid_pin_active: lid-pin {
> + pins = "gpio124";
> + function = "gpio";
> +
> + input-enable;
> + bias-disable;
> + };
> +
> + mode_pin_active: mode-pin {
> + pins = "gpio95";
> + function = "gpio";
> +
> + input-enable;
> + bias-disable;
> + };
> };
>
> {
Tested-by: Steev Klimaszewski
Re: [PATCH] Revert "i2c: qcom-geni: Disable DMA processing on the Lenovo Yoga C630"
On 11/24/20 12:57 PM, Bjorn Andersson wrote:
> A combination of recent bug fixes by Doug Anderson and the proper
> definition of iommu streams means that this hack is no longer needed.
> Let's clean up the code by reverting '127068abe85b ("i2c: qcom-geni:
> Disable DMA processing on the Lenovo Yoga C630")'.
>
> Signed-off-by: Bjorn Andersson
> ---
> drivers/i2c/busses/i2c-qcom-geni.c | 12
> 1 file changed, 4 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/i2c/busses/i2c-qcom-geni.c
> b/drivers/i2c/busses/i2c-qcom-geni.c
> index dce75b85253c..046d241183c5 100644
> --- a/drivers/i2c/busses/i2c-qcom-geni.c
> +++ b/drivers/i2c/busses/i2c-qcom-geni.c
> @@ -353,13 +353,11 @@ static int geni_i2c_rx_one_msg(struct geni_i2c_dev
> *gi2c, struct i2c_msg *msg,
> {
> dma_addr_t rx_dma;
> unsigned long time_left;
> - void *dma_buf = NULL;
> + void *dma_buf;
> struct geni_se *se = >se;
> size_t len = msg->len;
>
> - if (!of_machine_is_compatible("lenovo,yoga-c630"))
> - dma_buf = i2c_get_dma_safe_msg_buf(msg, 32);
> -
> + dma_buf = i2c_get_dma_safe_msg_buf(msg, 32);
> if (dma_buf)
> geni_se_select_mode(se, GENI_SE_DMA);
> else
> @@ -394,13 +392,11 @@ static int geni_i2c_tx_one_msg(struct geni_i2c_dev
> *gi2c, struct i2c_msg *msg,
> {
> dma_addr_t tx_dma;
> unsigned long time_left;
> - void *dma_buf = NULL;
> + void *dma_buf;
> struct geni_se *se = >se;
> size_t len = msg->len;
>
> - if (!of_machine_is_compatible("lenovo,yoga-c630"))
> - dma_buf = i2c_get_dma_safe_msg_buf(msg, 32);
> -
> + dma_buf = i2c_get_dma_safe_msg_buf(msg, 32);
> if (dma_buf)
> geni_se_select_mode(se, GENI_SE_DMA);
> else
Tested-by: Steev Klimaszewski
Re: [PATCH] arm64: dts: qcom: c630: Re-enable apps_smmu
On 11/24/20 12:44 PM, Bjorn Andersson wrote:
> Re-enable the apps_smmu now that the arm-smmu driver supports stream
> mapping handoff from firmware.
>
> Signed-off-by: Bjorn Andersson
> ---
> arch/arm64/boot/dts/qcom/sdm850-lenovo-yoga-c630.dts | 5 -
> 1 file changed, 5 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/qcom/sdm850-lenovo-yoga-c630.dts
> b/arch/arm64/boot/dts/qcom/sdm850-lenovo-yoga-c630.dts
> index d03ca3190746..f5b98845fa90 100644
> --- a/arch/arm64/boot/dts/qcom/sdm850-lenovo-yoga-c630.dts
> +++ b/arch/arm64/boot/dts/qcom/sdm850-lenovo-yoga-c630.dts
> @@ -232,11 +232,6 @@ vreg_lvs2a_1p8: lvs2 {
> };
> };
>
> -_smmu {
> - /* TODO: Figure out how to survive booting with this enabled */
> - status = "disabled";
> -};
> -
> _pas {
> firmware-name = "qcom/LENOVO/81JL/qccdsp850.mbn";
> status = "okay";
Tested-by: Steev Klimaszewski
Re: [PATCH v4 2/2] ASoC: qcom: Add support for playback recover after resume
On 11/27/20 10:59 PM, Srinivasa Rao Mandadapu wrote:
> To support playback continuation after hard suspend(bypass powerd)
> and resume add component driver ops and do regcache sync.
>
> Signed-off-by: V Sujith Kumar Reddy
> Signed-off-by: Srinivasa Rao Mandadapu
> ---
> sound/soc/qcom/lpass-platform.c | 35 +++
> 1 file changed, 35 insertions(+)
>
> diff --git a/sound/soc/qcom/lpass-platform.c b/sound/soc/qcom/lpass-platform.c
> index 0e71899..12764a8 100644
> --- a/sound/soc/qcom/lpass-platform.c
> +++ b/sound/soc/qcom/lpass-platform.c
> @@ -827,6 +827,39 @@ static void lpass_platform_pcm_free(struct
> snd_soc_component *component,
> }
> }
>
> +static int lpass_platform_pcmops_suspend(struct snd_soc_component *component)
> +{
> + struct lpass_data *drvdata = snd_soc_component_get_drvdata(component);
> + struct regmap *map;
> + unsigned int dai_id = component->id;
> +
> + if (dai_id == LPASS_DP_RX)
> + map = drvdata->hdmiif_map;
> + else
> + map = drvdata->lpaif_map;
> +
> + regcache_cache_only(map, true);
> + regcache_mark_dirty(map);
> +
> + return 0;
> +}
> +
> +static int lpass_platform_pcmops_resume(struct snd_soc_component *component)
> +{
> + struct lpass_data *drvdata = snd_soc_component_get_drvdata(component);
> + struct regmap *map;
> + unsigned int dai_id = component->id;
> +
> + if (dai_id == LPASS_DP_RX)
> + map = drvdata->hdmiif_map;
> + else
> + map = drvdata->lpaif_map;
> +
> + regcache_cache_only(map, false);
> + return regcache_sync(map);
> +}
> +
> +
> static const struct snd_soc_component_driver lpass_component_driver = {
> .name = DRV_NAME,
> .open = lpass_platform_pcmops_open,
> @@ -839,6 +872,8 @@ static const struct snd_soc_component_driver
> lpass_component_driver = {
> .mmap = lpass_platform_pcmops_mmap,
> .pcm_construct = lpass_platform_pcm_new,
> .pcm_destruct = lpass_platform_pcm_free,
> + .suspend = lpass_platform_pcmops_suspend,
> + .resume = lpass_platform_pcmops_resume,
>
> };
>
Tested this series on a Lenovo Yoga C630
Tested-by: Steev Klimaszewski
Re: [PATCH] arm64: defconfig: Enable QCOM_SCM as builtin
On 11/18/20 10:25 AM, Bjorn Andersson wrote: > The Qualcomm SCM driver was never explicitly enabled in the defconfig. > Instead it was (apparently) selected by DRM_MSM and by the recent change > to make it tristate now became =m. > > Unfortunately this removes the ability for PINCTRL_MSM and ARM_SMMU to > be =y and with deferred_probe_timeout defaulting to 0 this means that > things such as UART, USB, PCIe and SDHCI probes with their dependencies > ignored. > > The lack of pinctrl results in invalid pin configuration and the lack of > iommu results in the system locking up as soon as any form of data > transfer is attempted from any of the affected peripherals. > > Mark QCOM_SCM as builtin, to avoid this. > > Cc: John Stultz > Signed-off-by: Bjorn Andersson > --- > arch/arm64/configs/defconfig | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig > index d129340a7ed1..287ccf98dc41 100644 > --- a/arch/arm64/configs/defconfig > +++ b/arch/arm64/configs/defconfig > @@ -99,6 +99,7 @@ CONFIG_ARM_SCPI_PROTOCOL=y > CONFIG_RASPBERRYPI_FIRMWARE=y > CONFIG_INTEL_STRATIX10_SERVICE=y > CONFIG_INTEL_STRATIX10_RSU=m > +CONFIG_QCOM_SCM=y > CONFIG_EFI_CAPSULE_LOADER=y > CONFIG_IMX_SCU=y > CONFIG_IMX_SCU_PD=y Tested-by: Steev Klimaszewski
Re: [PATCH] arm64: defconfig: Enable TMPFS Posix ACL
On 11/30/20 10:30 AM, Bjorn Andersson wrote: > The lack of TMPFS Posix ACL prevents the upstream defconfig from booting > e.g. Ubuntu, so enable this. > > Signed-off-by: Bjorn Andersson > --- > arch/arm64/configs/defconfig | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig > index f4d0b3a61e41..3d2a1de6e8d6 100644 > --- a/arch/arm64/configs/defconfig > +++ b/arch/arm64/configs/defconfig > @@ -1075,6 +1075,7 @@ CONFIG_FUSE_FS=m > CONFIG_CUSE=m > CONFIG_OVERLAY_FS=m > CONFIG_VFAT_FS=y > +CONFIG_TMPFS_POSIX_ACL=y > CONFIG_HUGETLBFS=y > CONFIG_CONFIGFS_FS=y > CONFIG_EFIVAR_FS=y Tested-by: Steev Klimaszewski
Re: [PATCH] arm64: defconfig: Enable HID multitouch
On 11/30/20 10:28 AM, Bjorn Andersson wrote: > The Lenovo Yoga C630 relies on HID multitouch support for proper > touchpad operation, so enable this. > > Signed-off-by: Bjorn Andersson > --- > arch/arm64/configs/defconfig | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig > index 8e3ed05b655a..f4d0b3a61e41 100644 > --- a/arch/arm64/configs/defconfig > +++ b/arch/arm64/configs/defconfig > @@ -737,6 +737,7 @@ CONFIG_SND_SOC_WM8904=m > CONFIG_SND_SOC_WSA881X=m > CONFIG_SND_SIMPLE_CARD=m > CONFIG_SND_AUDIO_GRAPH_CARD=m > +CONFIG_HID_MULTITOUCH=m > CONFIG_I2C_HID=m > CONFIG_USB_CONN_GPIO=m > CONFIG_USB=y Tested-by: Steev Klimaszewski
Re: [PATCH] arm64: defconfig: Enable Qualcomm PON driver
On 11/24/20 8:38 PM, Bjorn Andersson wrote: > The PON block in the PMIC provides, among other things, support for > "reboot reason", power key and reset "key" handling. Let's enable the > driver for this block. > > Signed-off-by: Bjorn Andersson > --- > arch/arm64/configs/defconfig | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig > index c9246f51085f..8e3ed05b655a 100644 > --- a/arch/arm64/configs/defconfig > +++ b/arch/arm64/configs/defconfig > @@ -521,6 +521,7 @@ CONFIG_POWER_AVS=y > CONFIG_QCOM_CPR=y > CONFIG_ROCKCHIP_IODOMAIN=y > CONFIG_POWER_RESET_MSM=y > +CONFIG_POWER_RESET_QCOM_PON=m > CONFIG_POWER_RESET_XGENE=y > CONFIG_POWER_RESET_SYSCON=y > CONFIG_SYSCON_REBOOT_MODE=y Tested-by: Steev Klimaszewski
Re: [PATCH] arm64: dts: qcom: c630: Polish i2c-hid devices
On 11/30/20 10:59 AM, Bjorn Andersson wrote:
> The numbering of the i2c busses differs from ACPI and a number of typos
> was made in the original patch. Further more the irq flags for the
> various resources was not correct and i2c3 only has one of the two
> client devices active in any one device.
>
> Also label the various devices, for easier comparison with the ACPI
> tables.
>
> Fixes: 44acee207844 ("arm64: dts: qcom: Add Lenovo Yoga C630")
> Signed-off-by: Bjorn Andersson
> ---
> .../boot/dts/qcom/sdm850-lenovo-yoga-c630.dts | 31 +++
> 1 file changed, 18 insertions(+), 13 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/qcom/sdm850-lenovo-yoga-c630.dts
> b/arch/arm64/boot/dts/qcom/sdm850-lenovo-yoga-c630.dts
> index 047ac9c16874..399aef2a0951 100644
> --- a/arch/arm64/boot/dts/qcom/sdm850-lenovo-yoga-c630.dts
> +++ b/arch/arm64/boot/dts/qcom/sdm850-lenovo-yoga-c630.dts
> @@ -264,23 +264,28 @@ {
> status = "okay";
> clock-frequency = <40>;
>
> - hid@15 {
> + tsel: hid@15 {
> compatible = "hid-over-i2c";
> reg = <0x15>;
> hid-descr-addr = <0x1>;
>
> - interrupts-extended = < 37 IRQ_TYPE_EDGE_RISING>;
> + interrupts-extended = < 37 IRQ_TYPE_LEVEL_HIGH>;
> +
> + pinctrl-names = "default";
> + pinctrl-0 = <_hid_active>;
> };
>
> - hid@2c {
> + tsc2: hid@2c {
> compatible = "hid-over-i2c";
> reg = <0x2c>;
> hid-descr-addr = <0x20>;
>
> - interrupts-extended = < 37 IRQ_TYPE_EDGE_RISING>;
> + interrupts-extended = < 37 IRQ_TYPE_LEVEL_HIGH>;
>
> pinctrl-names = "default";
> - pinctrl-0 = <_hid_active>;
> + pinctrl-0 = <_hid_active>;
> +
> + status = "disabled";
> };
> };
>
> @@ -288,15 +293,15 @@ {
> status = "okay";
> clock-frequency = <40>;
>
> - hid@10 {
> + tsc1: hid@10 {
> compatible = "hid-over-i2c";
> reg = <0x10>;
> hid-descr-addr = <0x1>;
>
> - interrupts-extended = < 125 IRQ_TYPE_EDGE_FALLING>;
> + interrupts-extended = < 125 IRQ_TYPE_LEVEL_LOW>;
>
> pinctrl-names = "default";
> - pinctrl-0 = <_hid_active>;
> + pinctrl-0 = <_hid_active>;
> };
> };
>
> @@ -304,7 +309,7 @@ {
> status = "okay";
> clock-frequency = <40>;
>
> - hid@5c {
> + ecsh: hid@5c {
> compatible = "hid-over-i2c";
> reg = <0x5c>;
> hid-descr-addr = <0x1>;
> @@ -312,7 +317,7 @@ hid@5c {
> interrupts-extended = < 92 IRQ_TYPE_LEVEL_LOW>;
>
> pinctrl-names = "default";
> - pinctrl-0 = <_hid_active>;
> + pinctrl-0 = <_hid_active>;
> };
> };
>
> @@ -426,7 +431,7 @@ codec {
> {
> gpio-reserved-ranges = <0 4>, <81 4>;
>
> - i2c2_hid_active: i2c2-hid-active {
> + i2c3_hid_active: i2c2-hid-active {
> pins = <37>;
> function = "gpio";
>
> @@ -435,7 +440,7 @@ i2c2_hid_active: i2c2-hid-active {
> drive-strength = <2>;
> };
>
> - i2c6_hid_active: i2c6-hid-active {
> + i2c5_hid_active: i2c5-hid-active {
> pins = <125>;
> function = "gpio";
>
> @@ -444,7 +449,7 @@ i2c6_hid_active: i2c6-hid-active {
> drive-strength = <2>;
> };
>
> - i2c12_hid_active: i2c12-hid-active {
> + i2c11_hid_active: i2c11-hid-active {
> pins = <92>;
> function = "gpio";
>
Tested-by: Steev Klimaszewski
Re: [PATCH] arm64: dts: qcom: c630: Fix pinctrl pins properties
On 11/30/20 11:00 AM, Bjorn Andersson wrote:
> The "pins" property takes an array of pin _names_, not pin numbers. Fix
> this.
>
> Fixes: 44acee207844 ("arm64: dts: qcom: Add Lenovo Yoga C630")
> Signed-off-by: Bjorn Andersson
> ---
> arch/arm64/boot/dts/qcom/sdm850-lenovo-yoga-c630.dts | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/qcom/sdm850-lenovo-yoga-c630.dts
> b/arch/arm64/boot/dts/qcom/sdm850-lenovo-yoga-c630.dts
> index 399aef2a0951..bb314973eb0c 100644
> --- a/arch/arm64/boot/dts/qcom/sdm850-lenovo-yoga-c630.dts
> +++ b/arch/arm64/boot/dts/qcom/sdm850-lenovo-yoga-c630.dts
> @@ -432,7 +432,7 @@ {
> gpio-reserved-ranges = <0 4>, <81 4>;
>
> i2c3_hid_active: i2c2-hid-active {
> - pins = <37>;
> + pins = "gpio37";
> function = "gpio";
>
> input-enable;
> @@ -441,7 +441,7 @@ i2c3_hid_active: i2c2-hid-active {
> };
>
> i2c5_hid_active: i2c5-hid-active {
> - pins = <125>;
> + pins = "gpio125";
> function = "gpio";
>
> input-enable;
> @@ -450,7 +450,7 @@ i2c5_hid_active: i2c5-hid-active {
> };
>
> i2c11_hid_active: i2c11-hid-active {
> - pins = <92>;
> + pins = "gpio92";
> function = "gpio";
>
> input-enable;
> @@ -459,7 +459,7 @@ i2c11_hid_active: i2c11-hid-active {
> };
>
> wcd_intr_default: wcd_intr_default {
> - pins = <54>;
> + pins = "gpio54";
> function = "gpio";
>
> input-enable;
Tested-by: Steev Klimaszewski
Re: [PATCH v1 1/3] scsi: ufs: add write booster feature support
On 6/23/20 1:51 AM, Kyuho Choi wrote: > Hi Avri, > > On 6/23/20, Avri Altman wrote: >>> AFAIK, this device are ufs 2.1. It's not support writebooster. >>> >>> I'd check latest linux scsi branch and ufshcd_wb_config function's >>> called without device capability check. >> Please grep ufshcd_wb_probe. >> > I got your point, but as I mentioned, this device not support wb, this > is old products. > > I'm not sure ufshcd_wb_probe are called or not in Rob and Steev's platform. > If it's called, hba->caps are setted with wb diable and this error not > occured. > But (it looks) not called, same query error will be occured in > ufshcd_wb_config/ctrl. > > BR, > Kyuho Choi I do show ufshcd_wb_probe in my sources - I'm based on 5.8-rc2 with a few extra patches for the c630, and the inline encryption patches. I this is the output that I see - 1. [ 0.702501] ufshcd-qcom 1d84000.ufshc: ufshcd_populate_vreg: Unable to find vdd-hba-supply regulator, assuming enabled 2. [ 0.702506] ufshcd-qcom 1d84000.ufshc: ufshcd_populate_vreg: Unable to find vccq-supply regulator, assuming enabled 3. [ 0.702508] ufshcd-qcom 1d84000.ufshc: ufshcd_populate_vreg: Unable to find vccq2-supply regulator, assuming enabled 4. [ 0.703296] ufshcd-qcom 1d84000.ufshc: Found QC Inline Crypto Engine (ICE) v3.1.75 5. [ 0.705121] scsi host0: ufshcd 6. [ 0.720163] ALSA device list: 7. [ 0.720171] No soundcards found. 8. [ 0.731393] ufshcd-qcom 1d84000.ufshc: ufshcd_print_pwr_info:[RX, TX]: gear=[1, 1], lane[1, 1], pwr[SLOWAUTO_MODE, SLOWAUTO_MODE], rate = 0 9. [ 0.893738] ufshcd-qcom 1d84000.ufshc: ufshcd_print_pwr_info:[RX, TX]: gear=[3, 3], lane[2, 2], pwr[FAST MODE, FAST MODE], rate = 2 10. [ 0.894703] ufshcd-qcom 1d84000.ufshc: ufshcd_find_max_sup_active_icc_level: Regulator capability was not set, actvIccLevel=0 11. [ 0.896032] ufshcd-qcom 1d84000.ufshc: ufshcd_query_flag: Sending flag query for idn 14 failed, err = 253 12. [ 0.896919] ufshcd-qcom 1d84000.ufshc: ufshcd_query_flag: Sending flag query for idn 14 failed, err = 253 13. [ 0.897798] ufshcd-qcom 1d84000.ufshc: ufshcd_query_flag: Sending flag query for idn 14 failed, err = 253 14. [ 0.898227] ufshcd-qcom 1d84000.ufshc: ufshcd_query_flag_retry: query attribute, opcode 6, idn 14, failed with error 253 after 3 retires 15. [ 0.898798] ufshcd-qcom 1d84000.ufshc: ufshcd_wb_ctrl write booster enable failed 253 16. [ 0.899150] ufshcd-qcom 1d84000.ufshc: ufshcd_wb_config: Enable WB failed: 253 17. [ 0.899918] ufshcd-qcom 1d84000.ufshc: ufshcd_query_flag: Sending flag query for idn 16 failed, err = 253 18. [ 0.900448] ufshcd-qcom 1d84000.ufshc: ufshcd_query_flag: Sending flag query for idn 16 failed, err = 253 19. [ 0.901290] ufshcd-qcom 1d84000.ufshc: ufshcd_query_flag: Sending flag query for idn 16 failed, err = 253 20. [ 0.901749] ufshcd-qcom 1d84000.ufshc: ufshcd_query_flag_retry: query attribute, opcode 6, idn 16, failed with error 253 after 3 retires 21. [ 0.902285] ufshcd-qcom 1d84000.ufshc: ufshcd_wb_config: En WB flush during H8: failed: 253 22. [ 0.903105] ufshcd-qcom 1d84000.ufshc: ufshcd_query_flag: Sending flag query for idn 15 failed, err = 253 23. [ 0.903988] ufshcd-qcom 1d84000.ufshc: ufshcd_query_flag: Sending flag query for idn 15 failed, err = 253 24. [ 0.904866] ufshcd-qcom 1d84000.ufshc: ufshcd_query_flag: Sending flag query for idn 15 failed, err = 253 25. [ 0.905294] ufshcd-qcom 1d84000.ufshc: ufshcd_query_flag_retry: query attribute, opcode 6, idn 15, failed with error 253 after 3 retires 26. [ 0.905859] ufshcd-qcom 1d84000.ufshc: ufshcd_wb_buf_flush_enable WB - buf flush enable failed 253 27. [ 0.907659] scsi 0:0:0:49488: Well-known LUN SAMSUNG KLUDG4U1EA-B0C1 0500 PQ: 0 ANSI: 6 28. [ 0.911082] scsi 0:0:0:49476: Well-known LUN SAMSUNG KLUDG4U1EA-B0C1 0500 PQ: 0 ANSI: 6 29. [ 0.913268] scsi 0:0:0:49456: Well-known LUN SAMSUNG KLUDG4U1EA-B0C1 0500 PQ: 0 ANSI: 6 30. [ 0.914580] scsi 0:0:0:0: Direct-Access SAMSUNG KLUDG4U1EA-B0C1 0500 PQ: 0 ANSI: 6 31. [ 0.915156] sd 0:0:0:0: Power-on or device reset occurred 32. [ 0.915311] scsi 0:0:0:1: Direct-Access SAMSUNG KLUDG4U1EA-B0C1 0500 PQ: 0 ANSI: 6 33. [ 0.916104] scsi 0:0:0:2: Direct-Access SAMSUNG KLUDG4U1EA-B0C1 0500 PQ: 0 ANSI: 6 34. [ 0.916318] sd 0:0:0:0: [sda] 29765632 4096-byte logical blocks: (122 GB/114 GiB) 35. [ 0.916417] sd 0:0:0:0: [sda] Write Protect is off 36. [ 0.916424] sd 0:0:0:0: [sda] Mode Sense: 00 32 00 10 37. [ 0.916589] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, supports DPO and FUA 38. [ 0.916667] sd 0:0:0:0: [sda] Optimal transfer size 8192 bytes
Re: [PATCH v1 1/3] scsi: ufs: add write booster feature support
On 6/23/20 8:53 PM, Stanley Chu wrote: > Hi Steev, > > Please help try below simple patch to see if above WriteBooster messages > can be eliminated. > > > --- > drivers/scsi/ufs/ufshcd.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c > index f173ad1bd79f..089c0785f0b3 100644 > --- a/drivers/scsi/ufs/ufshcd.c > +++ b/drivers/scsi/ufs/ufshcd.c > @@ -6985,6 +6985,8 @@ static int ufs_get_device_desc(struct ufs_hba > *hba) > dev_info->wspecversion == 0x220 || > (hba->dev_quirks & UFS_DEVICE_QUIRK_SUPPORT_EXTENDED_FEATURES)) > ufshcd_wb_probe(hba, desc_buf); > + else > + hba->caps &= ~UFSHCD_CAP_WB_EN; > > /* >* ufshcd_read_string_desc returns size of the string Hi Stanley, That worked. 1. [ 0.704775] ufshcd-qcom 1d84000.ufshc: ufshcd_populate_vreg: Unable to find vdd-hba-supply regulator, assuming enabled 2. [ 0.704781] ufshcd-qcom 1d84000.ufshc: ufshcd_populate_vreg: Unable to find vccq-supply regulator, assuming enabled 3. [ 0.704783] ufshcd-qcom 1d84000.ufshc: ufshcd_populate_vreg: Unable to find vccq2-supply regulator, assuming enabled 4. [ 0.705618] ufshcd-qcom 1d84000.ufshc: Found QC Inline Crypto Engine (ICE) v3.1.75 5. [ 0.707496] scsi host0: ufshcd 6. [ 0.720415] ALSA device list: 7. [ 0.720422] No soundcards found. 8. [ 0.734245] ufshcd-qcom 1d84000.ufshc: ufshcd_print_pwr_info:[RX, TX]: gear=[1, 1], lane[1, 1], pwr[SLOWAUTO_MODE, SLOWAUTO_MODE], rate = 0 9. [ 0.845159] ufshcd-qcom 1d84000.ufshc: ufshcd_print_pwr_info:[RX, TX]: gear=[3, 3], lane[2, 2], pwr[FAST MODE, FAST MODE], rate = 2 10. [ 0.846399] ufshcd-qcom 1d84000.ufshc: ufshcd_find_max_sup_active_icc_level: Regulator capability was not set, actvIccLevel=0 11. [ 0.849258] scsi 0:0:0:49488: Well-known LUN SAMSUNG KLUDG4U1EA-B0C1 0500 PQ: 0 ANSI: 6 12. [ 0.853372] scsi 0:0:0:49476: Well-known LUN SAMSUNG KLUDG4U1EA-B0C1 0500 PQ: 0 ANSI: 6 13. [ 0.855135] scsi 0:0:0:49456: Well-known LUN SAMSUNG KLUDG4U1EA-B0C1 0500 PQ: 0 ANSI: 6 14. [ 0.857050] scsi 0:0:0:0: Direct-Access SAMSUNG KLUDG4U1EA-B0C1 0500 PQ: 0 ANSI: 6 15. [ 0.858297] sd 0:0:0:0: Power-on or device reset occurred 16. [ 0.859985] scsi 0:0:0:1: Direct-Access SAMSUNG KLUDG4U1EA-B0C1 0500 PQ: 0 ANSI: 6 17. [ 0.860702] sd 0:0:0:0: [sda] 29765632 4096-byte logical blocks: (122 GB/114 GiB) (full dmesg output at https://pastebin.com/Pvfqe42P ) I guess you can throw my Tested-by on there. Thanks --Steev
Re: [PATCH] drm/msm/dpu: fix/enable 6bpc dither with split-lm
Hi,
On 7/15/20 5:19 PM, Rob Clark wrote:
> From: Rob Clark
>
> If split-lm is used (for ex, on sdm845), we can have multiple ping-
> pongs, but only a single phys encoder. We need to configure dithering
> on each of them.
>
> Signed-off-by: Rob Clark
> ---
> drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 22 ++-
> .../gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.c | 3 +--
> 2 files changed, 13 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> index 46df0ff75b85..9b98b63c77fb 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> @@ -212,14 +212,14 @@ static u32 dither_matrix[DITHER_MATRIX_SZ] = {
> 15, 7, 13, 5, 3, 11, 1, 9, 12, 4, 14, 6, 0, 8, 2, 10
> };
>
> -static void _dpu_encoder_setup_dither(struct dpu_encoder_phys *phys)
> +static void _dpu_encoder_setup_dither(struct dpu_hw_pingpong *hw_pp,
> unsigned bpc)
> {
> struct dpu_hw_dither_cfg dither_cfg = { 0 };
>
> - if (!phys->hw_pp || !phys->hw_pp->ops.setup_dither)
> + if (!hw_pp->ops.setup_dither)
> return;
>
> - switch (phys->connector->display_info.bpc) {
> + switch (bpc) {
> case 6:
> dither_cfg.c0_bitdepth = 6;
> dither_cfg.c1_bitdepth = 6;
> @@ -228,14 +228,14 @@ static void _dpu_encoder_setup_dither(struct
> dpu_encoder_phys *phys)
> dither_cfg.temporal_en = 0;
> break;
> default:
> - phys->hw_pp->ops.setup_dither(phys->hw_pp, NULL);
> + hw_pp->ops.setup_dither(hw_pp, NULL);
> return;
> }
>
> memcpy(_cfg.matrix, dither_matrix,
> sizeof(u32) * DITHER_MATRIX_SZ);
>
> - phys->hw_pp->ops.setup_dither(phys->hw_pp, _cfg);
> + hw_pp->ops.setup_dither(hw_pp, _cfg);
> }
>
> void dpu_encoder_helper_report_irq_timeout(struct dpu_encoder_phys *phys_enc,
> @@ -1132,11 +1132,13 @@ static void _dpu_encoder_virt_enable_helper(struct
> drm_encoder *drm_enc)
>
> _dpu_encoder_update_vsync_source(dpu_enc, _enc->disp_info);
>
> - if (dpu_enc->disp_info.intf_type == DRM_MODE_ENCODER_DSI) {
> - for (i = 0; i < dpu_enc->num_phys_encs; i++) {
> - struct dpu_encoder_phys *phys = dpu_enc->phys_encs[i];
> -
> - _dpu_encoder_setup_dither(phys);
> + if (dpu_enc->disp_info.intf_type == DRM_MODE_ENCODER_DSI &&
> + !WARN_ON(dpu_enc->num_phys_encs == 0)) {
> + unsigned bpc =
> dpu_enc->phys_encs[0]->connector->display_info.bpc;
> + for (i = 0; i < MAX_CHANNELS_PER_ENC; i++) {
> + if (!dpu_enc->hw_pp[i])
> + continue;
> + _dpu_encoder_setup_dither(dpu_enc->hw_pp[i], bpc);
> }
> }
> }
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.c
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.c
> index 7411ab6bf6af..bea4ab5c58c5 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.c
> @@ -231,8 +231,7 @@ static void _setup_pingpong_ops(struct dpu_hw_pingpong *c,
> c->ops.poll_timeout_wr_ptr = dpu_hw_pp_poll_timeout_wr_ptr;
> c->ops.get_line_count = dpu_hw_pp_get_line_count;
>
> - if (test_bit(DPU_PINGPONG_DITHER, ) &&
> - IS_SC7180_TARGET(c->hw.hwversion))
> + if (test_bit(DPU_PINGPONG_DITHER, ))
> c->ops.setup_dither = dpu_hw_pp_setup_dither;
> };
Sorry for taking so long to get around to testing this. I was able to
today, and it does reduce the banding to be less noticeable.
Tested-by: Steev Klimaszewski
Thanks!
-- steev
Re: [PATCH v2] arm64: dts: qcom: sdm845: Add cpu OPP tables
On 7/2/20 3:46 PM, Sibi Sankar wrote: > Add OPP tables required to scale DDR/L3 per freq-domain on SDM845 SoCs. > > Signed-off-by: Sibi Sankar > --- Hi Sibi, Bjorn asked me to give this patch a whirl, and I have to say, I like it but I'm not sure if I'm missing a dependency somewhere... In 5.8.0-rc4, I'm seeing a couple probe defers [ 0.131341] cpu cpu0: _allocate_opp_table: Error finding interconnect paths: -517 [ 0.132694] cpu cpu4: _allocate_opp_table: Error finding interconnect paths: -517 And then a bit later on, [ 0.625837] cpu cpu0: failed to get clock: -2 If these aren't anything to worry about, you can throw my Tested-by on Tested-by: Steev Klimaszewski
Re: [PATCH v3 6/9] drm/bridge: ti-sn65dsi86: Use 18-bit DP if we can
On 7/9/20 9:14 PM, Doug Anderson wrote:
Hi,
On Thu, Jul 9, 2020 at 6:38 PM Doug Anderson wrote:
Hi,
On Thu, Jul 9, 2020 at 6:19 PM Steev Klimaszewski wrote:
Hi Doug,
I've been testing 5.8 and linux-next on the Lenovo Yoga C630, and with this
patch applied, there is really bad banding on the display.
I'm really bad at explaining it, but you can see the differences in the
following:
24bit (pre-5.8) - https://dev.gentoo.org/~steev/files/image0.jpg
18bit (5.8/linux-next) - https://dev.gentoo.org/~steev/files/image1.jpg
Presumably this means that your panel is defined improperly? If the
panel reports that it's a 6 bits per pixel panel but it's actually an
8 bits per pixel panel then you'll run into this problem.
I would have to assume you have a bunch of out of tree patches to
support your hardware since I don't see any device trees in linuxnext
(other than cheza) that use this bridge chip. Otherwise I could try
to check and confirm that was the problem.
Ah, interesting. Maybe you have the panel:
boe,nv133fhm-n61
As far as I can tell from the datasheet (I have the similar
boe,nv133fhm-n62) this is a 6bpp panel. ...but if you feed it 8bpp
the banding goes away! Maybe the panel itself knows how to dither???
...or maybe the datasheet / edid are wrong and this is actually an
8bpp panel. Seems unlikely...
In any case, one fix is to pick
<https://lore.kernel.org/dri-devel/1593087419-903-1-git-send-email-kalya...@codeaurora.org/>,
though right now that patch is only enabled for sc7180. Maybe you
could figure out how to apply it to your hardware?
...another fix would be to pretend that your panel is 8bpp even though
it's actually 6bpp. Ironically if anyone ever tried to configure BPP
from the EDID they'd go back to 6bpp. You can read the EDID of your
panel with this:
bus=$(i2cdetect -l | grep sn65 | sed 's/i2c-\([0-9]*\).*$/\1/')
i2cdump ${bus} 0x50 i
When I do that and then decode it on the "boe,nv133fhm-n62" panel, I find:
6 bits per primary color channel
-Doug
Hi Doug,
Decoding it does show be to boe,nv133fhm-n61 - and yeah it does say it's
6-bit according to panelook's specs for it.
I'll take a look at the patch and see what I can come up with... at the
moment, I'm forcing it to be 8bit and that does "work fine" but I'd like
it to be fixed properly instead of my hack.
Thanks for your time and work!
-- Steev
Re: [PATCH v3 6/9] drm/bridge: ti-sn65dsi86: Use 18-bit DP if we can
On 7/9/20 10:12 PM, Steev Klimaszewski wrote:
On 7/9/20 9:14 PM, Doug Anderson wrote:
Hi,
On Thu, Jul 9, 2020 at 6:38 PM Doug Anderson
wrote:
Hi,
On Thu, Jul 9, 2020 at 6:19 PM Steev Klimaszewski
wrote:
Hi Doug,
I've been testing 5.8 and linux-next on the Lenovo Yoga C630, and
with this patch applied, there is really bad banding on the display.
I'm really bad at explaining it, but you can see the differences in
the following:
24bit (pre-5.8) - https://dev.gentoo.org/~steev/files/image0.jpg
18bit (5.8/linux-next) -
https://dev.gentoo.org/~steev/files/image1.jpg
Presumably this means that your panel is defined improperly? If the
panel reports that it's a 6 bits per pixel panel but it's actually an
8 bits per pixel panel then you'll run into this problem.
I would have to assume you have a bunch of out of tree patches to
support your hardware since I don't see any device trees in linuxnext
(other than cheza) that use this bridge chip. Otherwise I could try
to check and confirm that was the problem.
Ah, interesting. Maybe you have the panel:
boe,nv133fhm-n61
As far as I can tell from the datasheet (I have the similar
boe,nv133fhm-n62) this is a 6bpp panel. ...but if you feed it 8bpp
the banding goes away! Maybe the panel itself knows how to dither???
...or maybe the datasheet / edid are wrong and this is actually an
8bpp panel. Seems unlikely...
In any case, one fix is to pick
<https://lore.kernel.org/dri-devel/1593087419-903-1-git-send-email-kalya...@codeaurora.org/>,
though right now that patch is only enabled for sc7180. Maybe you
could figure out how to apply it to your hardware?
...another fix would be to pretend that your panel is 8bpp even though
it's actually 6bpp. Ironically if anyone ever tried to configure BPP
from the EDID they'd go back to 6bpp. You can read the EDID of your
panel with this:
bus=$(i2cdetect -l | grep sn65 | sed 's/i2c-\([0-9]*\).*$/\1/')
i2cdump ${bus} 0x50 i
When I do that and then decode it on the "boe,nv133fhm-n62" panel, I
find:
6 bits per primary color channel
-Doug
Hi Doug,
Decoding it does show be to boe,nv133fhm-n61 - and yeah it does say
it's 6-bit according to panelook's specs for it.
I'll take a look at the patch and see what I can come up with... at
the moment, I'm forcing it to be 8bit and that does "work fine" but
I'd like it to be fixed properly instead of my hack.
Thanks for your time and work!
-- Steev
For what it's worth - the 5.8 that I'm testing is at
https://github.com/steev/linux/commits/c630-5.8-rc4-inline-encryption
Re: [PATCH v3 6/9] drm/bridge: ti-sn65dsi86: Use 18-bit DP if we can
On 7/9/20 10:17 PM, Steev Klimaszewski wrote:
On 7/9/20 10:12 PM, Steev Klimaszewski wrote:
On 7/9/20 9:14 PM, Doug Anderson wrote:
Hi,
On Thu, Jul 9, 2020 at 6:38 PM Doug Anderson
wrote:
Hi,
On Thu, Jul 9, 2020 at 6:19 PM Steev Klimaszewski
wrote:
Hi Doug,
I've been testing 5.8 and linux-next on the Lenovo Yoga C630, and
with this patch applied, there is really bad banding on the display.
I'm really bad at explaining it, but you can see the differences
in the following:
24bit (pre-5.8) - https://dev.gentoo.org/~steev/files/image0.jpg
18bit (5.8/linux-next) -
https://dev.gentoo.org/~steev/files/image1.jpg
Presumably this means that your panel is defined improperly? If the
panel reports that it's a 6 bits per pixel panel but it's actually an
8 bits per pixel panel then you'll run into this problem.
I would have to assume you have a bunch of out of tree patches to
support your hardware since I don't see any device trees in linuxnext
(other than cheza) that use this bridge chip. Otherwise I could try
to check and confirm that was the problem.
Ah, interesting. Maybe you have the panel:
boe,nv133fhm-n61
As far as I can tell from the datasheet (I have the similar
boe,nv133fhm-n62) this is a 6bpp panel. ...but if you feed it 8bpp
the banding goes away! Maybe the panel itself knows how to dither???
...or maybe the datasheet / edid are wrong and this is actually an
8bpp panel. Seems unlikely...
In any case, one fix is to pick
<https://lore.kernel.org/dri-devel/1593087419-903-1-git-send-email-kalya...@codeaurora.org/>,
though right now that patch is only enabled for sc7180. Maybe you
could figure out how to apply it to your hardware?
...another fix would be to pretend that your panel is 8bpp even though
it's actually 6bpp. Ironically if anyone ever tried to configure BPP
from the EDID they'd go back to 6bpp. You can read the EDID of your
panel with this:
bus=$(i2cdetect -l | grep sn65 | sed 's/i2c-\([0-9]*\).*$/\1/')
i2cdump ${bus} 0x50 i
When I do that and then decode it on the "boe,nv133fhm-n62" panel, I
find:
6 bits per primary color channel
-Doug
Hi Doug,
Decoding it does show be to boe,nv133fhm-n61 - and yeah it does say
it's 6-bit according to panelook's specs for it.
I derped again...
root@c630:~# bus=$(i2cdetect -l | grep sn65 | sed 's/i2c-\([0-9]*\).*$/\1/')
root@c630:~# i2cdump ${bus} 0x50 i > edid
WARNING! This program can confuse your I2C bus, cause data loss and worse!
I will probe file /dev/i2c-16, address 0x50, mode i2c block
Continue? [Y/n]
root@c630:~# edid-decode edid
edid-decode (hex):
00 ff ff ff ff ff ff 00 09 e5 d1 07 00 00 00 00
01 1c 01 04 a5 1d 11 78 0a 1d b0 a6 58 54 9e 26
0f 50 54 00 00 00 01 01 01 01 01 01 01 01 01 01
01 01 01 01 01 01 c0 39 80 18 71 38 28 40 30 20
36 00 26 a5 10 00 00 1a 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 1a 00 00 00 fe 00 42
4f 45 20 43 51 0a 20 20 20 20 20 20 00 00 00 fe
00 4e 56 31 33 33 46 48 4d 2d 4e 36 31 0a 00 9a
03 26 0a 77 ab 1c 05 71 6f 1d 8c f1 43 ce 6a bb
fb d3 11 20 39 07 22 6e 65 68 77 70 d3 05 34 73
44 21 8b fd f5 6d 11 62 94 2a 7c fa 93 ba 6a 61
92 da 15 53 4c 39 eb f7 86 23 97 48 e9 39 09 d2
66 02 70 bb e2 77 0f 4a a3 a0 4c 72 6e 5d 47 70
43 c2 13 f3 b2 d9 b9 78 02 be 41 82 15 6a 28 dc
45 0f 9d eb 0f 2a cc e8 35 8d 34 7f 3e 84 5e a3
30 5e 1e 29 0a 48 0c d1 0a c4 08 31 03 a9 3b 29
EDID version: 1.4
Manufacturer: BOE Model 2001 Serial Number 0
Made in week 1 of 2018
Digital display
8 bits per primary color channel
DisplayPort interface
Maximum image size: 29 cm x 17 cm
Gamma: 2.20
Supported color formats: RGB 4:4:4, YCrCb 4:4:4
First detailed timing includes the native pixel format and preferred
refresh rate
Color Characteristics
Red: 0.6484, 0.3447
Green: 0.3310, 0.6181
Blue: 0.1503, 0.0615
White: 0.3125, 0.3281
Established Timings I & II: none
Standard Timings: none
Detailed mode: Clock 147.840 MHz, 294 mm x 165 mm
1920 1968 2000 2200 ( 48 32 200)
1080 1083 1089 1120 ( 3 6 31)
+hsync -vsync
VertFreq: 60.000 Hz, HorFreq: 67.200 kHz
Manufacturer-Specified Display Descriptor (0x00): 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 1a
Alphanumeric Data String: BOE CQ
Alphanumeric Data String: NV133FHM-N61
Checksum: 0x9a
Unknown EDID Extension Block 0x03
03 26 0a 77 ab 1c 05 71 6f 1d 8c f1 43 ce 6a bb .&.w...qo...C.j.
fb d3 11 20 39 07 22 6e 65 68 77 70 d3 05 34 73 ... 9."nehwp..4s
44 21 8b fd f5 6d 11 62 94 2a 7c fa 93 ba 6a 61 D!...m.b.*|...ja
92 da 15 53 4c 39 eb f7 86 23 97 48 e9 39 09 d2 ...SL9...#.H.9..
66 02 70 bb e2 77 0f 4a a3 a0 4c 72 6e 5d 47 70 f.p..w.J..Lrn]Gp
43 c2 13 f3 b2 d9 b9 78 02 be 41 82 15 6a 28 dc C..x..A..j(.
45 0f 9d eb 0f 2a cc e8 35 8d 34 7f 3e 84 5e a3 E*..5.4.>.^.
30 5e 1e 29 0a 48 0c d1 0a c4 08 31 03 a9 3b 29 0^.).H.1..;)
Checksum: 0x29 (should be 0x82)
- My edid does in fact say it's 8bit
Re: [PATCH v3 6/9] drm/bridge: ti-sn65dsi86: Use 18-bit DP if we can
Hi,
On 7/9/20 11:12 PM, Doug Anderson wrote:
root@c630:~# bus=$(i2cdetect -l | grep sn65 | sed 's/i2c-\([0-9]*\).*$/\1/')
root@c630:~# i2cdump ${bus} 0x50 i > edid
WARNING! This program can confuse your I2C bus, cause data loss and worse!
I will probe file /dev/i2c-16, address 0x50, mode i2c block
Continue? [Y/n]
root@c630:~# edid-decode edid
edid-decode (hex):
00 ff ff ff ff ff ff 00 09 e5 d1 07 00 00 00 00
01 1c 01 04 a5 1d 11 78 0a 1d b0 a6 58 54 9e 26
0f 50 54 00 00 00 01 01 01 01 01 01 01 01 01 01
01 01 01 01 01 01 c0 39 80 18 71 38 28 40 30 20
36 00 26 a5 10 00 00 1a 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 1a 00 00 00 fe 00 42
4f 45 20 43 51 0a 20 20 20 20 20 20 00 00 00 fe
00 4e 56 31 33 33 46 48 4d 2d 4e 36 31 0a 00 9a
03 26 0a 77 ab 1c 05 71 6f 1d 8c f1 43 ce 6a bb
fb d3 11 20 39 07 22 6e 65 68 77 70 d3 05 34 73
44 21 8b fd f5 6d 11 62 94 2a 7c fa 93 ba 6a 61
92 da 15 53 4c 39 eb f7 86 23 97 48 e9 39 09 d2
66 02 70 bb e2 77 0f 4a a3 a0 4c 72 6e 5d 47 70
43 c2 13 f3 b2 d9 b9 78 02 be 41 82 15 6a 28 dc
45 0f 9d eb 0f 2a cc e8 35 8d 34 7f 3e 84 5e a3
30 5e 1e 29 0a 48 0c d1 0a c4 08 31 03 a9 3b 29
EDID version: 1.4
Manufacturer: BOE Model 2001 Serial Number 0
Made in week 1 of 2018
Digital display
8 bits per primary color channel
DisplayPort interface
Maximum image size: 29 cm x 17 cm
Gamma: 2.20
Supported color formats: RGB 4:4:4, YCrCb 4:4:4
First detailed timing includes the native pixel format and preferred
refresh rate
Color Characteristics
Red: 0.6484, 0.3447
Green: 0.3310, 0.6181
Blue: 0.1503, 0.0615
White: 0.3125, 0.3281
Established Timings I & II: none
Standard Timings: none
Detailed mode: Clock 147.840 MHz, 294 mm x 165 mm
1920 1968 2000 2200 ( 48 32 200)
1080 1083 1089 1120 ( 3 6 31)
+hsync -vsync
VertFreq: 60.000 Hz, HorFreq: 67.200 kHz
Manufacturer-Specified Display Descriptor (0x00): 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 1a
Alphanumeric Data String: BOE CQ
Alphanumeric Data String: NV133FHM-N61
Checksum: 0x9a
Unknown EDID Extension Block 0x03
03 26 0a 77 ab 1c 05 71 6f 1d 8c f1 43 ce 6a bb .&.w...qo...C.j.
fb d3 11 20 39 07 22 6e 65 68 77 70 d3 05 34 73 ... 9."nehwp..4s
44 21 8b fd f5 6d 11 62 94 2a 7c fa 93 ba 6a 61 D!...m.b.*|...ja
92 da 15 53 4c 39 eb f7 86 23 97 48 e9 39 09 d2 ...SL9...#.H.9..
66 02 70 bb e2 77 0f 4a a3 a0 4c 72 6e 5d 47 70 f.p..w.J..Lrn]Gp
43 c2 13 f3 b2 d9 b9 78 02 be 41 82 15 6a 28 dc C..x..A..j(.
45 0f 9d eb 0f 2a cc e8 35 8d 34 7f 3e 84 5e a3 E*..5.4.>.^.
30 5e 1e 29 0a 48 0c d1 0a c4 08 31 03 a9 3b 29 0^.).H.1..;)
Checksum: 0x29 (should be 0x82)
- My edid does in fact say it's 8bit
Crazy! Mine:
Extracted contents:
header: 00 ff ff ff ff ff ff 00
serial number: 09 e5 2d 08 00 00 00 00 23 1c
version: 01 04
basic params:95 1d 11 78 02
chroma info: d5 00 a6 58 54 9f 27 0f 4f 57
established: 00 00 00
standard:01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01
descriptor 1:c0 39 80 18 71 38 28 40 30 20 36 00 26 a5 10 00 00 1a
descriptor 2:00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
descriptor 3:00 00 00 fe 00 42 4f 45 20 43 51 0a 20 20 20 20 20 20
descriptor 4:00 00 00 fe 00 4e 56 31 33 33 46 48 4d 2d 4e 36 32 0a
extensions: 00
checksum:40
Manufacturer: BOE Model 82d Serial Number 0
Made week 35 of 2018
EDID version: 1.4
Digital display
6 bits per primary color channel
DisplayPort interface
Maximum image size: 29 cm x 17 cm
Gamma: 2.20
Supported color formats: RGB 4:4:4
First detailed timing is preferred timing
Established timings supported:
Standard timings supported:
Detailed mode: Clock 147.840 MHz, 294 mm x 165 mm
1920 1968 2000 2200 hborder 0
1080 1083 1089 1120 vborder 0
+hsync -vsync
Manufacturer-specified data, tag 0
ASCII string: BOE
ASCII string: NV133FHM-N62
Checksum: 0x40 (valid)
Unknown extension block
EDID block does NOT conform to EDID 1.3!
Missing name descriptor
Missing monitor ranges
Detailed block string not properly terminated
EDID block does not conform at all!
Has 128 nonconformant extension block(s)
I did attempt to modify the patch, and I don't think I did it correctly
Around line 232, I changed
IS_SC7180_TARGET(c->hw.hwversion))
to
IS_SC7180_TARGET(c->hw.hwversion) ||
IS_SDM845_TARGET(c->hw.hwversion))
But it would seem that only gets us 1/2 way there...
https://dev.gentoo.org/~steev/files/image2.jpg
But should I continue on this path, or should we be finding others who
have an N61 and see what their EDID reports?
I have another c630, but unfortunately, it appears to have the IVO
screen in it, instead of another N61. I asked another user and he also
had the IVO.
-- steev
Re: [PATCH v3 6/9] drm/bridge: ti-sn65dsi86: Use 18-bit DP if we can
On 7/10/20 9:47 AM, Doug Anderson wrote: > Hi, > > > But should I continue on this path, > It's probably worth getting dithering working on your sdm845 anyway in > case anyone actually does put a 6bpp panel on this SoC. > > >> or should we be finding others who >> have an N61 and see what their EDID reports? > I have an email out to BOE, but it might take a little while to get a > response. I'll see what they say. If they say that the panel > actually supports 8bpp then it's a no-brainer and we should just > switch to 8bpp and be done. > > ...but if they say it's a 6bpp panel that has its own dither logic > then it gets more complicated. Initially one would think there should > be very little downside in defining the panel as an 8bpp panel and > calling it done. ...except that it conflicts with some other work > that I have in progress. :-P Specifically if you treat the panel as > 6bpp and then reduce the blanking a tiny bit you can actually save 75 > mW of total system power on my board (probably similar on your board > since you have the same bridge chip). You can see a patch to do that > here: > > https://crrev.com/c/2276384 > > ...so I'm hoping to get some clarity from BOE both on the true bits > per pixel and whether my proposed timings are valid before moving > forward. Is that OK? > > > -Doug It's fine by me - testing Rob's suggestion of changing MAX_HDISPLAY_SPLIT 1080->1920 along with the change to adding IS_SDM845 does give me a full screen that looks nicer, I'm fine with using the hack locally until a proper solution is found. And I'm always a fan of using less power on a laptop. I'll give the patch a spin here if you want as well. Hopefully BOE gets back to you soon, and there's no rush, I'm just an end user who is extremely appreciative of all the work everyone on the list and the kernel in general put in to make my machines usable.
Re: [PATCH v1 1/3] scsi: ufs: add write booster feature support
On 6/21/20 11:50 AM, Rob Clark wrote: > This looks like a device issue to be taken with the flash vendor: >> There's no way for a end-user to file a bug report with the flash vendor >> on a device bought from an OEM and even if they would accept the bug >> report they wouldn't re-provision the flash in an shipped device. >> >> So you will have to work around this in the driver. > oh, ugg.. well I think these msgs from dmesg identify the part if we > end up needing to use a denylist: > > scsi 0:0:0:49488: Well-known LUNSKhynix H28S8Q302CMR A102 PQ: 0 > ANSI: 6 > scsi 0:0:0:49476: Well-known LUNSKhynix H28S8Q302CMR A102 PQ: 0 > ANSI: 6 > scsi 0:0:0:49456: Well-known LUNSKhynix H28S8Q302CMR A102 PQ: 0 > ANSI: 6 > scsi 0:0:0:0: Direct-Access SKhynix H28S8Q302CMR A102 PQ: 0 ANSI: 6 > scsi 0:0:0:1: Direct-Access SKhynix H28S8Q302CMR A102 PQ: 0 ANSI: 6 > sd 0:0:0:0: [sda] 29765632 4096-byte logical blocks: (122 GB/114 GiB) > sd 0:0:0:0: [sda] Write Protect is off > sd 0:0:0:0: [sda] Mode Sense: 00 32 00 10 > sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, supports > DPO and FUA > sd 0:0:0:0: [sda] Optimal transfer size 786432 bytes > scsi 0:0:0:2: Direct-Access SKhynix H28S8Q302CMR A102 PQ: 0 ANSI: 6 > scsi 0:0:0:3: Direct-Access SKhynix H28S8Q302CMR A102 PQ: 0 ANSI: 6 > > > (otoh I guess the driver could just notice that writeboost keeps > failing and stop trying to use it) > > BR, > -R FWIW, I see this on my c630 as well, but my LUN shows up as scsi 0:0:0:49488: Well-known LUN SAMSUNG KLUDG4U1EA-B0C1 0500 PQ: 0 ANSI: 6
Re: [v1] drm/msm/disp/dpu1: icc path needs to be set before dpu runtime resume
On 3/22/21 4:17 AM, Kalyan Thota wrote:
> From: Kalyan Thota
>
> DPU runtime resume will request for a min vote on the AXI bus as
> it is a necessary step before turning ON the AXI clock.
>
> The change does below
> 1) Move the icc path set before requesting runtime get_sync.
> 2) remove the dependency of hw catalog for min ib vote
> as it is initialized at a later point.
>
> Signed-off-by: Kalyan Thota
> ---
> drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 12 +++-
> 1 file changed, 7 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
> index ed636f1..cab387f 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
> @@ -44,6 +44,8 @@
> #define DPU_DEBUGFS_DIR "msm_dpu"
> #define DPU_DEBUGFS_HWMASKNAME "hw_log_mask"
>
> +#define MIN_IB_BW4ULL /* Min ib vote 400MB */
> +
> static int dpu_kms_hw_init(struct msm_kms *kms);
> static void _dpu_kms_mmu_destroy(struct dpu_kms *dpu_kms);
>
> @@ -932,6 +934,9 @@ static int dpu_kms_hw_init(struct msm_kms *kms)
> DPU_DEBUG("REG_DMA is not defined");
> }
>
> + if (of_device_is_compatible(dev->dev->of_node, "qcom,sc7180-mdss"))
> + dpu_kms_parse_data_bus_icc_path(dpu_kms);
> +
> pm_runtime_get_sync(_kms->pdev->dev);
>
> dpu_kms->core_rev = readl_relaxed(dpu_kms->mmio + 0x0);
> @@ -1037,9 +1042,6 @@ static int dpu_kms_hw_init(struct msm_kms *kms)
>
> dpu_vbif_init_memtypes(dpu_kms);
>
> - if (of_device_is_compatible(dev->dev->of_node, "qcom,sc7180-mdss"))
> - dpu_kms_parse_data_bus_icc_path(dpu_kms);
> -
> pm_runtime_put_sync(_kms->pdev->dev);
>
> return 0;
> @@ -1196,10 +1198,10 @@ static int __maybe_unused dpu_runtime_resume(struct
> device *dev)
>
> ddev = dpu_kms->dev;
>
> + WARN_ON(!(dpu_kms->num_paths));
> /* Min vote of BW is required before turning on AXI clk */
> for (i = 0; i < dpu_kms->num_paths; i++)
> - icc_set_bw(dpu_kms->path[i], 0,
> - dpu_kms->catalog->perf.min_dram_ib);
> + icc_set_bw(dpu_kms->path[i], 0, Bps_to_icc(MIN_IB_BW));
>
> rc = msm_dss_enable_clk(mp->clk_config, mp->num_clk, true);
> if (rc) {
With this patch now applied to 5.12-rc5, I am seeing the following when
booting the Lenovo Yoga C630 -
Mar 30 13:16:03 c630 kernel: [2.038491] [ cut here ]
Mar 30 13:16:03 c630 kernel: [2.038495] WARNING: CPU: 3 PID: 125 at
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c:1196 dpu_runtime_resume+0xc0/0xf0 [msm]
Mar 30 13:16:03 c630 kernel: [2.038551] Modules linked in: ti_sn65dsi86
i2c_hid_of crct10dif_ce msm rtc_pm8xxx llcc_qcom ocmem drm_kms_helper
i2c_qcom_geni phy_qcom_qusb2 ipa(+) qcom_common qcom_glink_smem qmi_helpers
mdt_loader panel_simple drm pwm_bl
Mar 30 13:16:03 c630 kernel: [2.038599] CPU: 3 PID: 125 Comm: kworker/3:1
Not tainted 5.12.0-rc5 #1
Mar 30 13:16:03 c630 kernel: [2.038605] Hardware name: LENOVO
81JL/LNVNB161216, BIOS 9UCN33WW(V2.06) 06/ 4/2019
Mar 30 13:16:03 c630 kernel: [2.038610] Workqueue: events
deferred_probe_work_func
Mar 30 13:16:03 c630 kernel: [2.038621] pstate: 6045 (nZCv daif +PAN
-UAO -TCO BTYPE=--)
Mar 30 13:16:03 c630 kernel: [2.038627] pc : dpu_runtime_resume+0xc0/0xf0
[msm]
Mar 30 13:16:03 c630 kernel: [2.038674] lr :
pm_generic_runtime_resume+0x30/0x50
Mar 30 13:16:03 c630 kernel: [2.038683] sp : 800010b9b7e0
Mar 30 13:16:03 c630 kernel: [2.038685] x29: 800010b9b7e0 x28:
Mar 30 13:16:03 c630 kernel: [2.038692] x27: x26:
6b42c0c16cf4
Mar 30 13:16:03 c630 kernel: [2.038698] x25: 7965f7df x24:
0001
Mar 30 13:16:03 c630 kernel: [2.038705] x23: 6b42c0a34180 x22:
da2e0cc5b3d0
Mar 30 13:16:03 c630 kernel: [2.038712] x21: da2e0b3ed6a0 x20:
6b42c6845000
Mar 30 13:16:03 c630 kernel: [2.038718] x19: 6b42c6851080 x18:
da2e0cce1220
Mar 30 13:16:03 c630 kernel: [2.038725] x17: da2e0cce1238 x16:
da2e0b23e5f0
Mar 30 13:16:03 c630 kernel: [2.038731] x15: 4000 x14:
Mar 30 13:16:03 c630 kernel: [2.038738] x13: 6b42c5f0b5b0 x12:
Mar 30 13:16:03 c630 kernel: [2.038744] x11: 0001 x10:
3fff
Mar 30 13:16:03 c630 kernel: [2.038750] x9 : x8 :
Mar 30 13:16:03 c630 kernel: [2.038755] x7 : x6 :
0c473b7e
Mar 30 13:16:03 c630 kernel: [2.038761] x5 : 00ff x4 :
00221806fff8f800
Mar 30 13:16:03 c630 kernel: [2.038768] x3 : 0018 x2 :
da2dc3d34320
Mar 30 13:16:03 c630 kernel: [2.038774] x1 : x0 :
Mar 30 13:16:03 c630 kernel: [2.038781] Call trace:
Mar 30 13:16:03 c630
Re: [Freedreno] [v1] drm/msm/disp/dpu1: icc path needs to be set before dpu runtime resume
On 3/31/21 7:34 AM, kalya...@codeaurora.org wrote: > On 2021-03-31 00:04, Steev Klimaszewski wrote: >> On 3/22/21 4:17 AM, Kalyan Thota wrote: >>> From: Kalyan Thota >>> >>> DPU runtime resume will request for a min vote on the AXI bus as >>> it is a necessary step before turning ON the AXI clock. >>> > Hi Steev, > > The WARN_ON is true only for the device with compatible > "qcom,sc7180-mdss". For other devices its a > false alarm. Can you please try with the below change ? > > https://patchwork.kernel.org/project/linux-arm-msm/patch/1617190020-7931-1-git-send-email-kalya...@codeaurora.org/ > > > Thanks, > Kalyan > Hi Kalyan, Tested here, and it does get rid of the warning. I'll keep a copy of the patch locally, since this is going to hit stable too at some point it seems, at least until another version comes out addressing the other comments from people way smarter than me. -- steev
Re: [PATCH v7 0/6] soc: qcom: add in-kernel pd-mapper implementation
Hi Dmitry, On Wed, Apr 24, 2024 at 4:28 AM Dmitry Baryshkov wrote: > > Protection domain mapper is a QMI service providing mapping between > 'protection domains' and services supported / allowed in these domains. > For example such mapping is required for loading of the WiFi firmware or > for properly starting up the UCSI / altmode / battery manager support. > > The existing userspace implementation has several issue. It doesn't play > well with CONFIG_EXTRA_FIRMWARE, it doesn't reread the JSON files if the > firmware location is changed (or if the firmware was not available at > the time pd-mapper was started but the corresponding directory is > mounted later), etc. > > However this configuration is largely static and common between > different platforms. Provide in-kernel service implementing static > per-platform data. > > Unlike previous revisions of the patchset, this iteration uses static > configuration per platform, rather than building it dynamically from the > list of DSPs being started. > > To: Bjorn Andersson > To: Konrad Dybcio > To: Sibi Sankar > To: Mathieu Poirier > Cc: linux-arm-...@vger.kernel.org > Cc: linux-kernel@vger.kernel.org > Cc: linux-remotep...@vger.kernel.org > Cc: Johan Hovold > Cc: Xilin Wu > Cc: "Bryan O'Donoghue" > -- > > Changes in v7: > - Fixed modular build (Steev) > - Link to v6: > https://lore.kernel.org/r/20240422-qcom-pd-mapper-v6-0-f96957d01...@linaro.org > > Changes in v6: > - Reworked mutex to fix lockdep issue on deregistration > - Fixed dependencies between PD-mapper and remoteproc to fix modular > builds (Krzysztof) > - Added EXPORT_SYMBOL_GPL to fix modular builds (Krzysztof) > - Fixed kerneldocs (Krzysztof) > - Removed extra pr_debug messages (Krzysztof) > - Fixed wcss build (Krzysztof) > - Added platforms which do not require protection domain mapping to > silence the notice on those platforms > - Link to v5: > https://lore.kernel.org/r/20240419-qcom-pd-mapper-v5-0-e35b6f847...@linaro.org > > Changes in v5: > - pdr: drop lock in pdr_register_listener, list_lock is already held (Chris > Lew) > - pd_mapper: reworked to provide static configuration per platform > (Bjorn) > - Link to v4: > https://lore.kernel.org/r/20240311-qcom-pd-mapper-v4-0-24679cca5...@linaro.org > > Changes in v4: > - Fixed missing chunk, reenabled kfree in qmi_del_server (Konrad) > - Added configuration for sm6350 (Thanks to Luca) > - Removed RFC tag (Konrad) > - Link to v3: > https://lore.kernel.org/r/20240304-qcom-pd-mapper-v3-0-6858fa1ac...@linaro.org > > Changes in RFC v3: > - Send start / stop notifications when PD-mapper domain list is changed > - Reworked the way PD-mapper treats protection domains, register all of > them in a single batch > - Added SC7180 domains configuration based on TCL Book 14 GO > - Link to v2: > https://lore.kernel.org/r/20240301-qcom-pd-mapper-v2-0-5d12a081d...@linaro.org > > Changes in RFC v2: > - Swapped num_domains / domains (Konrad) > - Fixed an issue with battery not working on sc8280xp > - Added missing configuration for QCS404 > > --- > Dmitry Baryshkov (6): > soc: qcom: pdr: protect locator_addr with the main mutex > soc: qcom: pdr: fix parsing of domains lists > soc: qcom: pdr: extract PDR message marshalling data > soc: qcom: qmi: add a way to remove running service > soc: qcom: add pd-mapper implementation > remoteproc: qcom: enable in-kernel PD mapper > > drivers/remoteproc/Kconfig | 4 + > drivers/remoteproc/qcom_q6v5_adsp.c | 11 +- > drivers/remoteproc/qcom_q6v5_mss.c | 10 +- > drivers/remoteproc/qcom_q6v5_pas.c | 12 +- > drivers/remoteproc/qcom_q6v5_wcss.c | 12 +- > drivers/soc/qcom/Kconfig| 14 + > drivers/soc/qcom/Makefile | 2 + > drivers/soc/qcom/pdr_interface.c| 6 +- > drivers/soc/qcom/pdr_internal.h | 318 ++--- > drivers/soc/qcom/qcom_pd_mapper.c | 656 > > drivers/soc/qcom/qcom_pdr_msg.c | 353 +++ > drivers/soc/qcom/qmi_interface.c| 67 > include/linux/soc/qcom/pd_mapper.h | 28 ++ > include/linux/soc/qcom/qmi.h| 2 + > 14 files changed, 1193 insertions(+), 302 deletions(-) > --- > base-commit: a59668a9397e7245b26e9be85d23f242ff757ae8 > change-id: 20240301-qcom-pd-mapper-e12d622d4ad0 > > Best regards, > -- > Dmitry Baryshkov > > I've tested this series over a large number of reboots, and the p-d devices(?) do always seem to come up (with the pd-mapper service disabled) on my Thinkpad X13s. One less service to run in userland! Tested-by: Steev Klimaszewski
Re: [PATCH v8 0/5] soc: qcom: add in-kernel pd-mapper implementation
On Sat, May 11, 2024 at 4:56 PM Dmitry Baryshkov wrote: > > Protection domain mapper is a QMI service providing mapping between > 'protection domains' and services supported / allowed in these domains. > For example such mapping is required for loading of the WiFi firmware or > for properly starting up the UCSI / altmode / battery manager support. > > The existing userspace implementation has several issue. It doesn't play > well with CONFIG_EXTRA_FIRMWARE, it doesn't reread the JSON files if the > firmware location is changed (or if the firmware was not available at > the time pd-mapper was started but the corresponding directory is > mounted later), etc. > > However this configuration is largely static and common between > different platforms. Provide in-kernel service implementing static > per-platform data. > > To: Bjorn Andersson > To: Konrad Dybcio > To: Sibi Sankar > To: Mathieu Poirier > Cc: linux-arm-...@vger.kernel.org > Cc: linux-kernel@vger.kernel.org > Cc: linux-remotep...@vger.kernel.org > Cc: Johan Hovold > Cc: Xilin Wu > Cc: "Bryan O'Donoghue" > Cc: Steev Klimaszewski > Cc: Alexey Minnekhanov > > -- > > Changes in v8: > - Reworked pd-mapper to register as an rproc_subdev / auxdev > - Dropped Tested-by from Steev and Alexey from the last patch since the > implementation was changed significantly. > - Add sensors, cdsp and mpss_root domains to 660 config (Alexey > Minnekhanov) > - Added platform entry for sm4250 (used for qrb4210 / RB2) > - Added locking to the pdr_get_domain_list() (Chris Lew) > - Remove the call to qmi_del_server() and corresponding API (Chris Lew) > - In qmi_handle_init() changed 1024 to a defined constant (Chris Lew) > - Link to v7: > https://lore.kernel.org/r/20240424-qcom-pd-mapper-v7-0-05f7fc646...@linaro.org > > Changes in v7: > - Fixed modular build (Steev) > - Link to v6: > https://lore.kernel.org/r/20240422-qcom-pd-mapper-v6-0-f96957d01...@linaro.org > > Changes in v6: > - Reworked mutex to fix lockdep issue on deregistration > - Fixed dependencies between PD-mapper and remoteproc to fix modular > builds (Krzysztof) > - Added EXPORT_SYMBOL_GPL to fix modular builds (Krzysztof) > - Fixed kerneldocs (Krzysztof) > - Removed extra pr_debug messages (Krzysztof) > - Fixed wcss build (Krzysztof) > - Added platforms which do not require protection domain mapping to > silence the notice on those platforms > - Link to v5: > https://lore.kernel.org/r/20240419-qcom-pd-mapper-v5-0-e35b6f847...@linaro.org > > Changes in v5: > - pdr: drop lock in pdr_register_listener, list_lock is already held (Chris > Lew) > - pd_mapper: reworked to provide static configuration per platform > (Bjorn) > - Link to v4: > https://lore.kernel.org/r/20240311-qcom-pd-mapper-v4-0-24679cca5...@linaro.org > > Changes in v4: > - Fixed missing chunk, reenabled kfree in qmi_del_server (Konrad) > - Added configuration for sm6350 (Thanks to Luca) > - Removed RFC tag (Konrad) > - Link to v3: > https://lore.kernel.org/r/20240304-qcom-pd-mapper-v3-0-6858fa1ac...@linaro.org > > Changes in RFC v3: > - Send start / stop notifications when PD-mapper domain list is changed > - Reworked the way PD-mapper treats protection domains, register all of > them in a single batch > - Added SC7180 domains configuration based on TCL Book 14 GO > - Link to v2: > https://lore.kernel.org/r/20240301-qcom-pd-mapper-v2-0-5d12a081d...@linaro.org > > Changes in RFC v2: > - Swapped num_domains / domains (Konrad) > - Fixed an issue with battery not working on sc8280xp > - Added missing configuration for QCS404 > > --- > Dmitry Baryshkov (5): > soc: qcom: pdr: protect locator_addr with the main mutex > soc: qcom: pdr: fix parsing of domains lists > soc: qcom: pdr: extract PDR message marshalling data > soc: qcom: add pd-mapper implementation > remoteproc: qcom: enable in-kernel PD mapper > > drivers/remoteproc/qcom_common.c| 87 + > drivers/remoteproc/qcom_common.h| 10 + > drivers/remoteproc/qcom_q6v5_adsp.c | 3 + > drivers/remoteproc/qcom_q6v5_mss.c | 3 + > drivers/remoteproc/qcom_q6v5_pas.c | 3 + > drivers/remoteproc/qcom_q6v5_wcss.c | 3 + > drivers/soc/qcom/Kconfig| 15 + > drivers/soc/qcom/Makefile | 2 + > drivers/soc/qcom/pdr_interface.c| 17 +- > drivers/soc/qcom/pdr_internal.h | 318 ++--- > drivers/soc/qcom/qcom_pd_mapper.c | 676 > > drivers/soc/qcom/qcom_pdr_msg.c | 353 +++ > 12 files changed, 1190 insertions(+), 300 deletions(-) > --- > base-commit: e5119bbdaca76cd3c15c3c975d51d840bbfb2488 > change-id: 20240301-qcom-pd-mapper-e12d622d4ad0 > > Best regards, > -- > Dmitry Baryshkov > I've tested this over the weekend on my Thinkpad X13s with a number of reboots and seems to do the correct thing in v8 as well. Tested-by: Steev Klimaszewski
