[radeon-alex:drm-next-4.15-dc 148/1063] drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/rv_hwmgr.c:845:49-50: asic_setup: first occurrence line 848, second occurrence line 875

[Julia Lawall]

There are two initializations of .asic_setup in this structure.

julia

-- Forwarded message --
Date: Wed, 27 Sep 2017 10:16:08 +0800
From: kbuild test robot 
To: kbu...@01.org
Cc: Julia Lawall 
Subject: [radeon-alex:drm-next-4.15-dc 148/1063]
drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/rv_hwmgr.c:845:49-50:
asic_setup: first occurrence line 848, second occurrence line 875


tree:   git://people.freedesktop.org/~agd5f/linux.git drm-next-4.15-dc
head:   dfbf0c14dd75d3b15f65478f10f373aa83042a50
commit: cf2623d951c1c52923a776e01cf2e2afc9d042a0 [148/1063] drm/amd/powerplay: 
refine powerplay code for RV
:: branch date: 4 hours ago
:: commit date: 8 days ago

>> drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/rv_hwmgr.c:845:49-50: 
>> asic_setup: first occurrence line 848, second occurrence line 875

git remote add radeon-alex git://people.freedesktop.org/~agd5f/linux.git
git remote update radeon-alex
git checkout cf2623d951c1c52923a776e01cf2e2afc9d042a0
vim +845 drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/rv_hwmgr.c

a960d61cb Rex Zhu 2017-05-11  844
a960d61cb Rex Zhu 2017-05-11 @845  static const struct pp_hwmgr_func 
rv_hwmgr_funcs = {
a960d61cb Rex Zhu 2017-05-11  846   .backend_init = rv_hwmgr_backend_init,
a960d61cb Rex Zhu 2017-05-11  847   .backend_fini = rv_hwmgr_backend_fini,
a960d61cb Rex Zhu 2017-05-11 @848   .asic_setup = NULL,
a960d61cb Rex Zhu 2017-05-11  849   .apply_state_adjust_rules = 
rv_apply_state_adjust_rules,
a960d61cb Rex Zhu 2017-05-11  850   .force_dpm_level = 
rv_dpm_force_dpm_level,
a960d61cb Rex Zhu 2017-05-11  851   .get_power_state_size = 
rv_get_power_state_size,
a960d61cb Rex Zhu 2017-05-11  852   .powerdown_uvd = NULL,
a960d61cb Rex Zhu 2017-05-11  853   .powergate_uvd = NULL,
a960d61cb Rex Zhu 2017-05-11  854   .powergate_vce = NULL,
a960d61cb Rex Zhu 2017-05-11  855   .get_mclk = rv_dpm_get_mclk,
a960d61cb Rex Zhu 2017-05-11  856   .get_sclk = rv_dpm_get_sclk,
a960d61cb Rex Zhu 2017-05-11  857   .patch_boot_state = 
rv_dpm_patch_boot_state,
a960d61cb Rex Zhu 2017-05-11  858   .get_pp_table_entry = 
rv_dpm_get_pp_table_entry,
a960d61cb Rex Zhu 2017-05-11  859   .get_num_of_pp_table_entries = 
rv_dpm_get_num_of_pp_table_entries,
a960d61cb Rex Zhu 2017-05-11  860   .set_cpu_power_state = 
rv_set_cpu_power_state,
a960d61cb Rex Zhu 2017-05-11  861   .store_cc6_data = rv_store_cc6_data,
a960d61cb Rex Zhu 2017-05-11  862   .force_clock_level = 
rv_force_clock_level,
a960d61cb Rex Zhu 2017-05-11  863   .print_clock_levels = 
rv_print_clock_levels,
a960d61cb Rex Zhu 2017-05-11  864   .get_dal_power_level = 
rv_get_dal_power_level,
a960d61cb Rex Zhu 2017-05-11  865   .get_performance_level = 
rv_get_performance_level,
a960d61cb Rex Zhu 2017-05-11  866   .get_current_shallow_sleep_clocks = 
rv_get_current_shallow_sleep_clocks,
a960d61cb Rex Zhu 2017-05-11  867   .get_clock_by_type_with_latency = 
rv_get_clock_by_type_with_latency,
a960d61cb Rex Zhu 2017-05-11  868   .get_clock_by_type_with_voltage = 
rv_get_clock_by_type_with_voltage,
a960d61cb Rex Zhu 2017-05-11  869   .get_max_high_clocks = 
rv_get_max_high_clocks,
a960d61cb Rex Zhu 2017-05-11  870   .read_sensor = rv_read_sensor,
841e3be12 Rex Zhu 2017-08-25  871   .set_active_display_count = 
rv_set_active_display_count,
841e3be12 Rex Zhu 2017-08-25  872   .set_deep_sleep_dcefclk = 
rv_set_deep_sleep_dcefclk,
cf2623d95 Rex Zhu 2017-09-04  873   .dynamic_state_management_enable = 
rv_enable_dpm_tasks,
cf2623d95 Rex Zhu 2017-09-04  874   .power_off_asic = rv_power_off_asic,
cf2623d95 Rex Zhu 2017-09-04 @875   .asic_setup = rv_setup_asic_task,
cf2623d95 Rex Zhu 2017-09-04  876   .power_state_set = 
rv_set_power_state_tasks,
cf2623d95 Rex Zhu 2017-09-04  877   .dynamic_state_management_disable = 
rv_disable_dpm_tasks,
a960d61cb Rex Zhu 2017-05-11  878  };
a960d61cb Rex Zhu 2017-05-11  879

:: The code at line 845 was first introduced by commit
:: a960d61cbd62544c04adb4fe6513577601ff4535 drm/amd/powerplay: add raven 
support in hwmgr. (v2)

:: TO: Rex Zhu 
:: CC: Alex Deucher 

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 03/13] drm/sun4i: tcon: Add support for demuxing TCON output on A31

[Chen-Yu Tsai]

On Tue, Sep 26, 2017 at 5:56 PM, Maxime Ripard
 wrote:
> Hi,
>
> On Tue, Sep 26, 2017 at 06:59:09AM +, Chen-Yu Tsai wrote:
>> On systems with 2 TCONs such as the A31, it is possible to demux the
>> output of the TCONs to one encoder.
>>
>> Add support for this for the A31.
>>
>> Signed-off-by: Chen-Yu Tsai 
>> ---
>>  drivers/gpu/drm/sun4i/sun4i_tcon.c | 61 
>> ++
>>  1 file changed, 61 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c 
>> b/drivers/gpu/drm/sun4i/sun4i_tcon.c
>> index e853dfe51389..770b843a6fa9 100644
>> --- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
>> +++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
>> @@ -14,9 +14,12 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>>  #include 
>>  #include 
>>
>> +#include 
>> +
>>  #include 
>>  #include 
>>  #include 
>> @@ -109,11 +112,69 @@ void sun4i_tcon_enable_vblank(struct sun4i_tcon *tcon, 
>> bool enable)
>>  }
>>  EXPORT_SYMBOL(sun4i_tcon_enable_vblank);
>>
>> +static struct sun4i_tcon *sun4i_get_first_tcon(struct drm_device *drm)
>> +{
>> + struct sun4i_drv *drv = drm->dev_private;
>> + struct sun4i_tcon *tcon;
>> +
>> + list_for_each_entry(tcon, >tcon_list, list)
>> + if (tcon->id == 0)
>> + return tcon;
>> +
>> + dev_warn(drm->dev,
>> +  "TCON0 not found, display output muxing may not work\n");
>> +
>> + return tcon;
>> +}
>> +
>> +static int _sun6i_tcon_set_mux(struct drm_encoder *encoder)
>> +{
>> + struct sun4i_tcon *tcon = sun4i_get_first_tcon(encoder->dev);
>> + int tcon_id = drm_crtc_to_sun4i_crtc(encoder->crtc)->tcon->id;
>> + u32 shift;
>> +
>> + DRM_DEBUG_DRIVER("Muxing encoder %s to CRTC %s (TCON %d)\n",
>> +  encoder->name, encoder->crtc->name, tcon_id);
>> +
>> + /* Only 2 TCONs */
>> + if (tcon_id >= 2)
>> + return -EINVAL;
>> +
>> + switch (encoder->encoder_type) {
>> + case DRM_MODE_ENCODER_TMDS:
>> + /* HDMI */
>> + shift = 8;
>> + break;
>> + case DRM_MODE_ENCODER_DSI:
>> + /* No MIPI DSI on A31s */
>> + if (of_device_is_compatible(tcon->dev->of_node,
>> + "allwinner,sun6i-a31s-tcon"))
>
> I'm not sure that test is needed.
>
> We won't end up in that case if we don't have a connected DSI block,
> which isn't going to be the case on the A31. And I guess we can tackle
> DSI later (when I'll send my patches...).

OK. I'll leave a comment instead.

>
>> + return -EINVAL;
>> + shift = 0;
>> + break;
>> + default:
>> + return -EINVAL;
>> + }
>> +
>> + regmap_update_bits(tcon->regs, SUN4I_TCON_MUX_CTRL_REG,
>> +0x3 << shift, tcon_id << shift);
>> +
>> + return 0;
>> +}
>> +
>>  void sun4i_tcon_set_mux(struct sun4i_tcon *tcon, int channel,
>>   struct drm_encoder *encoder)
>>  {
>> + /* Get the device node of the display engine */
>> + struct device_node *node = encoder->dev->dev->of_node;
>>   u32 val;
>>
>> + if (of_device_is_compatible(node, 
>> "allwinner,sun6i-a31-display-engine") ||
>> + of_device_is_compatible(node, 
>> "allwinner,sun6i-a31s-display-engine")) {
>> + _sun6i_tcon_set_mux(encoder);
>> + return;
>> + }
>> +
>
> I'd really like to avoid mix and matching the structure defined
> behaviour and those of_device_is_compatible calls spread out
> everywhere.
>
> You can either add a flag or a function pointer.

Function pointer it is!

ChenYu
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 0/3] Split default display handling out from VGA arbiter

[Daniel Axtens]

Hi Bjorn,

Yes, this works:

Tested-by: Daniel Axtens  # arm64, ppc64-qemu-tcg


Regards,
Daniel
> On Fri, Sep 01, 2017 at 05:27:41PM +1000, Daniel Axtens wrote:
>> This patch set:
>> 
>>  - splits the default display handling out from VGA arbiter, into its
>>own file and behind its own Kconfig option (and gives the functions
>>better names).
>> 
>>  - adds extra detection of default devices. To be nominated, the vga
>>arbiter and platform hooks must not have nominated a default. A
>>card will then only be nominated if it has a driver attached and
>>has IO or memory decoding enabled.
>> 
>>  - adds relevant documentation.
>> 
>> The practical impact of this is improved X autoconfiguration on some
>> arm64 systems.
>
> I think I gave you bad advice about trying to separate the "default
> device" idea from the VGA arbiter.
>
> It is true that the "VGA arbiter" per se is related to routing the
> legacy VGA resources, and the arbiter currently only selects a default
> device if it finds a device to which those resources are routed.
>
> We have some cases where we want to select a default device that may
> not support the legacy VGA resources, or where they might not be
> routed to the device:
>
>   - systems where we match the EFI framebuffer address with a BAR, and
> select that device as default,
>
>   - powerpc systems where there may be no host bridge window that maps
> to the legacy VGA resources,
>
>   - your ARM64 systems where the default device may be behind a bridge
> that doesn't support legacy VGA routing (PCI_BRIDGE_CTL_VGA)
>
> But I think trying to split the "default device" part out from the VGA
> arbiter ends up being overkill and making things more complicated
> instead of simpler.
>
> Would something like the following work for you as well as the powerpc
> case?  On powerpc, we already use vga_set_default_device() to select a
> device that doesn't use legacy VGA resources, so maybe we can just do
> the same on ARM64?
>
> I suppose there might be wrinkles in how the arbiter deals with
> multiple graphics devices on those systems, since I don't think it
> identifies these devices that don't use the legacy resources, but it
> seems like we live with whatever those on are powerpc and probably can
> on ARM64 as well.
>
>
> diff --git a/arch/powerpc/kernel/pci-common.c 
> b/arch/powerpc/kernel/pci-common.c
> index 02831a396419..0ac7aa346c69 100644
> --- a/arch/powerpc/kernel/pci-common.c
> +++ b/arch/powerpc/kernel/pci-common.c
> @@ -1740,15 +1740,3 @@ static void fixup_hide_host_resource_fsl(struct 
> pci_dev *dev)
>  }
>  DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_MOTOROLA, PCI_ANY_ID, 
> fixup_hide_host_resource_fsl);
>  DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_FREESCALE, PCI_ANY_ID, 
> fixup_hide_host_resource_fsl);
> -
> -static void fixup_vga(struct pci_dev *pdev)
> -{
> - u16 cmd;
> -
> - pci_read_config_word(pdev, PCI_COMMAND, );
> - if ((cmd & (PCI_COMMAND_IO | PCI_COMMAND_MEMORY)) || 
> !vga_default_device())
> - vga_set_default_device(pdev);
> -
> -}
> -DECLARE_PCI_FIXUP_CLASS_FINAL(PCI_ANY_ID, PCI_ANY_ID,
> -   PCI_CLASS_DISPLAY_VGA, 8, fixup_vga);
> diff --git a/drivers/gpu/vga/vgaarb.c b/drivers/gpu/vga/vgaarb.c
> index 76875f6299b8..9df4802c5f04 100644
> --- a/drivers/gpu/vga/vgaarb.c
> +++ b/drivers/gpu/vga/vgaarb.c
> @@ -1468,6 +1468,21 @@ static int __init vga_arb_device_init(void)
>   vgaarb_info(dev, "no bridge control possible\n");
>   }
>  
> + if (!vga_default_device()) {
> + list_for_each_entry(vgadev, _list, list) {
> + struct device *dev = >pdev->dev;
> + u16 cmd;
> +
> + pdev = vgadev->pdev;
> + pci_read_config_word(pdev, PCI_COMMAND, );
> + if (cmd & (PCI_COMMAND_IO | PCI_COMMAND_MEMORY)) {
> + vgaarb_info(dev, "setting as boot device\n");
> + vga_set_default_device(pdev);
> + break;
> + }
> + }
> + }
> +
>   pr_info("loaded\n");
>   return rc;
>  }


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 02/13] clk: sunxi-ng: sun6i: Rename HDMI DDC clock to avoid name collision

[Chen-Yu Tsai]

On Tue, Sep 26, 2017 at 5:32 PM, Maxime Ripard
 wrote:
> On Tue, Sep 26, 2017 at 06:59:08AM +, Chen-Yu Tsai wrote:
>> The HDMI DDC clock found in the CCU is the parent of the actual DDC
>> clock within the HDMI controller. That clock is also named "hdmi-ddc".
>>
>> Rename the one in the CCU to "hdmi-ddc-parent". This makes more sense
>> than renaming the one in the HDMI controller to something else.
>>
>> Fixes: c6e6c96d8fa6 ("clk: sunxi-ng: Add A31/A31s clocks")
>> Signed-off-by: Chen-Yu Tsai 
>
> I'd rather stick to the datasheet names. What about "DDC" ?

Works for me.

Thanks
ChenYu
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[pull] amdgpu dc drm-next-4.15-dc

[Alex Deucher]

Hi Dave,

Initial pull request for DC support.  We've completed a substantial amount of
the cleanup and restructuring in our TODO.  There are a few additional
cleanups that we are continuing to work on, but I don't think there are any
showstoppers remaining. We've tried to maintain most of the history for bisect
purposes.  Harry made sure all the commits build.  We've enabled DC for vega10
and Raven.  Pre-vega10 parts can be enabled via module parameter (amdgpu.dc=1),
but are not enabled by default at this point until we get further testing
upstream.

This code provides atomic modesetting support for DCE8 (CIK), DCE10 (Tonga,
Fiji), DCE11 (CZ, ST, Polaris), DCE12 (vega10), and DCN1 (RV) including
HDMI and DP audio, DP MST, and many other advanced display features.

The following changes since commit 6f87a895709eecc1542fe947e349364ad061ac00:

  drm/amdgpu: clarify license in amdgpu_trace_points.c (2017-09-26 15:14:37 
-0400)

are available in the git repository at:

  git://people.freedesktop.org/~agd5f/linux drm-next-4.15-dc

for you to fetch changes up to dfbf0c14dd75d3b15f65478f10f373aa83042a50:

  drm/amdgpu: drop experimental flag for vega10 (2017-09-26 18:17:46 -0400)


AMD\ktsao (1):
  drm/amd/display: remove DCN1 guard as DCN1 is already open sourced.

Alex Deucher (18):
  drm/amd/dc/dm: remove redundant display structs
  drm/amd/display: Enable DCE12 support
  drm/amd/display: Remove DCE12 guards
  drm/amdgpu/soc15: enable dc on vega10
  drm/amd/display: decouple per-crtc-plane model
  drm/amd/display: fix nullptr on vega initialization
  drm/amdgpu/display: Enable DCN in DC
  drm/amdgpu/soc15: enable DC ip module for Raven
  drm/amd/display/dc: Make dce110_validate_bandwidth static (v2)
  drm/amd/display/dc: make dce120_link_encoder_create static
  drm/amd/display/dm: add KV, KB, ML (v2)
  drm/amdgpu: add DCE8 APUs to dc_supported check
  drm/amd/display/dc: add DIGG for KV
  drm/amd/display/dc: add DCE_VERSION for DCE8 APUs
  drm/amd/disply/dc: add resource support for DCE8 APUs (v2)
  drm/amdgpu/cik: add IP modules for DC for APUs
  drm/amdgpu: disable DC on KB/ML for now
  drm/amdgpu: drop experimental flag for vega10

Amy Zhang (19):
  drm/amd/display: Fix Gamma Adjustment
  drm/amd/display: Framework for degamma and regramma through color module
  drm/amd/display: Output Transfer Function Regamma Refactor
  drm/amd/display: Set default degamma to sRGB instead of bypass
  drm/amd/display: HDR Enablement For Applications
  drm/amd/display: Fix Warnings
  drm/amd/display: Add bypass case for PQ transfer function
  drm/amd/display: DMCU PSR Refactor
  drm/amd/display: Simplify some DMCU waits
  drm/amd/display: PSR Aux Channel and Static Screen Support Fix
  drm/amd/display: always retrieve PSR cap
  drm/amd/display: Move output transfer function to stream updates
  drm/amd/display: Program CSC Mode For BT2020
  drm/amd/display: Disable ABM when eDP is disabled
  drm/amd/display: Disable PSR entry abort to prevent intermittent freezes
  drm/amd/display: Add function to get PSR state
  drm/amd/display: Refactor to call set PSR wait loop in dce_dmcu instead 
of dce_clocks
  drm/amd/display: Fix DRR Enable on Desktop
  drm/amd/display: Re-enable Vsync Interrupts for Gradual Refresh Ramp

Andrew Jiang (1):
  drm/amd/display: Fix context alloc failed logging

Andrew Wong (3):
  drm/amd/display: Change locking of registers when flipping frames.
  drm/amd/display: Retrieve windowed fullscreen state
  drm/amd/display: DAL3: HDR10 Infoframe encoding

Andrey Grodzovsky (81):
  drm/amd/display: Fix refcount over dc_sink.
  drm/amd/display: Add refcount debug assert
  drm/amd/display: Pass adev to fill_plane_attr
  drm/amd/display: [MST] Fix startup sequence v3.
  drm/amd/display: Use pflip prepare and submit parts (v2)
  drm/amd/display: Add interrupt entries for VBLANK isr.
  drm/amd/display: Register on VLBLANK ISR.
  drm/amd/display: Clean index in irq init loop
  drm/amd/display: Rename atomic_commit parameter.
  drm/amdgpu: Add a few members to support DAL atomic refactor.
  drm/amd/display: Refactor atomic commit implementation. (v2)
  drm/amd/display: Refactor headless to use atomic commit. (v2)
  drm/amd/display: Remove page_fleep_needed function.
  drm/amd/display: Switch to DRM helpers in s3.
  drm/amd/display: Fix the NULL pointer. (v2)
  drm/amd/display: Fix gfx9 parameters reading for DC.
  drm/amd/display: Unhardcode acrtc->max_cursor_{height,width}
  drm/amd/display: Unhardcode cursor size reported back to UMD.
  drm/amd/display: Set cursor pitch to cursor width (in pixels).
  drm/amd/display: use CRTC_VERTICAL_INTERRUPT0 as VBLANK trigger.
  drm/amd/display: use 

Re: [PATCH v2 2/8] drm/rockchip/dsi: add dual mipi channel support

[Matthias Kaehlcke]

Hi Nickey,

please see my comment inline.

(Note: I'm no export on MIPI DSI in general or this driver/controller
in particular, my reviews of this driver are more focussed on C and
generic kernel stuff, than on the details of the interaction with the
controller)

El Tue, Sep 26, 2017 at 03:55:17PM +0800 Nickey Yang ha dit:

> This patch add dual mipi channel support:
> 1.add definition of dsi1 register and grf operation.
> 2.dsi0 and dsi1 will work in master and slave mode
> when driving dual mipi panel.
> 
> Signed-off-by: Nickey Yang 
> ---
>  drivers/gpu/drm/rockchip/dw-mipi-dsi.c  | 390 
> 
>  drivers/gpu/drm/rockchip/rockchip_drm_drv.h |   1 +
>  drivers/gpu/drm/rockchip/rockchip_drm_vop.c |   2 +
>  drivers/gpu/drm/rockchip/rockchip_drm_vop.h |   3 +
>  4 files changed, 292 insertions(+), 104 deletions(-)
> 
> diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c 
> b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
> index c933a3a..191037c 100644
> --- a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
> +++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
> @@ -39,8 +39,58 @@
>  #define RK3399_DSI1_SEL_VOP_LIT  BIT(4)
>  
>  /* disable turnrequest, turndisable, forcetxstopmode, forcerxmode */
> -#define RK3399_GRF_SOC_CON22 0x6258
> -#define RK3399_GRF_DSI_MODE  0x
> +#define RK3399_GRF_SOC_CON22 0x6258
> +#define DPHY_TX0_TURNREQUEST_SET ((0xf << 12) << 16)
> +#define DPHY_TX0_TURNREQUEST_DISABLE (0x0 << 12)
> +#define DPHY_TX0_TURNREQUEST_ENABLE  (0xf << 12)
> +#define DPHY_TX0_TURNDISABLE_SET ((0xf << 8) << 16)
> +#define DPHY_TX0_TURNDISABLE_DISABLE (0x0 << 8)
> +#define DPHY_TX0_TURNDISABLE_ENABLE  (0xf << 8)
> +#define DPHY_TX0_FORCETXSTOPMODE_SET ((0xf << 4) << 16)
> +#define DPHY_TX0_FORCETXSTOPMODE_DISABLE (0x0 << 4)
> +#define DPHY_TX0_FORCETXSTOPMODE_ENABLE  (0xf << 4)
> +#define DPHY_TX0_FORCETRXMODE_SET((0xf << 0) << 16)
> +#define DPHY_TX0_FORCETRXMODE_DISABLE0x0
> +#define DPHY_TX0_FORCETRXMODE_ENABLE 0xf
> +#define RK3399_GRF_DSI_MODE  ((DPHY_TX0_TURNREQUEST_SET | \
> +  DPHY_TX0_TURNDISABLE_SET | \
> +  DPHY_TX0_FORCETXSTOPMODE_SET | 
> \
> +  DPHY_TX0_FORCETRXMODE_SET) | \
> +  (DPHY_TX0_TURNREQUEST_DISABLE 
> | \
> +  DPHY_TX0_TURNDISABLE_DISABLE | 
> \
> +  
> DPHY_TX0_FORCETXSTOPMODE_DISABLE | \
> +  DPHY_TX0_FORCETRXMODE_DISABLE))
> +
> +
> +/* disable turndisable, forcetxstopmode, forcerxmode, enable */
> +#define RK3399_GRF_SOC_CON23 0x625c
> +#define DPHY_TX1RX1_TURNDISABLE_SET  ((0xf << 12) << 16)
> +#define DPHY_TX1RX1_TURNDISABLE_DISABLE  (0x0 << 12)
> +#define DPHY_TX1RX1_TURNDISABLE_ENABLE   (0xf << 12)
> +#define DPHY_TX1RX1_FORCETXSTOPMODE_SET  ((0xf << 8) << 16)
> +#define DPHY_TX1RX1_FORCETXSTOPMODE_DISABLE  (0x0 << 8)
> +#define DPHY_TX1RX1_FORCETXSTOPMODE_ENABLE   (0xf << 8)
> +#define DPHY_TX1RX1_FORCERXMODE_SET  ((0xf << 4) << 16)
> +#define DPHY_TX1RX1_FORCERXMODE_DISABLE  (0x0 << 4)
> +#define DPHY_TX1RX1_FORCERXMODE_ENABLE   (0xf << 4)
> +#define DPHY_TX1RX1_ENABLE_SET   ((0xf << 0) << 16)
> +#define DPHY_TX1RX1_ENABLE_DISABLE   0x0
> +#define DPHY_TX1RX1_ENABLE_ENABLE0xf
> +#define RK3399_GRF_DSI1_MODE ((DPHY_TX1RX1_TURNDISABLE_SET | 
> \
> +  
> DPHY_TX1RX1_FORCETXSTOPMODE_SET | \
> +  DPHY_TX1RX1_FORCERXMODE_SET | \
> +  DPHY_TX1RX1_ENABLE_SET) | \
> +  (DPHY_TX0_TURNREQUEST_DISABLE 
> | \
> +  DPHY_TX0_TURNDISABLE_DISABLE | 
> \
> +  
> DPHY_TX0_FORCETXSTOPMODE_DISABLE | \
> +  DPHY_TX0_FORCETRXMODE_DISABLE))
> +#define RK3399_GRF_DSI1_ENABLE   
> ((DPHY_TX1RX1_ENABLE_SET | \
> +   DPHY_TX1RX1_ENABLE_ENABLE))
> +
> +#define RK3399_GRF_SOC_CON24 0x6260
> +#define RK3399_TXRX_MASTERSLAVEZ BIT(7)
> +#define RK3399_TXRX_ENABLECLKBIT(6)
> +#define RK3399_TXRX_BASEDIR  BIT(5)
>  
>  #define DSI_VERSION  0x00
>  #define DSI_PWR_UP   0x04
> @@ -304,6 +354,13 @@ struct dw_mipi_dsi_plat_data {
>   u32 grf_switch_reg;
>   u32 grf_dsi0_mode;
>   u32 

Re: [PATCH] drm: Call sysfs_notify after changing drm_connector::dpms

[Karsten Wiese]

2017-09-25 15:48 GMT+02:00 Jani Nikula :

> On Tue, 19 Sep 2017, Karsten Wiese  wrote:
> > This makes poll work for the
> > /sys/class/drm/cardX/connectorY/dpms attributes.
>
> I guess the question is, what are you trying to achieve? What is the
> problem that this solves?
>
​
The patch enables cpu cycle less waiting for dpms flag changes.

Here it lets a screen brightness ​setting daemon know which monitor to
handle.
One of the attached screens gets confused if it is set just after being
switched on,
hence the daemon leaves it untouched until it has been active for some
seconds.

Without the p​atch the daemon would have to actively read the dpms flag
every once in a while.


>
> We have zero sysfs_notify in all of drm AFAICT.


Yes I noticed too and looked for some dbus signal to listen to​ but didn't
find any.

BR,
Karsten

>
> BR,
> Jani.
>
>
> >
> > Tested with i915 suspended by XScreenServer and
> > suspend to RAM.
> >
> > Signed-off-by: Karsten Wiese 
> > ---
> >  drivers/gpu/drm/drm_atomic.c| 4 
> >  drivers/gpu/drm/drm_atomic_helper.c | 6 +-
> >  2 files changed, 9 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> > index 2fd383d..b6fa87b 100644
> > --- a/drivers/gpu/drm/drm_atomic.c
> > +++ b/drivers/gpu/drm/drm_atomic.c
> > @@ -1880,6 +1880,10 @@ int drm_atomic_connector_commit_dpms(struct
> drm_atomic_state *state,
> >  out:
> >   if (ret != 0)
> >   connector->dpms = old_mode;
> > + else
> > + if (connector->dpms != old_mode)
> > + sysfs_notify(>kdev->kobj, NULL,
> "dpms");
> > +
> >   return ret;
> >  }
> >
> > diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> b/drivers/gpu/drm/drm_atomic_helper.c
> > index 4e53aae..6198772 100644
> > --- a/drivers/gpu/drm/drm_atomic_helper.c
> > +++ b/drivers/gpu/drm/drm_atomic_helper.c
> > @@ -921,12 +921,16 @@ drm_atomic_helper_update_legacy_modeset_state(struct
> drm_device *dev,
> >   crtc = new_conn_state->crtc;
> >   if ((!crtc && old_conn_state->crtc) ||
> >   (crtc && drm_atomic_crtc_needs_modeset(crtc->state)))
> {
> > - int mode = DRM_MODE_DPMS_OFF;
> > + int old_mode, mode = DRM_MODE_DPMS_OFF;
> >
> >   if (crtc && crtc->state->active)
> >   mode = DRM_MODE_DPMS_ON;
> >
> > + old_mode = connector->dpms;
> >   connector->dpms = mode;
> > + if (old_mode != mode)
> > + sysfs_notify(>kdev->kobj,
> > + NULL, "dpms");
> >   }
> >   }
>
> --
> Jani Nikula, Intel Open Source Technology Center
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 02/22] drm/i915: introduce simple gemfs

[Greg Kroah-Hartman]

On Tue, Sep 26, 2017 at 04:21:47PM +0300, Joonas Lahtinen wrote:
> On Tue, 2017-09-26 at 09:52 +0200, Greg Kroah-Hartman wrote:
> > On Mon, Sep 25, 2017 at 07:47:17PM +0100, Matthew Auld wrote:
> > > Not a fully blown gemfs, just our very own tmpfs kernel mount. Doing so
> > > moves us away from the shmemfs shm_mnt, and gives us the much needed
> > > flexibility to do things like set our own mount options, namely huge=
> > > which should allow us to enable the use of transparent-huge-pages for
> > > our shmem backed objects.
> > > 
> > > v2: various improvements suggested by Joonas
> > > 
> > > v3: move gemfs instance to i915.mm and simplify now that we have
> > > file_setup_with_mnt
> > > 
> > > v4: fallback to tmpfs shm_mnt upon failure to setup gemfs
> > > 
> > > v5: make tmpfs fallback kinder
> > 
> > Why do this only for one specific driver?  Shouldn't the drm core handle
> > this for you, for all other drivers as well?  Otherwise trying to figure
> > out how to "contain" this type of thing is going to be a pain (mount
> > options, selinux options, etc.)
> 
> We actually started quite grande by making stripped down version of
> shmemfs for drm core, but kept running into nacks about how we were
> implementing it (after getting a recommendation to try implementing it
> some way). After a few iterations and massive engineering time, we have
> been progressively reducing the amount of changes outside i915 in the
> hopes to get this merged.
> 
> And all the while clock is ticking, so we thought the best way to get
> something to support our future work is to implement this first locally
> with minimal external changes outside i915 and then once we have
> something working, it'll be easier to generalize it for the drm core.
> Otherwise we'll never get to work with the huge page support, for which
> gemfs is the stepping stone here.
> 
> So we're not planning on sitting on top of it, we'll just incubate it
> under i915/ so that it'll then be less pain for others to adopt when
> the biggest hurdles with core MM interactions are sorted out.

But by doing this, you are now creating a new user/kernel api that you
have to support for forever, right?  Will it not change if you make it
"generic" to the drm core eventually?

Worse case, name it a generic name that everyone will end up using in
the future, and then you can just claim that all other drivers need to
implement it :)

thanks,

greg k-h
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] [PATCH 1/2] drm/dp: Add defines for latency in sink

[Rodrigo Vivi]

On Tue, Sep 26, 2017 at 1:37 PM, Puthikorn Voravootivat
 wrote:
>
>
> On Tue, Sep 26, 2017 at 10:37 AM, Puthikorn Voravootivat
>  wrote:
>>
>>
>>
>> On Mon, Sep 25, 2017 at 10:11 PM, Daniel Vetter  wrote:
>>>
>>> On Thu, Sep 21, 2017 at 07:42:07AM -0700, Rodrigo Vivi wrote:
>>> > On Wed, Sep 20, 2017 at 02:32:34PM +, vathsala nagaraju wrote:
>>> > > Add defines for dpcd register 2009 (synchronization latency
>>> > > in sink).
>>> > >
>>> > > Cc: Rodrigo Vivi 
>>> > > CC: Puthikorn Voravootivat 
>>> > > Signed-off-by: Vathsala Nagaraju 
>>> >
>>> > I keep forgetting to update my eDP spec 1.4 to this 1.4b...
>>>
>>> Maybe the patch should then make this clear, by annotating it with
>>> /* eDP 1.4b */ That's missing, which isn't all that great really, since
>>> it
>>> makes specs hunts like yours necessary.
>>>
>> It's actually in eDP 1.4 spec, table 5-6 page 86
>
> Copy and paste the wrong one.
> 0x2009 is actually in eDP 1.4 spec, Table 6-7: DPCD – Sink Device PSR Status
> Field page 124

you are absolutely right! eDP 1.4 has it. even the eDP 1.4a had...
I definitely had a strange version here... All updated locally here.

For the patch I will update when merging. No need to send a newer version.
I intend to merge patches tomorrow if no one has any other comment or
concern on those.

>
>>
>>
>>>
>>> Please fix up before applying.
>>> -Daniel
>>> >
>>> >
>>> > Reviewed-by: Rodrigo Vivi 
>>> >
>>> >
>>> >
>>> > > ---
>>> > >  include/drm/drm_dp_helper.h | 3 +++
>>> > >  1 file changed, 3 insertions(+)
>>> > >
>>> > > diff --git a/include/drm/drm_dp_helper.h
>>> > > b/include/drm/drm_dp_helper.h
>>> > > index 11c39f1..846004e6 100644
>>> > > --- a/include/drm/drm_dp_helper.h
>>> > > +++ b/include/drm/drm_dp_helper.h
>>> > > @@ -735,6 +735,9 @@
>>> > >  # define DP_PSR_SINK_INTERNAL_ERROR 7
>>> > >  # define DP_PSR_SINK_STATE_MASK 0x07
>>> > >
>>> > > +#define DP_SINK_SYNCHRONIZATION_LATENCY0x2009
>>> > > +# define DP_MAX_RESYNC_FRAME_CNT_MASK  0xf
>>> > > +
>>> > >  #define DP_RECEIVER_ALPM_STATUS0x200b  /* eDP 1.4 */
>>> > >  # define DP_ALPM_LOCK_TIMEOUT_ERROR(1 << 0)
>>> > >
>>> > > --
>>> > > 1.9.1
>>> > >
>>> > ___
>>> > dri-devel mailing list
>>> > dri-devel@lists.freedesktop.org
>>> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
>>>
>>> --
>>> Daniel Vetter
>>> Software Engineer, Intel Corporation
>>> http://blog.ffwll.ch
>>
>>
>
>
> ___
> Intel-gfx mailing list
> intel-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
>



-- 
Rodrigo Vivi
Blog: http://blog.vivi.eng.br
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 91880] Radeonsi on Grenada cards (r9 390) exceptionally unstable and poorly performing

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=91880

--- Comment #179 from Thomas DEBESSE  ---
Andrea Zanoni, can you print the output of this command?

lspci -nn | grep VGA

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[pull] radeon, amdgpu, ttm drm-next-4.15

[Alex Deucher]

Hi Dave,

First feature pull for 4.15.  Highlights:
- Per VM BO support
- Lots of powerplay cleanups
- Powerplay support for CI
- pasid mgr for kfd
- interrupt infrastructure for recoverable page faults
- SR-IOV fixes
- initial GPU reset for vega10
- prime mmap support
- ttm page table debugging improvements
- lots of bug fixes

The following changes since commit 7846b12fe0b5feab5446d892f41b5140c1419109:

  Merge branch 'drm-vmwgfx-next' of 
git://people.freedesktop.org/~syeh/repos_linux into drm-next (2017-08-29 
10:38:14 +1000)

are available in the git repository at:

  git://people.freedesktop.org/~agd5f/linux drm-next-4.15

for you to fetch changes up to 6f87a895709eecc1542fe947e349364ad061ac00:

  drm/amdgpu: clarify license in amdgpu_trace_points.c (2017-09-26 15:14:37 
-0400)


Alex Deucher (14):
  drm/amdgpu/gfx8: fix spelling typo in mqd allocation
  drm/amdgpu: add automatic per asic settings for gart_size
  drm/amdgpu: refine default gart size
  drm/amdgpu: move default gart size setting into gmc modules
  drm/amdgpu: set sched_hw_submission higher for KIQ (v3)
  drm/amdgpu/powerplay/vega10: fix typo in register base index
  drm/amdgpu/gfx8: apply dynamic cu mask to APUs as well
  drm/amdgpu/gfx8: drop cz mqd
  drm/amdgpu/gfx9: update mqd to include dynamic CU mask
  drm/amdgpu/gfx9: adjust mqd allocation size
  drm/amd/powerplay: fix sclk setting for profile mode for CZ/ST
  drm/amdgpu/gfx9: properly set the hdp flush reg for Raven
  drm/amdgpu/psp: declare raven psp firmware
  drm/amdgpu: clarify license in amdgpu_trace_points.c

Allen Pais (1):
  drivers:gpu:Use ARRAY_SIZE() for the size calculation of the array.

Arnd Bergmann (1):
  drm/radeon: properly initialize r600_audio_status() data

Bas Nieuwenhuizen (1):
  drm/amdgpu: Account for shadow PTs in mapping update IB size.

Christian König (45):
  drm/amdgpu: fix and cleanup shadow handling
  drm/amdgpu: discard commands of killed processes
  drm/amdgpu: remove the GART copy hack
  drm/amdgpu: fix amdgpu_ttm_bind
  drm/amdgpu: inline amdgpu_ttm_do_bind again
  drm/amdgpu: fix amdgpu_vm_bo_map trace point
  drm/amdgpu: fix and cleanup VM ready check
  drm/amdgpu: cleanup GWS, GDS and OA allocation
  drm/amdgpu: rework moved handling in the VM v2
  drm/amdgpu: add bo_va cleared flag again v2
  drm/amdgpu: fix comment on amdgpu_bo_va
  drm/amdgpu: track evicted page tables v2
  drm/amdgpu: rework page directory filling v2
  drm/amdgpu: cleanup the VM code a bit more
  drm/amdgpu: move hw generation check into amdgpu_doorbell_init v2
  drm/amdgpu: fix new PD update code for Vega10 v2
  drm/amdgpu: restrict userptr even more
  drm/amdgpu: add support for per VM BOs v2
  drm/amdgpu: add IOCTL interface for per VM BOs v3
  drm/amdgpu: bump version for support of local BOs
  drm/amdgpu: fix moved list handling in the VM
  drm/amdgpu: fix placement flags in amdgpu_ttm_bind
  drm/amdgpu: fix userptr put_page handling
  drm/amdgpu: revert "fix deadlock of reservation between cs and gpu reset 
v2"
  drm/ttm: fix ttm_bo_cleanup_refs_or_queue once more
  drm/amdgpu: move taking mmap_sem into get_user_pages v2
  drm/amdgpu: stop using BO status for user pages
  drm/amdgpu: move userptr BOs to CPU domain during CS v2
  drm/amdgpu: use a rw_semaphore for MMU notifiers
  drm/amdgpu: stop reserving the BO in the MMU callback v3
  drm/ttm: allow mapping BOs while they are still on the swap list
  drm/amdgpu: move amdgpu_cs_sysvm_access_required into find_mapping
  drm/amdgpu: rework amdgpu_cs_find_mapping
  drm/amdgpu: keep the MMU lock until the update ends v4
  drm/amdgpu: move amdgpu_ttm_tt_* declarations into amdgpu_ttm.h
  drm/amdgpu: move MMU notifier related defines to amdgpu_mn.h
  drm/amdgpu: fix VM sync with always valid BOs v2
  drm/amdgpu: fix amdgpu_vm_handle_moved as well v2
  drm/amdgpu: fix cgs alignment handling
  drm/amd: remove min/max addr handling from cgs
  drm/amdgpu: fix and cleanup amdgpu_bo_create v2
  drm/ttm: fix memory leak while individualizing BOs
  drm/ttm: cleanup ttm_page_alloc_dma.c
  drm/amdgpu: use 2MB fragment size for GFX6,7 and 8
  drm/amdgpu: simplify pinning into visible VRAM

Christophe JAILLET (1):
  drm/amdgpu: check memory allocation failure

Colin Ian King (1):
  drm/amdgpu: remove duplicate return statement

Emily Deng (1):
  drm/amdgpu/virtual_dce: Virtual display doesn't support disable vblank 
immediately

Eric Huang (4):
  drm/amdgpu: add cgs query info of pci bus devfn
  drm/amd/powerplay: add register thermal interrupt in hwmgr_hw_init
  drm/amd/powerplay: implement register thermal interrupt for Vega10
  drm/amd/powerplay: change alert temperature range

Evan Quan 

Re: [PATCH] radeon and amdgpu drm-fixes-4.14

[Alex Deucher]

Whoops. subject should say [pull].

Alex

On Tue, Sep 26, 2017 at 3:33 PM, Alex Deucher  wrote:
> Hi Dave,
>
> A few fixes for 4.14.  Nothing too major.
>
> The following changes since commit 47e0cd6b1dbbbff7591fe7eecc20bac5ca674351:
>
>   Merge branch 'drm-next-4.14' of git://people.freedesktop.org/~agd5f/linux 
> into drm-next (2017-09-13 14:34:11 +1000)
>
> are available in the git repository at:
>
>   git://people.freedesktop.org/~agd5f/linux drm-fixes-4.14
>
> for you to fetch changes up to 820608548737e315c6f93e3099b4e65bde062334:
>
>   drm/radeon: disable hard reset in hibernate for APUs (2017-09-15 11:55:27 
> -0400)
>
> 
> Alex Deucher (1):
>   drm/radeon: disable hard reset in hibernate for APUs
>
> Jean Delvare (1):
>   drm/amdgpu: revert tile table update for oland
>
>  drivers/gpu/drm/amd/amdgpu/gfx_v6_0.c  | 189 
> -
>  drivers/gpu/drm/radeon/radeon_device.c |   2 +-
>  2 files changed, 189 insertions(+), 2 deletions(-)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] radeon and amdgpu drm-fixes-4.14

[Alex Deucher]

Hi Dave,

A few fixes for 4.14.  Nothing too major.

The following changes since commit 47e0cd6b1dbbbff7591fe7eecc20bac5ca674351:

  Merge branch 'drm-next-4.14' of git://people.freedesktop.org/~agd5f/linux 
into drm-next (2017-09-13 14:34:11 +1000)

are available in the git repository at:

  git://people.freedesktop.org/~agd5f/linux drm-fixes-4.14

for you to fetch changes up to 820608548737e315c6f93e3099b4e65bde062334:

  drm/radeon: disable hard reset in hibernate for APUs (2017-09-15 11:55:27 
-0400)


Alex Deucher (1):
  drm/radeon: disable hard reset in hibernate for APUs

Jean Delvare (1):
  drm/amdgpu: revert tile table update for oland

 drivers/gpu/drm/amd/amdgpu/gfx_v6_0.c  | 189 -
 drivers/gpu/drm/radeon/radeon_device.c |   2 +-
 2 files changed, 189 insertions(+), 2 deletions(-)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: XDC 2017 feedback

[Manasi Navare]

Hi,

XDC was a really great conference and loved the fact that it was
in just one room which kept all the hallway conversations in that room resulting
into more networking.
But I agree with Andres that for the videos, it would be great to split the
huge youtube video stream per presentation and have seperate links for each
talk somewhere on the XDC page.

Regards
Manasi



On Tue, Sep 26, 2017 at 01:25:15PM -0400, Andres Rodriguez wrote:
> Hi,
> 
> A small piece of feedback from those of us watching remotely. It would be
> nice to have a simple to access index for the long livestream videos.
> 
> I think the XDC 2017 wiki page would be a good place for this information. A
> brief example:
> 
> Presentation Title | Presenter Name | Link with timestamp
> ---||-
> ...| ...| youtu.be/video-id?t=XhYmZs
> 
> Or alternatively, a list of hyperlinks with the presentation title as text
> that point to the correct timestamp in the video would also be sufficient.
> 
> Really enjoyed the talks, and would like them to be slightly easier to
> access and share with others.
> 
> Regards,
> Andres
> 
> 
> On 2017-09-26 12:57 PM, Daniel Vetter wrote:
> >Hi all,
> >
> >First again big thanks to Stéphane and Jennifer for organizing a great XDC.
> >
> >Like last year we'd like to hear feedback on how this year's XDC went,
> >both the good (and what you'd like to see more of) and the not so
> >good. Talk selection, organization, location, scheduling of talks,
> >anything really.
> >
> >Here's a few things we took into account from Helsinki and tried to apply:
> >- More breaks for more hallway track.
> >- Try to schedule the hot topics on the first day (did we pick the
> >right ones) for better hallway track.
> >- More lightning talk time to give all the late/rejected submissions
> >some place to give a quick showcase.
> >
> >Things that didn't work out perfectly this year and that we'll try to
> >get better at next year:
> >- Lots of people missed the submission deadline and their talks were
> >rejected only because of that. We'll do better PR by sending out a
> >pile of reminders.
> >- Comparitively few people asked for travel assistance. No idea
> >whether this was a year with more budget around, or whether this isn't
> >all that well know and we need to make more PR in maybe the call for
> >papers about it.
> >
> >But that's just the stuff we've gathered already, we'd like to hear
> >more feedback. Just reply to this mail or send a mail to
> >bo...@foundation.x.org if you don't want the entire world to read it.
> >And if you want to send at pseudonymous feedback, drop a pastebin onto
> >the #xf-bod channel on the OFTC irc server.
> >
> >Thanks, Daniel
> >
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v4 2/2] staging: ion: create one device entry per heap

[Laura Abbott]

On 09/26/2017 09:17 AM, Mark Brown wrote:

On Tue, Sep 26, 2017 at 02:07:05PM +0200, Benjamin Gaignard wrote:


version 4:
- add a configuration flag to switch between legacy Ion misc device
   and one device per heap version.


Should this be a switch or should it just be enabling and disabling the
legacy device with the per heap ones always availalbe?  I can't see that
the new devices would do any harm or have trouble interacting with the
per heap ones.  Being able to have both enabled would make things easier
for userspaces that are moving to the device per heap interface.



Agreed. We should be enabling the new interface unconditionally. The
old /dev/ion interface should coexist to allow for backwards
compatibility but keep it under a Kconfig to allow it to be turned off
for security or other reasons.

Thanks,
Laura
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 2/2] staging: ion: create one device entry per heap

[Laura Abbott]

On 09/25/2017 11:56 PM, Greg KH wrote:

On Tue, Sep 26, 2017 at 07:09:14AM +0200, Daniel Vetter wrote:

On Mon, Sep 25, 2017 at 11:26:27AM -0700, Laura Abbott wrote:

On 09/20/2017 01:45 AM, Benjamin Gaignard wrote:

Instead a getting one common device "/dev/ion" for
all the heaps this patch allow to create one device
entry ("/dev/ionX") per heap.
Getting an entry per heap could allow to set security rules
per heap and global ones for all heaps.

Allocation requests will be only allowed if the mask_id
match with device minor.
Query request could be done on any of the devices.
Deivce node major will also change and that may impact init scripts.



We should start Cc linux-api for future changes since we're going
to have more than just /dev/ion.

Thinking about this some more, I think we need to allow backwards
compatibility. It's just not feasible to keep throwing workarounds
into userspace if we can avoid it. I'd propose keeping the old /dev/ion
misc interface available under a Kconfig and then creating the new
split heaps in parallel.

On a somewhat related note, there was some interest in possibly
having a sysfs interface for Ion long term. I don't think this
needs to happen right now but I'd like whatever we do to not
make adding that harder.


Not sure sysfs is a good idea for allocating buffers. The backlight
interface is in sysfs, which defacto makes it a root-only interface.
Distros really hate that, because it makes unpriviledged X/wayland really
hard to pull of. Passing a device file otoh from logind to the compositor
is dead simple (and how X et al get at e.g. the drm/input devices
already).


sysfs is not a good idea for allocating buffers.  We already have some
out-of-tree drm drivers doing horrid things in sysfs in ways that
totally abuse that api, and vendors have to do crazy things with selinux
rules to try to lock it down because of that.  A device node is fine, we
are used to that for graphics stuff :)

thanks,

greg k-h



I wasn't thinking of sysfs for allocation, this was for exposure of
other Ion information that might make more sense than debugfs. Like
I said, this was mostly forward thinking to make sure we aren't
stuck later.

Thanks,
Laura
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: XDC 2017 feedback

[Andres Rodriguez]

Hi,

A small piece of feedback from those of us watching remotely. It would 
be nice to have a simple to access index for the long livestream videos.


I think the XDC 2017 wiki page would be a good place for this 
information. A brief example:


Presentation Title | Presenter Name | Link with timestamp
---||-
...| ...| youtu.be/video-id?t=XhYmZs

Or alternatively, a list of hyperlinks with the presentation title as 
text that point to the correct timestamp in the video would also be 
sufficient.


Really enjoyed the talks, and would like them to be slightly easier to 
access and share with others.


Regards,
Andres


On 2017-09-26 12:57 PM, Daniel Vetter wrote:

Hi all,

First again big thanks to Stéphane and Jennifer for organizing a great XDC.

Like last year we'd like to hear feedback on how this year's XDC went,
both the good (and what you'd like to see more of) and the not so
good. Talk selection, organization, location, scheduling of talks,
anything really.

Here's a few things we took into account from Helsinki and tried to apply:
- More breaks for more hallway track.
- Try to schedule the hot topics on the first day (did we pick the
right ones) for better hallway track.
- More lightning talk time to give all the late/rejected submissions
some place to give a quick showcase.

Things that didn't work out perfectly this year and that we'll try to
get better at next year:
- Lots of people missed the submission deadline and their talks were
rejected only because of that. We'll do better PR by sending out a
pile of reminders.
- Comparitively few people asked for travel assistance. No idea
whether this was a year with more budget around, or whether this isn't
all that well know and we need to make more PR in maybe the call for
papers about it.

But that's just the stuff we've gathered already, we'd like to hear
more feedback. Just reply to this mail or send a mail to
bo...@foundation.x.org if you don't want the entire world to read it.
And if you want to send at pseudonymous feedback, drop a pastebin onto
the #xf-bod channel on the OFTC irc server.

Thanks, Daniel


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

XDC 2017 feedback

[Daniel Vetter]

Hi all,

First again big thanks to Stéphane and Jennifer for organizing a great XDC.

Like last year we'd like to hear feedback on how this year's XDC went,
both the good (and what you'd like to see more of) and the not so
good. Talk selection, organization, location, scheduling of talks,
anything really.

Here's a few things we took into account from Helsinki and tried to apply:
- More breaks for more hallway track.
- Try to schedule the hot topics on the first day (did we pick the
right ones) for better hallway track.
- More lightning talk time to give all the late/rejected submissions
some place to give a quick showcase.

Things that didn't work out perfectly this year and that we'll try to
get better at next year:
- Lots of people missed the submission deadline and their talks were
rejected only because of that. We'll do better PR by sending out a
pile of reminders.
- Comparitively few people asked for travel assistance. No idea
whether this was a year with more budget around, or whether this isn't
all that well know and we need to make more PR in maybe the call for
papers about it.

But that's just the stuff we've gathered already, we'd like to hear
more feedback. Just reply to this mail or send a mail to
bo...@foundation.x.org if you don't want the entire world to read it.
And if you want to send at pseudonymous feedback, drop a pastebin onto
the #xf-bod channel on the OFTC irc server.

Thanks, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v4 2/2] staging: ion: create one device entry per heap

[Mark Brown]

On Tue, Sep 26, 2017 at 02:07:05PM +0200, Benjamin Gaignard wrote:

> version 4:
> - add a configuration flag to switch between legacy Ion misc device
>   and one device per heap version.

Should this be a switch or should it just be enabling and disabling the
legacy device with the per heap ones always availalbe?  I can't see that
the new devices would do any harm or have trouble interacting with the 
per heap ones.  Being able to have both enabled would make things easier
for userspaces that are moving to the device per heap interface.


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/4] drm/amd/powerplay: Cocci spatch "alloc_cast"

[Alex Deucher]

On Thu, Sep 21, 2017 at 2:33 AM, Thomas Meyer  wrote:
> Remove casting the values returned by memory allocation functions like
> kmalloc, kzalloc, kmem_cache_alloc, kmem_cache_zalloc etc."
> Found by coccinelle spatch "api/alloc/alloc_cast.cocci"
>
> Signed-off-by: Thomas Meyer 
> ---
>
> diff -u -p a/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_processpptables.c 
> b/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_processpptables.c
> --- a/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_processpptables.c
> +++ b/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_processpptables.c
> @@ -291,7 +291,7 @@ static int get_mm_clock_voltage_table(
> table_size = sizeof(uint32_t) +
> sizeof(phm_ppt_v1_mm_clock_voltage_dependency_record) 
> *
> mm_dependency_table->ucNumEntries;
> -   mm_table = (phm_ppt_v1_mm_clock_voltage_dependency_table *)
> +   mm_table =
> kzalloc(table_size, GFP_KERNEL);

Please fix up the whitespace.  E.g.,
 mm_table = kzalloc(table_size, GFP_KERNEL);

Alex


>
> if (!mm_table)
> @@ -519,7 +519,7 @@ static int get_socclk_voltage_dependency
> sizeof(phm_ppt_v1_clock_voltage_dependency_record) *
> clk_dep_table->ucNumEntries;
>
> -   clk_table = (phm_ppt_v1_clock_voltage_dependency_table *)
> +   clk_table =
> kzalloc(table_size, GFP_KERNEL);
>
> if (!clk_table)
> @@ -554,7 +554,7 @@ static int get_mclk_voltage_dependency_t
> sizeof(phm_ppt_v1_clock_voltage_dependency_record) *
> mclk_dep_table->ucNumEntries;
>
> -   mclk_table = (phm_ppt_v1_clock_voltage_dependency_table *)
> +   mclk_table =
> kzalloc(table_size, GFP_KERNEL);
>
> if (!mclk_table)
> @@ -596,7 +596,7 @@ static int get_gfxclk_voltage_dependency
> sizeof(phm_ppt_v1_clock_voltage_dependency_record) *
> clk_dep_table->ucNumEntries;
>
> -   clk_table = (struct phm_ppt_v1_clock_voltage_dependency_table *)
> +   clk_table =
> kzalloc(table_size, GFP_KERNEL);
>
> if (!clk_table)
> @@ -663,7 +663,7 @@ static int get_pix_clk_voltage_dependenc
> sizeof(phm_ppt_v1_clock_voltage_dependency_record) *
> clk_dep_table->ucNumEntries;
>
> -   clk_table = (struct phm_ppt_v1_clock_voltage_dependency_table *)
> +   clk_table =
> kzalloc(table_size, GFP_KERNEL);
>
> if (!clk_table)
> @@ -728,7 +728,7 @@ static int get_dcefclk_voltage_dependenc
> sizeof(phm_ppt_v1_clock_voltage_dependency_record) *
> num_entries;
>
> -   clk_table = (struct phm_ppt_v1_clock_voltage_dependency_table *)
> +   clk_table =
> kzalloc(table_size, GFP_KERNEL);
>
> if (!clk_table)
> @@ -772,7 +772,7 @@ static int get_pcie_table(struct pp_hwmg
> sizeof(struct phm_ppt_v1_pcie_record) *
> atom_pcie_table->ucNumEntries;
>
> -   pcie_table = (struct phm_ppt_v1_pcie_table *)
> +   pcie_table =
> kzalloc(table_size, GFP_KERNEL);
>
> if (!pcie_table)
> @@ -1026,7 +1026,7 @@ static int get_vddc_lookup_table(
> table_size = sizeof(uint32_t) +
> sizeof(phm_ppt_v1_voltage_lookup_record) * max_levels;
>
> -   table = (phm_ppt_v1_voltage_lookup_table *)
> +   table =
> kzalloc(table_size, GFP_KERNEL);
>
> if (NULL == table)
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: RFC: page-flip with damage?

[Thomas Hellstrom]

On 09/26/2017 01:18 AM, Daniel Vetter wrote:

On Sun, Sep 24, 2017 at 07:41:45PM +0200, Thomas Hellstrom wrote:

Hi, list!

Page flips, while efficient on real hardware, aren't that efficient in other
situations, like for virtual devices with local, or even worse, remote
desktops.
We might ending up forwarding or encoding a couple of full frames worth of
data instead of a small region at a cursor blink.

Now there is this extension EGL_KHR_swap_buffers_with_damage, and
gnome-shell/wayland on KMS also has a damage region that it forwards all the
way down to the function where page-flip is called.

So I'd like to start looking at page-flips with damage, meaning that the
damage is an optional hint to the device about what part of the contents is
actually updated. What would be the best way to implement this? I figure
this can be done within the atomic context with a region attached to the
plane state? Would we want to follow the EGL extension and forward an array
of rects or for simplicity use a single bounding box? Both these options
would be a great win.

So my rough plan for all this was:

- Add damage to drm_crtc_state, in screen coordinates. I think this is the
   most natural place for this, since it's what PSR/manual upload DSI want.
   It should also fit well for udl and tinydrm.  Virtual drivers like
   vmwgfx might need helpers to wrap this back to framebuffer rectangles,
   but that seems the odd case out - the framebuffer-based approach in the
   DIRTY_IOCTL forces most drivers to do a fancy lookup from fb to the
   crtc.

   Per-plane dirty rectangle seems to be an awkward in-betwen state, with
   all the confusion about whether it's pre/post scaled and how to best
   combine them. And then someone changes the background color of the crtc
   (or something like that), what happens then? I think pushing all that
   onto userspace is best, it can always ask for a complete flip if it's
   unclear whether it damaged the entire screen or not.

- Add a helper to the atomic core to implement fb_funcs->dirty on top of
   this new atomic state, so that drivers don't have to implement both the
   frontbuffer and the pageflip version of the _with_damage update. Just
   doing a flip (or an async one, if the driver supports that) should work
   well I think.


Sounds fine with me. I think the DIRTY_IOCTL was designed with 
user-space in mind. Typically
userspace has easier access to what part of the framebuffer was dirtied 
than to which parts
of all crtcs scanning out of the framebuffer were dirtied. But even 
vmwgfx eventually

translates this to crtc rects so I'm OK with that.


Wrt single dirty rect vs. rectlist: I'd opt for a single rect since that
makes the interface easier. Currently most drivers collapes the list
passed to fb_funcs->dirty to a single rect, so that seems good enough, and
a nice simplification of the interface (both uapi and driver).


I think multiple cliprects had its benefits for old X type rendering: 
Frontbuffer-type diagonal
lines benchmarked with x11perf and similar. Now that everybody's 
compositing that use-case is mostly gone, and as you say
most driver coalesce anyway. Even we to some extent, at least on newer 
"hardware" versions.




Wrt enabling this on the legacy pageflip ioctl: I wouldn't bother, since
all drivers we reasonable care about are atomic already. One exception is
amdgpu, but that's going to be fixed soonish by merging the DC branch I
hope.

There's definitely lots of people who want to see this happen, that part
is for sure.


Great.


-Daniel



If anybody's already doing this or has code to share, please let me 
know. Or for that matter if somebody needs this stuff faster than 
vmwgfx's moderate development pace :).


/Thomas


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v3] drm: exynos: Add driver for HDMI audio interface

[Sylwester Nawrocki]

The hdmi-codec interface added in this patch is required to properly
support HDMI audio. Currently the audio part of the SoC internal
HDMI transmitter is configured with fixed values, which makes HDMI
audio working by chance, only on boards having an external audio
codec connected in parallel with the HDMI audio transmitter's input
I2S interface.

Signed-off-by: Sylwester Nawrocki 
Reviewed-by: Andrzej Hajda 

---
Tested on Odroid XU3 and Odroid XU4 with Ubuntu 14.04.

Changes since v2:
 - u8 replaced with bool type,
 - the  HDMI codec iec.status data used directly for setting up
   the HDMI controller registers rather than using hard coded
   constants,
 - constants used for configuring the HDMI_AUI_CON register
   instead of plain numbers,
 - if/IS_ERR/return replaced with PTR_ERR_OR_ZERO().

Changes since v1:
 - rebased onto v4.14-rc1 and adapted locking

Changes since RFC version:
 - fixed hdmi-codec locking issue
 - added a comment documenting struct hdmi_contex::mutex
---
 drivers/gpu/drm/exynos/Kconfig   |   1 +
 drivers/gpu/drm/exynos/exynos_hdmi.c | 253 ++-
 drivers/gpu/drm/exynos/regs-hdmi.h   |   8 +-
 3 files changed, 197 insertions(+), 65 deletions(-)

diff --git a/drivers/gpu/drm/exynos/Kconfig b/drivers/gpu/drm/exynos/Kconfig
index 305dc3d..5a7c9d8 100644
--- a/drivers/gpu/drm/exynos/Kconfig
+++ b/drivers/gpu/drm/exynos/Kconfig
@@ -3,6 +3,7 @@ config DRM_EXYNOS
depends on OF && DRM && (ARCH_S3C64XX || ARCH_EXYNOS || 
ARCH_MULTIPLATFORM)
select DRM_KMS_HELPER
select VIDEOMODE_HELPERS
+   select SND_SOC_HDMI_CODEC if SND_SOC
help
  Choose this option if you have a Samsung SoC EXYNOS chipset.
  If M is selected the module will be called exynosdrm.
diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c 
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index 214fa5e..d2b389a 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -40,7 +40,7 @@
 #include 
 #include 
 #include 
-
+#include 
 #include 

 #include 
@@ -111,12 +111,18 @@ struct hdmi_driver_data {
struct string_array_spec clk_muxes;
 };

+struct hdmi_audio {
+   struct platform_device  *pdev;
+   struct hdmi_audio_infoframe infoframe;
+   struct hdmi_codec_paramsparams;
+   boolenable;
+};
+
 struct hdmi_context {
struct drm_encoder  encoder;
struct device   *dev;
struct drm_device   *drm_dev;
struct drm_connectorconnector;
-   boolpowered;
booldvi_mode;
struct delayed_work hotplug_work;
struct drm_display_mode current_mode;
@@ -137,6 +143,11 @@ struct hdmi_context {
struct regulator*reg_hdmi_en;
struct exynos_drm_clk   phy_clk;
struct drm_bridge   *bridge;
+
+   /* mutex protecting subsequent fields below */
+   struct mutexmutex;
+   struct hdmi_audio   audio;
+   boolpowered;
 };

 static inline struct hdmi_context *encoder_to_hdmi(struct drm_encoder *e)
@@ -768,6 +779,22 @@ static int hdmi_clk_set_parents(struct hdmi_context 
*hdata, bool to_phy)
return ret;
 }

+static int hdmi_audio_infoframe_apply(struct hdmi_context *hdata)
+{
+   struct hdmi_audio_infoframe *infoframe = >audio.infoframe;
+   u8 buf[HDMI_INFOFRAME_SIZE(AUDIO)];
+   int len;
+
+   len = hdmi_audio_infoframe_pack(infoframe, buf, sizeof(buf));
+   if (len < 0)
+   return len;
+
+   hdmi_reg_writeb(hdata, HDMI_AUI_CON, HDMI_AUI_CON_EVERY_VSYNC);
+   hdmi_reg_write_buf(hdata, HDMI_AUI_HEADER0, buf, len);
+
+   return 0;
+}
+
 static void hdmi_reg_infoframes(struct hdmi_context *hdata)
 {
union hdmi_infoframe frm;
@@ -805,15 +832,7 @@ static void hdmi_reg_infoframes(struct hdmi_context *hdata)
hdmi_reg_write_buf(hdata, HDMI_VSI_DATA(0), buf + 3, ret - 3);
}

-   ret = hdmi_audio_infoframe_init();
-   if (!ret) {
-   frm.audio.channels = 2;
-   ret = hdmi_audio_infoframe_pack(, buf, sizeof(buf));
-   }
-   if (ret > 0) {
-   hdmi_reg_writeb(hdata, HDMI_AUI_CON, HDMI_AUI_CON_EVERY_VSYNC);
-   hdmi_reg_write_buf(hdata, HDMI_AUI_HEADER0, buf, ret);
-   }
+   hdmi_audio_infoframe_apply(hdata);
 }

 static enum drm_connector_status hdmi_detect(struct drm_connector *connector,
@@ -995,23 +1014,18 @@ static void hdmi_reg_acr(struct hdmi_context *hdata, u32 
freq)
hdmi_reg_writeb(hdata, HDMI_ACR_CON, 4);
 }

-static void hdmi_audio_init(struct hdmi_context *hdata)
+static void hdmi_audio_config(struct hdmi_context *hdata)
 {
-   u32 sample_rate, bits_per_sample;
-   

Re: [PATCH v2 7/8] arm64: dts: rockchip: add a grf clk for dw-mipi-dsi

[Heiko Stuebner]

Am Dienstag, 26. September 2017, 15:55:22 CEST schrieb Nickey Yang:
> The clk of grf must be enabled before writing grf
> register for rk3399.
> 
> Signed-off-by: Nickey Yang 

applied as fix for 4.14


Thanks
Heiko
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 6/8] arm64: dts: rockchip: rk3399: Correct MIPI DPHY PLL clock

[Heiko Stuebner]

Am Dienstag, 26. September 2017, 15:55:21 CEST schrieb Nickey Yang:
> Mipi-dphy's ref_clk connect to clk_dphy_pll inside rk3399.
> clk_24m -> Gate11[14] -> clk_mipidphy_ref -> Gate21[0] -> clk_dphy_pll
> So correct it.
> 
> Signed-off-by: Nickey Yang 

I've already applied this patch from the previous version.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2] drm/tinydrm: Move backlight helpers to a separate file

[Noralf Trønnes]

Den 26.09.2017 15.06, skrev Noralf Trønnes:


Den 26.09.2017 13.32, skrev Daniel Vetter:

On Tue, Sep 26, 2017 at 04:46:53PM +0530, Meghana Madhyastha wrote:

On Mon, Sep 25, 2017 at 06:31:58PM +0200, Noralf Trønnes wrote:

Den 25.09.2017 16.56, skrev Noralf Trønnes:

Hi Meghana,


Den 22.09.2017 17.09, skrev Meghana Madhyastha:

Move backlight helpers from tinydrm-helpers.c to
tinydrm-backlight.c. This is because it is organizationally
simpler to understand and advantageous to group functions
performing a similar function to a separate file as opposed to
having one helper file with heteregenous helper functions.

Signed-off-by: Meghana Madhyastha 
---

I don't think there is much gain in just moving the code like this.

The idea is to add a drm_backlight helper that can be useful for all
DRM drivers that use the backlight subsystem.

Yes I agree. That definitely makes more sense.

The full path to that helper would be:
drivers/gpu/drm/drm_backlight.c


This is what the TODO says:
https://dri.freedesktop.org/docs/drm/gpu/todo.html#tinydrm

- backlight helpers, probably best to put them into a new 
drm_backlight.c.
   This is because drivers/video is de-facto unmaintained. We 
could also
   move drivers/video/backlight to drivers/gpu/backlight and take 
it all

   over within drm-misc, but that’s more work.

There is also this discussion to take into account:
KMS backlight ABI proposition
https://lists.freedesktop.org/archives/dri-devel/2017-February/133206.html 




I don't remember what came out of that discussion.

Noralf.

After having discussed this with Daniel on the #dri-devel irc channel,
here are some of the points suggested.

Daniel suggested that I first look into the usage of shared backlight
helpers in drm (specifically backlight_update_status to begin with). 
The idea
was to see whether there is any pattern in usage and/or code 
dupication.
If there is, then the next step would be to write helper functions 
which

can be used by other drivers (and not just tinydrm).

To start with, I went through the instances of backlight_update_status
in the drm code, and made the following observations(most of them are
very simple/naive observations).

- backlight_update_status is usually called in backlight init (and
   sometimes exit) functions of the drivers just after the device is 
registered.
   So backlight_update_status is called with the registered device 
as the

   parameter.

Here are the following cases of properties changed/set before
backlight_update_status is called.

- CASE 1: Brightness is changed (either a macro BRIGHTNESS_MAX_LEVEL 
100
   is defined or it is manually set) This happens in the following 
files:


   gma500/cdv_device.c, gma500/mdfld_device.c, 
gma500/oaktrail_device.c,
   gma500/psb_device.c, noveau/noveau_backlight.c(here brightness is 
determined by fuction

   static int nv50_get_intensity)

- CASE 2: Power property is set (to FB_BLANK_UNBLANK mostly)
   This happens in the following files:

   omapdrm/displays/panel-dpi.c, panel/panel-innolux-p079zca.c,
   panel/panel-jdi-lt070me05000.c, panel/panel-sharp-lq101r1sx01.c,
   panel/panel-sharp-ls043t1le01.c, tilcdc/tilcdc_panel.c
   - CASE 3: State is set
   This happens in the following files:

   tinydrm/tinydrm-helpers.c

- CASE 4: Power and brightness properties are set
   This happens in the following files:

   atombios_encoders.c, radeon/radeon_legacy_encoders.c,
   shmobile/shmob_drm_backlight.c

- CASE 5: Power and the state properties are set
   This happens in the following files:

   panel/panel-lvds.c, panel/panel-panasonic-vvx10f034n00.c,
   panel/panel-simple.c, panel/panel-sitronix-st7789v.c

Please let me know if I am wrong / missed something. As for next steps,
wouldn't it be an overkill to have a separate helper function for each
of these cases ? Perhaps a generic helper function which would somehow
address these cases would be more appropriate ? Thank you for your
time/patience.

I suspect that a lot of these combinations are just plain wrong, but
happen to kinda work with the combination of gpu driver and backlight
driver they're used on. tbh I have no idea which one is the correct
version for enabling a backlight correctly ...

So definitely a good task to refactor this into a proper helper, but 
looks

a lot more involved than at first sight.


Backlight is tricky.

One annoying thing from a DRM point of view is that it's tied to fbdev
with a notifier fb_notifier_callback() that turns it off on
FB_EVENT_BLANK and FB_EVENT_CONBLANK. And the logic in that function is
very convoluted.

And if we look at the gpio backlight driver, we see that there are
3 properties that turn off the backlight:

static int gpio_backlight_update_status(struct backlight_device *bl)
{
    struct gpio_backlight *gbl = bl_get_data(bl);
    int brightness = bl->props.brightness;

    if (bl->props.power != FB_BLANK_UNBLANK ||
        bl->props.fb_blank != FB_BLANK_UNBLANK ||
        

Re: [PATCH 02/22] drm/i915: introduce simple gemfs

[Joonas Lahtinen]

On Tue, 2017-09-26 at 09:52 +0200, Greg Kroah-Hartman wrote:
> On Mon, Sep 25, 2017 at 07:47:17PM +0100, Matthew Auld wrote:
> > Not a fully blown gemfs, just our very own tmpfs kernel mount. Doing so
> > moves us away from the shmemfs shm_mnt, and gives us the much needed
> > flexibility to do things like set our own mount options, namely huge=
> > which should allow us to enable the use of transparent-huge-pages for
> > our shmem backed objects.
> > 
> > v2: various improvements suggested by Joonas
> > 
> > v3: move gemfs instance to i915.mm and simplify now that we have
> > file_setup_with_mnt
> > 
> > v4: fallback to tmpfs shm_mnt upon failure to setup gemfs
> > 
> > v5: make tmpfs fallback kinder
> 
> Why do this only for one specific driver?  Shouldn't the drm core handle
> this for you, for all other drivers as well?  Otherwise trying to figure
> out how to "contain" this type of thing is going to be a pain (mount
> options, selinux options, etc.)

We actually started quite grande by making stripped down version of
shmemfs for drm core, but kept running into nacks about how we were
implementing it (after getting a recommendation to try implementing it
some way). After a few iterations and massive engineering time, we have
been progressively reducing the amount of changes outside i915 in the
hopes to get this merged.

And all the while clock is ticking, so we thought the best way to get
something to support our future work is to implement this first locally
with minimal external changes outside i915 and then once we have
something working, it'll be easier to generalize it for the drm core.
Otherwise we'll never get to work with the huge page support, for which
gemfs is the stepping stone here.

So we're not planning on sitting on top of it, we'll just incubate it
under i915/ so that it'll then be less pain for others to adopt when
the biggest hurdles with core MM interactions are sorted out.

Regards, Joonas
-- 
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2] drm/tinydrm: Move backlight helpers to a separate file

[Noralf Trønnes]

Den 26.09.2017 13.32, skrev Daniel Vetter:

On Tue, Sep 26, 2017 at 04:46:53PM +0530, Meghana Madhyastha wrote:

On Mon, Sep 25, 2017 at 06:31:58PM +0200, Noralf Trønnes wrote:

Den 25.09.2017 16.56, skrev Noralf Trønnes:

Hi Meghana,


Den 22.09.2017 17.09, skrev Meghana Madhyastha:

Move backlight helpers from tinydrm-helpers.c to
tinydrm-backlight.c. This is because it is organizationally
simpler to understand and advantageous to group functions
performing a similar function to a separate file as opposed to
having one helper file with heteregenous helper functions.

Signed-off-by: Meghana Madhyastha 
---

I don't think there is much gain in just moving the code like this.

The idea is to add a drm_backlight helper that can be useful for all
DRM drivers that use the backlight subsystem.

Yes I agree. That definitely makes more sense.

The full path to that helper would be:
drivers/gpu/drm/drm_backlight.c


This is what the TODO says:
https://dri.freedesktop.org/docs/drm/gpu/todo.html#tinydrm

- backlight helpers, probably best to put them into a new drm_backlight.c.
   This is because drivers/video is de-facto unmaintained. We could also
   move drivers/video/backlight to drivers/gpu/backlight and take it all
   over within drm-misc, but that’s more work.

There is also this discussion to take into account:
KMS backlight ABI proposition
https://lists.freedesktop.org/archives/dri-devel/2017-February/133206.html


I don't remember what came out of that discussion.

Noralf.

After having discussed this with Daniel on the #dri-devel irc channel,
here are some of the points suggested.

Daniel suggested that I first look into the usage of shared backlight
helpers in drm (specifically backlight_update_status to begin with). The idea
was to see whether there is any pattern in usage and/or code dupication.
If there is, then the next step would be to write helper functions which
can be used by other drivers (and not just tinydrm).

To start with, I went through the instances of backlight_update_status
in the drm code, and made the following observations(most of them are
very simple/naive observations).

- backlight_update_status is usually called in backlight init (and
   sometimes exit) functions of the drivers just after the device is registered.
   So backlight_update_status is called with the registered device as the
   parameter.

Here are the following cases of properties changed/set before
backlight_update_status is called.

- CASE 1: Brightness is changed (either a macro BRIGHTNESS_MAX_LEVEL 100
   is defined or it is manually set) This happens in the following files:

   gma500/cdv_device.c, gma500/mdfld_device.c, gma500/oaktrail_device.c,
   gma500/psb_device.c, noveau/noveau_backlight.c(here brightness is determined 
by fuction
   static int nv50_get_intensity)

- CASE 2: Power property is set (to FB_BLANK_UNBLANK mostly)
   This happens in the following files:

   omapdrm/displays/panel-dpi.c, panel/panel-innolux-p079zca.c,
   panel/panel-jdi-lt070me05000.c, panel/panel-sharp-lq101r1sx01.c,
   panel/panel-sharp-ls043t1le01.c, tilcdc/tilcdc_panel.c
   
- CASE 3: State is set

   This happens in the following files:

   tinydrm/tinydrm-helpers.c

- CASE 4: Power and brightness properties are set
   This happens in the following files:

   atombios_encoders.c, radeon/radeon_legacy_encoders.c,
   shmobile/shmob_drm_backlight.c

- CASE 5: Power and the state properties are set
   This happens in the following files:

   panel/panel-lvds.c, panel/panel-panasonic-vvx10f034n00.c,
   panel/panel-simple.c, panel/panel-sitronix-st7789v.c

Please let me know if I am wrong / missed something. As for next steps,
wouldn't it be an overkill to have a separate helper function for each
of these cases ? Perhaps a generic helper function which would somehow
address these cases would be more appropriate ? Thank you for your
time/patience.

I suspect that a lot of these combinations are just plain wrong, but
happen to kinda work with the combination of gpu driver and backlight
driver they're used on. tbh I have no idea which one is the correct
version for enabling a backlight correctly ...

So definitely a good task to refactor this into a proper helper, but looks
a lot more involved than at first sight.


Backlight is tricky.

One annoying thing from a DRM point of view is that it's tied to fbdev
with a notifier fb_notifier_callback() that turns it off on
FB_EVENT_BLANK and FB_EVENT_CONBLANK. And the logic in that function is
very convoluted.

And if we look at the gpio backlight driver, we see that there are
3 properties that turn off the backlight:

static int gpio_backlight_update_status(struct backlight_device *bl)
{
    struct gpio_backlight *gbl = 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_SUSPENDED | BL_CORE_FBBLANK))
        brightness 

Re: [PATCH v2] drm/tinydrm: Move backlight helpers to a separate file

[Meghana Madhyastha]

On Tue, Sep 26, 2017 at 01:32:15PM +0200, Daniel Vetter wrote:
> On Tue, Sep 26, 2017 at 04:46:53PM +0530, Meghana Madhyastha wrote:
> > On Mon, Sep 25, 2017 at 06:31:58PM +0200, Noralf Trønnes wrote:
> > > 
> > > Den 25.09.2017 16.56, skrev Noralf Trønnes:
> > > >Hi Meghana,
> > > >
> > > >
> > > >Den 22.09.2017 17.09, skrev Meghana Madhyastha:
> > > >>Move backlight helpers from tinydrm-helpers.c to
> > > >>tinydrm-backlight.c. This is because it is organizationally
> > > >>simpler to understand and advantageous to group functions
> > > >>performing a similar function to a separate file as opposed to
> > > >>having one helper file with heteregenous helper functions.
> > > >>
> > > >>Signed-off-by: Meghana Madhyastha 
> > > >>---
> > > >
> > > >I don't think there is much gain in just moving the code like this.
> > > >
> > > >The idea is to add a drm_backlight helper that can be useful for all
> > > >DRM drivers that use the backlight subsystem.
> > 
> > Yes I agree. That definitely makes more sense.
> > > 
> > > The full path to that helper would be:
> > > drivers/gpu/drm/drm_backlight.c
> > > 
> > > >This is what the TODO says:
> > > >https://dri.freedesktop.org/docs/drm/gpu/todo.html#tinydrm
> > > >
> > > >- backlight helpers, probably best to put them into a new 
> > > >drm_backlight.c.
> > > >  This is because drivers/video is de-facto unmaintained. We could also
> > > >  move drivers/video/backlight to drivers/gpu/backlight and take it all
> > > >  over within drm-misc, but that’s more work.
> > > >
> > > >There is also this discussion to take into account:
> > > >KMS backlight ABI proposition
> > > >https://lists.freedesktop.org/archives/dri-devel/2017-February/133206.html
> > > >
> > > >
> > > >I don't remember what came out of that discussion.
> > > >
> > > >Noralf.
> > 
> > After having discussed this with Daniel on the #dri-devel irc channel, 
> > here are some of the points suggested.
> > 
> > Daniel suggested that I first look into the usage of shared backlight
> > helpers in drm (specifically backlight_update_status to begin with). The 
> > idea
> > was to see whether there is any pattern in usage and/or code dupication.
> > If there is, then the next step would be to write helper functions which
> > can be used by other drivers (and not just tinydrm). 
> > 
> > To start with, I went through the instances of backlight_update_status
> > in the drm code, and made the following observations(most of them are
> > very simple/naive observations).
> > 
> > - backlight_update_status is usually called in backlight init (and
> >   sometimes exit) functions of the drivers just after the device is 
> > registered.
> >   So backlight_update_status is called with the registered device as the
> >   parameter.
> > 
> > Here are the following cases of properties changed/set before 
> > backlight_update_status is called.
> > 
> > - CASE 1: Brightness is changed (either a macro BRIGHTNESS_MAX_LEVEL 100
> >   is defined or it is manually set) This happens in the following files:
> > 
> >   gma500/cdv_device.c, gma500/mdfld_device.c, gma500/oaktrail_device.c,
> >   gma500/psb_device.c, noveau/noveau_backlight.c(here brightness is 
> > determined by fuction
> >   static int nv50_get_intensity)
> > 
> > - CASE 2: Power property is set (to FB_BLANK_UNBLANK mostly)
> >   This happens in the following files:
> > 
> >   omapdrm/displays/panel-dpi.c, panel/panel-innolux-p079zca.c,
> >   panel/panel-jdi-lt070me05000.c, panel/panel-sharp-lq101r1sx01.c, 
> >   panel/panel-sharp-ls043t1le01.c, tilcdc/tilcdc_panel.c
> >   
> > - CASE 3: State is set
> >   This happens in the following files:
> > 
> >   tinydrm/tinydrm-helpers.c
> > 
> > - CASE 4: Power and brightness properties are set
> >   This happens in the following files:
> > 
> >   atombios_encoders.c, radeon/radeon_legacy_encoders.c, 
> >   shmobile/shmob_drm_backlight.c
> > 
> > - CASE 5: Power and the state properties are set
> >   This happens in the following files:
> > 
> >   panel/panel-lvds.c, panel/panel-panasonic-vvx10f034n00.c,
> >   panel/panel-simple.c, panel/panel-sitronix-st7789v.c
> > 
> > Please let me know if I am wrong / missed something. As for next steps,
> > wouldn't it be an overkill to have a separate helper function for each
> > of these cases ? Perhaps a generic helper function which would somehow
> > address these cases would be more appropriate ? Thank you for your
> > time/patience.
> 
> I suspect that a lot of these combinations are just plain wrong, but
> happen to kinda work with the combination of gpu driver and backlight
> driver they're used on. tbh I have no idea which one is the correct
> version for enabling a backlight correctly ...

So does this mean that different devices require different combinations
in order to enable a backlight ? Is it wrong or is it just that it
depends on the gpu driver ?

> So definitely a good task to refactor this into a proper helper, but looks
> a lot more involved 

[PATCH v4 2/2] staging: ion: create one device entry per heap

[Benjamin Gaignard]

Instead a getting one common device "/dev/ion" for
all the heaps this patch allow to create one device
entry ("/dev/ionX") per heap.
Getting an entry per heap could allow to set security rules
per heap and global ones for all heaps.

Allocation requests will be only allowed if the mask_id
match with device minor.
Query request could be done on any of the devices.

Signed-off-by: Benjamin Gaignard 
---
version 4:
- add a configuration flag to switch between legacy Ion misc device
  and one device per heap version.

version 3:
- change ion_device_add_heap prototype to return a possible error.

version 2:
- simplify ioctl check like propose by Dan
- make sure that we don't register more than ION_DEV_MAX heaps.

 drivers/staging/android/TODO|  1 -
 drivers/staging/android/ion/Kconfig |  8 
 drivers/staging/android/ion/ion-ioctl.c | 16 ++--
 drivers/staging/android/ion/ion.c   | 29 +++--
 drivers/staging/android/ion/ion.h   | 18 +-
 5 files changed, 66 insertions(+), 6 deletions(-)

diff --git a/drivers/staging/android/TODO b/drivers/staging/android/TODO
index 5f14247..d770ffa 100644
--- a/drivers/staging/android/TODO
+++ b/drivers/staging/android/TODO
@@ -9,7 +9,6 @@ TODO:
 ion/
  - Add dt-bindings for remaining heaps (chunk and carveout heaps). This would
involve putting appropriate bindings in a memory node for Ion to find.
- - Split /dev/ion up into multiple nodes (e.g. /dev/ion/heap0)
  - Better test framework (integration with VGEM was suggested)
 
 Please send patches to Greg Kroah-Hartman  and Cc:
diff --git a/drivers/staging/android/ion/Kconfig 
b/drivers/staging/android/ion/Kconfig
index a517b2d..6bb07f6 100644
--- a/drivers/staging/android/ion/Kconfig
+++ b/drivers/staging/android/ion/Kconfig
@@ -10,6 +10,14 @@ menuconfig ION
  If you're not using Android its probably safe to
  say N here.
 
+config ION_ONE_DEVICE_ENTRY_PER_HEAP
+   bool "Create one Ion device per heap"
+   depends on ION
+   help
+ Choose this option to have one device entry per heap. Each
+ device with named "/dev/ionX" where X is heap ID.
+ Selecting this option remove the legacy Ion misc device.
+
 config ION_SYSTEM_HEAP
bool "Ion system heap"
depends on ION
diff --git a/drivers/staging/android/ion/ion-ioctl.c 
b/drivers/staging/android/ion/ion-ioctl.c
index e26b786..76492cc 100644
--- a/drivers/staging/android/ion/ion-ioctl.c
+++ b/drivers/staging/android/ion/ion-ioctl.c
@@ -25,7 +25,8 @@ union ion_ioctl_arg {
struct ion_heap_query query;
 };
 
-static int validate_ioctl_arg(unsigned int cmd, union ion_ioctl_arg *arg)
+static int validate_ioctl_arg(struct file *filp,
+ unsigned int cmd, union ion_ioctl_arg *arg)
 {
switch (cmd) {
case ION_IOC_HEAP_QUERY:
@@ -34,6 +35,17 @@ static int validate_ioctl_arg(unsigned int cmd, union 
ion_ioctl_arg *arg)
arg->query.reserved2 )
return -EINVAL;
break;
+
+#ifdef CONFIG_ION_ONE_DEVICE_ENTRY_PER_HEAP
+   case ION_IOC_ALLOC:
+   {
+   int mask = 1 << iminor(filp->f_inode);
+
+   if (!(arg->allocation.heap_id_mask & mask))
+   return -EINVAL;
+   break;
+   }
+#endif
default:
break;
}
@@ -69,7 +81,7 @@ long ion_ioctl(struct file *filp, unsigned int cmd, unsigned 
long arg)
if (copy_from_user(, (void __user *)arg, _IOC_SIZE(cmd)))
return -EFAULT;
 
-   ret = validate_ioctl_arg(cmd, );
+   ret = validate_ioctl_arg(filp, cmd, );
if (WARN_ON_ONCE(ret))
return ret;
 
diff --git a/drivers/staging/android/ion/ion.c 
b/drivers/staging/android/ion/ion.c
index 93e2c90..18a20d2 100644
--- a/drivers/staging/android/ion/ion.c
+++ b/drivers/staging/android/ion/ion.c
@@ -40,6 +40,10 @@
 
 #include "ion.h"
 
+#ifdef CONFIG_ION_ONE_DEVICE_ENTRY_PER_HEAP
+#define ION_DEV_MAX 32
+#endif
+
 static struct ion_device *internal_dev;
 static int heap_id;
 
@@ -537,15 +541,30 @@ static int debug_shrink_get(void *data, u64 *val)
 DEFINE_SIMPLE_ATTRIBUTE(debug_shrink_fops, debug_shrink_get,
debug_shrink_set, "%llu\n");
 
-void ion_device_add_heap(struct ion_heap *heap)
+int ion_device_add_heap(struct ion_heap *heap)
 {
struct dentry *debug_file;
struct ion_device *dev = internal_dev;
+   int ret = 0;
 
if (!heap->ops->allocate || !heap->ops->free)
pr_err("%s: can not add heap with invalid ops struct.\n",
   __func__);
 
+#ifdef CONFIG_ION_ONE_DEVICE_ENTRY_PER_HEAP
+   if (heap_id >= ION_DEV_MAX)
+   return -EBUSY;
+
+   heap->ddev.devt = MKDEV(MAJOR(dev->devt), heap_id);
+   dev_set_name(>ddev, "ion%d", heap_id);
+   device_initialize(>ddev);
+ 

[PATCH v4 1/2] staging: ion: simplify ioctl args checking function

[Benjamin Gaignard]

Make arguments checking more easy to read.

Signed-off-by: Benjamin Gaignard 
---
 drivers/staging/android/ion/ion-ioctl.c | 11 +--
 1 file changed, 5 insertions(+), 6 deletions(-)

diff --git a/drivers/staging/android/ion/ion-ioctl.c 
b/drivers/staging/android/ion/ion-ioctl.c
index d9f8b14..e26b786 100644
--- a/drivers/staging/android/ion/ion-ioctl.c
+++ b/drivers/staging/android/ion/ion-ioctl.c
@@ -27,19 +27,18 @@ union ion_ioctl_arg {
 
 static int validate_ioctl_arg(unsigned int cmd, union ion_ioctl_arg *arg)
 {
-   int ret = 0;
-
switch (cmd) {
case ION_IOC_HEAP_QUERY:
-   ret = arg->query.reserved0 != 0;
-   ret |= arg->query.reserved1 != 0;
-   ret |= arg->query.reserved2 != 0;
+   if (arg->query.reserved0 ||
+   arg->query.reserved1 ||
+   arg->query.reserved2 )
+   return -EINVAL;
break;
default:
break;
}
 
-   return ret ? -EINVAL : 0;
+   return 0;
 }
 
 /* fix up the cases where the ioctl direction bits are incorrect */
-- 
2.7.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v4 0/2] staging: ion: get one device per heap

[Benjamin Gaignard]

version 4:
- add a configuration flag to switch between legacy Ion misc device
  and one device per heap version.
  This change has been suggested after Laura talks at XDC 2017.

version 3:
- change ion_device_add_heap prototype to return a possible error.

version 2:
- simplify ioctl check like propose by Dan
- make sure that we don't register more than ION_DEV_MAX heaps.

Until now all ion heaps are addressing using the same device "/dev/ion".
This way of working doesn't allow to give access rights (for example with
SElinux rules) per heap.
This series propose to have (under configuartion flag) one device "/dev/ionX"
per heap. Query heaps informations will be possible on each device node but
allocation request will only be possible if heap_mask_id match with device 
minor number.

That enable  thsi new flag change Ion ABI because:
- device name change
- allocation must be done on the correct device/heap.
- device major number will not be the same and that could impact init scripts.

Benjamin Gaignard (2):
  staging: ion: simplify ioctl args checking function
  staging: ion: create one device entry per heap

 drivers/staging/android/TODO|  1 -
 drivers/staging/android/ion/Kconfig |  8 
 drivers/staging/android/ion/ion-ioctl.c | 27 +++
 drivers/staging/android/ion/ion.c   | 29 +++--
 drivers/staging/android/ion/ion.h   | 18 +-
 5 files changed, 71 insertions(+), 12 deletions(-)

-- 
2.7.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Kernel GPU subsytem: Better manual upload for atomic

[Harsha Sharma]

Hello,
I am working on task "Better manual upload for atomic" in kernel gpu
subsystem.
When duplicating the crtc state I need to change drm_rect x2 and y2 to
MAX_INT.
I didn't get what is MAX_INT over here. Also, how am I supposed to test my
code?
It will be really helpful if you can suggest something.
Thanks a lot for your time.

Regards,
Harsha Sharma
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 1/2] drm: introduce drm_dev_{get/put} functions

[Aishwarya Pant]

Reference counting functions in the kernel typically use get/put suffixes. For
maintaining coding style consistency, introduce drm_dev_{get/put} functions. All
callers of drm_dev_ref() API have been converted in this patch and hence it has
been dropped while the drm_dev_unref() API with non-trivial number of users
remains for compatibility.

The semantic patch scripts/coccinelle/api/drm-get-put.cocci has been updated
with the new helper for conversion of drm_dev_unref() to drm_dev_put()

Signed-off-by: Aishwarya Pant 
---
Changes in v2
- Drop drm_dev_ref after replacing all its usages
- Update the drm subsystem wide cocci script drm-get-put with the new helper for
  drm_dev_unref to drm_dev_get conversion

 drivers/gpu/drm/drm_drv.c| 51 
 drivers/gpu/drm/drm_prime.c  |  2 +-
 include/drm/drm_drv.h|  5 ++--
 scripts/coccinelle/api/drm-get-put.cocci |  5 
 4 files changed, 41 insertions(+), 22 deletions(-)

diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index be38ac7..c0292e5 100644
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/drm/drm_drv.c
@@ -286,13 +286,13 @@ struct drm_minor *drm_minor_acquire(unsigned int minor_id)
spin_lock_irqsave(_minor_lock, flags);
minor = idr_find(_minors_idr, minor_id);
if (minor)
-   drm_dev_ref(minor->dev);
+   drm_dev_get(minor->dev);
spin_unlock_irqrestore(_minor_lock, flags);
 
if (!minor) {
return ERR_PTR(-ENODEV);
} else if (drm_dev_is_unplugged(minor->dev)) {
-   drm_dev_unref(minor->dev);
+   drm_dev_put(minor->dev);
return ERR_PTR(-ENODEV);
}
 
@@ -301,7 +301,7 @@ struct drm_minor *drm_minor_acquire(unsigned int minor_id)
 
 void drm_minor_release(struct drm_minor *minor)
 {
-   drm_dev_unref(minor->dev);
+   drm_dev_put(minor->dev);
 }
 
 /**
@@ -326,11 +326,11 @@ void drm_minor_release(struct drm_minor *minor)
  * When cleaning up a device instance everything needs to be done in reverse:
  * First unpublish the device instance with drm_dev_unregister(). Then clean up
  * any other resources allocated at device initialization and drop the driver's
- * reference to _device using drm_dev_unref().
+ * reference to _device using drm_dev_put().
  *
  * Note that the lifetime rules for _device instance has still a lot of
  * historical baggage. Hence use the reference counting provided by
- * drm_dev_ref() and drm_dev_unref() only carefully.
+ * drm_dev_get() and drm_dev_put() only carefully.
  *
  * It is recommended that drivers embed  drm_device into their own 
device
  * structure, which is supported through drm_dev_init().
@@ -345,7 +345,7 @@ void drm_minor_release(struct drm_minor *minor)
  * Cleans up all DRM device, calling drm_lastclose().
  *
  * Note: Use of this function is deprecated. It will eventually go away
- * completely.  Please use drm_dev_unregister() and drm_dev_unref() explicitly
+ * completely.  Please use drm_dev_unregister() and drm_dev_put() explicitly
  * instead to make sure that the device isn't userspace accessible any more
  * while teardown is in progress, ensuring that userspace can't access an
  * inconsistent state.
@@ -360,7 +360,7 @@ void drm_put_dev(struct drm_device *dev)
}
 
drm_dev_unregister(dev);
-   drm_dev_unref(dev);
+   drm_dev_put(dev);
 }
 EXPORT_SYMBOL(drm_put_dev);
 
@@ -386,7 +386,7 @@ void drm_dev_unplug(struct drm_device *dev)
mutex_lock(_global_mutex);
drm_device_set_unplugged(dev);
if (dev->open_count == 0)
-   drm_dev_unref(dev);
+   drm_dev_put(dev);
mutex_unlock(_global_mutex);
 }
 EXPORT_SYMBOL(drm_dev_unplug);
@@ -475,8 +475,8 @@ static void drm_fs_inode_free(struct inode *inode)
  * initialization sequence to make sure userspace can't access an inconsistent
  * state.
  *
- * The initial ref-count of the object is 1. Use drm_dev_ref() and
- * drm_dev_unref() to take and drop further ref-counts.
+ * The initial ref-count of the object is 1. Use drm_dev_get() and
+ * drm_dev_put() to take and drop further ref-counts.
  *
  * Note that for purely virtual devices @parent can be NULL.
  *
@@ -626,8 +626,8 @@ EXPORT_SYMBOL(drm_dev_fini);
  * initialization sequence to make sure userspace can't access an inconsistent
  * state.
  *
- * The initial ref-count of the object is 1. Use drm_dev_ref() and
- * drm_dev_unref() to take and drop further ref-counts.
+ * The initial ref-count of the object is 1. Use drm_dev_get() and
+ * drm_dev_put() to take and drop further ref-counts.
  *
  * Note that for purely virtual devices @parent can be NULL.
  *
@@ -670,36 +670,49 @@ static void drm_dev_release(struct kref *ref)
 }
 
 /**
- * drm_dev_ref - Take reference of a DRM device
+ * drm_dev_get - Take reference of a DRM device
  * @dev: device to take reference of or NULL
  *
  * 

[PATCH v2 0/2] drm/tilcdc: replace reference/unreference with get/put

[Aishwarya Pant]

This patchset introduces drm_dev_get() and drm_dev_put() functions that are
intented to be replacements for drm_dev_{ref/unref}.

Then all usages of ref/reference and unref/unreference suffixes are replaced by
get/put reference count functions in tilcdc. The following cocci script was used
to make the tilcdc patch:

@@
expression ex;
@@

(
-drm_framebuffer_unreference(ex);
+drm_framebuffer_put(ex);
|
-drm_dev_unref(ex);
+drm_dev_put(ex);
|
-drm_framebuffer_reference(ex);
+drm_framebuffer_get(ex);
)

Changes in v2
- Drop drm_dev_ref after replacing all its usages
- Update the drm subsystem wide cocci script drm-get-put with the new helper for
  drm_dev_unref to drm_dev_get conversion

Aishwarya Pant (2):
  drm: introduce drm_dev_{get/put} functions
  drm/tilcdc: replace reference/unreference() with get/put

 drivers/gpu/drm/drm_drv.c| 51 
 drivers/gpu/drm/drm_prime.c  |  2 +-
 drivers/gpu/drm/tilcdc/tilcdc_crtc.c |  6 ++--
 drivers/gpu/drm/tilcdc/tilcdc_drv.c  |  2 +-
 include/drm/drm_drv.h|  5 ++--
 scripts/coccinelle/api/drm-get-put.cocci |  5 
 6 files changed, 45 insertions(+), 26 deletions(-)

-- 
2.7.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 2/2] drm/tilcdc: replace reference/unreference() with get/put

[Aishwarya Pant]

For maintaining consistency with kernel coding style replace
reference/unreference in ref counting functions with get/put.

The following cocci script was used to generate the tilcdc patch:

@@
expression ex;
@@

(
-drm_framebuffer_unreference(ex);
+drm_framebuffer_put(ex);
|
-drm_dev_unref(ex);
+drm_dev_put(ex);
|
-drm_framebuffer_reference(ex);
+drm_framebuffer_get(ex);
)

Signed-off-by: Aishwarya Pant 
---
No changes in v2

drivers/gpu/drm/tilcdc/tilcdc_crtc.c | 6 +++---
 drivers/gpu/drm/tilcdc/tilcdc_drv.c  | 2 +-
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c 
b/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
index 406fe45..d2589f310 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
@@ -75,7 +75,7 @@ static void unref_worker(struct drm_flip_work *work, void 
*val)
struct drm_device *dev = tilcdc_crtc->base.dev;
 
mutex_lock(>mode_config.mutex);
-   drm_framebuffer_unreference(val);
+   drm_framebuffer_put(val);
mutex_unlock(>mode_config.mutex);
 }
 
@@ -456,7 +456,7 @@ static void tilcdc_crtc_set_mode(struct drm_crtc *crtc)
 
set_scanout(crtc, fb);
 
-   drm_framebuffer_reference(fb);
+   drm_framebuffer_get(fb);
 
crtc->hwmode = crtc->state->adjusted_mode;
 }
@@ -633,7 +633,7 @@ int tilcdc_crtc_update_fb(struct drm_crtc *crtc,
return -EBUSY;
}
 
-   drm_framebuffer_reference(fb);
+   drm_framebuffer_get(fb);
 
crtc->primary->fb = fb;
tilcdc_crtc->event = event;
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_drv.c 
b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
index b0d70f9..74276ef 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_drv.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
@@ -225,7 +225,7 @@ static void tilcdc_fini(struct drm_device *dev)
 
pm_runtime_disable(dev->dev);
 
-   drm_dev_unref(dev);
+   drm_dev_put(dev);
 }
 
 static int tilcdc_init(struct drm_driver *ddrv, struct device *dev)
-- 
2.7.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Outreachy kernel] [PATCH] drm/gem: use new idr deletion interface to cleanup drm_gem_handle_delete()

[Aishwarya Pant]

On Tue, Sep 26, 2017 at 10:20:47AM +0200, Daniel Vetter wrote:
> On Tue, Sep 26, 2017 at 12:17:28AM +0530, Aishwarya Pant wrote:
> > The IDR deletion interface now returns the deleted entry or NULL if it was 
> > not
> > present. So we don't have to do the extra work of checking if we have a
> > reference on the drm_gem_object, this can be handled by checking the return
> > value from idr_remove() and the extra locks can be dropped.
> > 
> > Signed-off-by: Aishwarya Pant 
> 
> Haneen is already working on this task, with the patch just merged. Please
> coordinate with mentors (me or Sean Paul) before starting on something to
> avoid such clashes in the future.

Apologies for the mix-up, I'll make sure to check in with the mentors before
starting a task.

I looked over the other patch sent by Haneen today, there is one thing that I
could use some clarity on. I'm not sure how the -this is gross- comment is
obsolete since we can drop the check to idr_replace() and use the return value
from idr_remove() which seems neater in my opinion.

> 
> Note also that some todo items are just ideas, and need confirmation with
> relevant maintainers first.
> 
> Thanks, Daniel
> > ---
> >  drivers/gpu/drm/drm_gem.c | 21 ++---
> >  1 file changed, 2 insertions(+), 19 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
> > index c55f338..f62757a 100644
> > --- a/drivers/gpu/drm/drm_gem.c
> > +++ b/drivers/gpu/drm/drm_gem.c
> > @@ -282,29 +282,12 @@ drm_gem_handle_delete(struct drm_file *filp, u32 
> > handle)
> >  {
> > struct drm_gem_object *obj;
> >  
> > -   /* This is gross. The idr system doesn't let us try a delete and
> > -* return an error code.  It just spews if you fail at deleting.
> > -* So, we have to grab a lock around finding the object and then
> > -* doing the delete on it and dropping the refcount, or the user
> > -* could race us to double-decrement the refcount and cause a
> > -* use-after-free later.  Given the frequency of our handle lookups,
> > -* we may want to use ida for number allocation and a hash table
> > -* for the pointers, anyway.
> > -*/
> > spin_lock(>table_lock);
> > -
> > -   /* Check if we currently have a reference on the object */
> > -   obj = idr_replace(>object_idr, NULL, handle);
> > -   spin_unlock(>table_lock);
> > -   if (IS_ERR_OR_NULL(obj))
> > +   obj = idr_remove(>object_idr, handle);
> > +   if (!obj)
> > return -EINVAL;
> > -
> > /* Release driver's reference and decrement refcount. */
> > drm_gem_object_release_handle(handle, obj, filp);
> > -
> > -   /* And finally make the handle available for future allocations. */
> > -   spin_lock(>table_lock);
> > -   idr_remove(>object_idr, handle);
> > spin_unlock(>table_lock);
> >  
> > return 0;
> > -- 
> > 2.7.4
> > 
> > -- 
> > You received this message because you are subscribed to the Google Groups 
> > "outreachy-kernel" group.
> > To unsubscribe from this group and stop receiving emails from it, send an 
> > email to outreachy-kernel+unsubscr...@googlegroups.com.
> > To post to this group, send email to outreachy-ker...@googlegroups.com.
> > To view this discussion on the web visit 
> > https://groups.google.com/d/msgid/outreachy-kernel/20170925184728.GA8861%40aishwarya.
> > For more options, visit https://groups.google.com/d/optout.
> 
> -- 
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/gem: use new idr deletion interface to cleanup drm_gem_handle_delete()

[Aishwarya Pant]

On Tue, Sep 26, 2017 at 10:12:12AM +0100, Chris Wilson wrote:
> Quoting Aishwarya Pant (2017-09-25 19:47:28)
> > The IDR deletion interface now returns the deleted entry or NULL if it was 
> > not
> > present. So we don't have to do the extra work of checking if we have a
> > reference on the drm_gem_object, this can be handled by checking the return
> > value from idr_remove() and the extra locks can be dropped.
> > 
> > Signed-off-by: Aishwarya Pant 
> 
> This reintroduces the bug were the idr entry is available for reuse
> before the drivers have had the change to release their resources. So a
> new handle may be reused that is then hooked up to the old private data.
> See commit f6cd7daecff558fab2c45d15283d3e52f688342d
> Author: Chris Wilson 
> Date:   Fri Apr 15 12:55:08 2016 +0100
> 
> drm: Release driver references to handle before making it available again

Thanks, this makes sense now.

> -Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2] drm/tinydrm: Move backlight helpers to a separate file

[Daniel Vetter]

On Tue, Sep 26, 2017 at 04:46:53PM +0530, Meghana Madhyastha wrote:
> On Mon, Sep 25, 2017 at 06:31:58PM +0200, Noralf Trønnes wrote:
> > 
> > Den 25.09.2017 16.56, skrev Noralf Trønnes:
> > >Hi Meghana,
> > >
> > >
> > >Den 22.09.2017 17.09, skrev Meghana Madhyastha:
> > >>Move backlight helpers from tinydrm-helpers.c to
> > >>tinydrm-backlight.c. This is because it is organizationally
> > >>simpler to understand and advantageous to group functions
> > >>performing a similar function to a separate file as opposed to
> > >>having one helper file with heteregenous helper functions.
> > >>
> > >>Signed-off-by: Meghana Madhyastha 
> > >>---
> > >
> > >I don't think there is much gain in just moving the code like this.
> > >
> > >The idea is to add a drm_backlight helper that can be useful for all
> > >DRM drivers that use the backlight subsystem.
> 
> Yes I agree. That definitely makes more sense.
> > 
> > The full path to that helper would be:
> > drivers/gpu/drm/drm_backlight.c
> > 
> > >This is what the TODO says:
> > >https://dri.freedesktop.org/docs/drm/gpu/todo.html#tinydrm
> > >
> > >- backlight helpers, probably best to put them into a new drm_backlight.c.
> > >  This is because drivers/video is de-facto unmaintained. We could also
> > >  move drivers/video/backlight to drivers/gpu/backlight and take it all
> > >  over within drm-misc, but that’s more work.
> > >
> > >There is also this discussion to take into account:
> > >KMS backlight ABI proposition
> > >https://lists.freedesktop.org/archives/dri-devel/2017-February/133206.html
> > >
> > >
> > >I don't remember what came out of that discussion.
> > >
> > >Noralf.
> 
> After having discussed this with Daniel on the #dri-devel irc channel, 
> here are some of the points suggested.
> 
> Daniel suggested that I first look into the usage of shared backlight
> helpers in drm (specifically backlight_update_status to begin with). The idea
> was to see whether there is any pattern in usage and/or code dupication.
> If there is, then the next step would be to write helper functions which
> can be used by other drivers (and not just tinydrm). 
> 
> To start with, I went through the instances of backlight_update_status
> in the drm code, and made the following observations(most of them are
> very simple/naive observations).
> 
> - backlight_update_status is usually called in backlight init (and
>   sometimes exit) functions of the drivers just after the device is 
> registered.
>   So backlight_update_status is called with the registered device as the
>   parameter.
> 
> Here are the following cases of properties changed/set before 
> backlight_update_status is called.
> 
> - CASE 1: Brightness is changed (either a macro BRIGHTNESS_MAX_LEVEL 100
>   is defined or it is manually set) This happens in the following files:
> 
>   gma500/cdv_device.c, gma500/mdfld_device.c, gma500/oaktrail_device.c,
>   gma500/psb_device.c, noveau/noveau_backlight.c(here brightness is 
> determined by fuction
>   static int nv50_get_intensity)
> 
> - CASE 2: Power property is set (to FB_BLANK_UNBLANK mostly)
>   This happens in the following files:
> 
>   omapdrm/displays/panel-dpi.c, panel/panel-innolux-p079zca.c,
>   panel/panel-jdi-lt070me05000.c, panel/panel-sharp-lq101r1sx01.c, 
>   panel/panel-sharp-ls043t1le01.c, tilcdc/tilcdc_panel.c
>   
> - CASE 3: State is set
>   This happens in the following files:
> 
>   tinydrm/tinydrm-helpers.c
> 
> - CASE 4: Power and brightness properties are set
>   This happens in the following files:
> 
>   atombios_encoders.c, radeon/radeon_legacy_encoders.c, 
>   shmobile/shmob_drm_backlight.c
> 
> - CASE 5: Power and the state properties are set
>   This happens in the following files:
> 
>   panel/panel-lvds.c, panel/panel-panasonic-vvx10f034n00.c,
>   panel/panel-simple.c, panel/panel-sitronix-st7789v.c
> 
> Please let me know if I am wrong / missed something. As for next steps,
> wouldn't it be an overkill to have a separate helper function for each
> of these cases ? Perhaps a generic helper function which would somehow
> address these cases would be more appropriate ? Thank you for your
> time/patience.

I suspect that a lot of these combinations are just plain wrong, but
happen to kinda work with the combination of gpu driver and backlight
driver they're used on. tbh I have no idea which one is the correct
version for enabling a backlight correctly ...

So definitely a good task to refactor this into a proper helper, but looks
a lot more involved than at first sight.

Do you have any of the hardware supported by any of these drivers? lsmod
and then comparing with the modules you're building in your own tree
should help you figure this out.
-Daniel

> 
> -Meghana
> 
> > >>Changes in v2:
> > >>  -Improved commit message by explaining why the changes were made.
> > >>
> > >>  drivers/gpu/drm/tinydrm/core/Makefile    |   2 +-
> > >>  drivers/gpu/drm/tinydrm/core/tinydrm-backlight.c | 103
> > 

Re: [PATCH v2] drm/tinydrm: Move backlight helpers to a separate file

[Meghana Madhyastha]

On Mon, Sep 25, 2017 at 06:31:58PM +0200, Noralf Trønnes wrote:
> 
> Den 25.09.2017 16.56, skrev Noralf Trønnes:
> >Hi Meghana,
> >
> >
> >Den 22.09.2017 17.09, skrev Meghana Madhyastha:
> >>Move backlight helpers from tinydrm-helpers.c to
> >>tinydrm-backlight.c. This is because it is organizationally
> >>simpler to understand and advantageous to group functions
> >>performing a similar function to a separate file as opposed to
> >>having one helper file with heteregenous helper functions.
> >>
> >>Signed-off-by: Meghana Madhyastha 
> >>---
> >
> >I don't think there is much gain in just moving the code like this.
> >
> >The idea is to add a drm_backlight helper that can be useful for all
> >DRM drivers that use the backlight subsystem.

Yes I agree. That definitely makes more sense.
> 
> The full path to that helper would be:
> drivers/gpu/drm/drm_backlight.c
> 
> >This is what the TODO says:
> >https://dri.freedesktop.org/docs/drm/gpu/todo.html#tinydrm
> >
> >- backlight helpers, probably best to put them into a new drm_backlight.c.
> >  This is because drivers/video is de-facto unmaintained. We could also
> >  move drivers/video/backlight to drivers/gpu/backlight and take it all
> >  over within drm-misc, but that’s more work.
> >
> >There is also this discussion to take into account:
> >KMS backlight ABI proposition
> >https://lists.freedesktop.org/archives/dri-devel/2017-February/133206.html
> >
> >
> >I don't remember what came out of that discussion.
> >
> >Noralf.

After having discussed this with Daniel on the #dri-devel irc channel, 
here are some of the points suggested.

Daniel suggested that I first look into the usage of shared backlight
helpers in drm (specifically backlight_update_status to begin with). The idea
was to see whether there is any pattern in usage and/or code dupication.
If there is, then the next step would be to write helper functions which
can be used by other drivers (and not just tinydrm). 

To start with, I went through the instances of backlight_update_status
in the drm code, and made the following observations(most of them are
very simple/naive observations).

- backlight_update_status is usually called in backlight init (and
  sometimes exit) functions of the drivers just after the device is registered.
  So backlight_update_status is called with the registered device as the
  parameter.

Here are the following cases of properties changed/set before 
backlight_update_status is called.

- CASE 1: Brightness is changed (either a macro BRIGHTNESS_MAX_LEVEL 100
  is defined or it is manually set) This happens in the following files:

  gma500/cdv_device.c, gma500/mdfld_device.c, gma500/oaktrail_device.c,
  gma500/psb_device.c, noveau/noveau_backlight.c(here brightness is determined 
by fuction
  static int nv50_get_intensity)

- CASE 2: Power property is set (to FB_BLANK_UNBLANK mostly)
  This happens in the following files:

  omapdrm/displays/panel-dpi.c, panel/panel-innolux-p079zca.c,
  panel/panel-jdi-lt070me05000.c, panel/panel-sharp-lq101r1sx01.c, 
  panel/panel-sharp-ls043t1le01.c, tilcdc/tilcdc_panel.c
  
- CASE 3: State is set
  This happens in the following files:

  tinydrm/tinydrm-helpers.c

- CASE 4: Power and brightness properties are set
  This happens in the following files:

  atombios_encoders.c, radeon/radeon_legacy_encoders.c, 
  shmobile/shmob_drm_backlight.c

- CASE 5: Power and the state properties are set
  This happens in the following files:

  panel/panel-lvds.c, panel/panel-panasonic-vvx10f034n00.c,
  panel/panel-simple.c, panel/panel-sitronix-st7789v.c

Please let me know if I am wrong / missed something. As for next steps,
wouldn't it be an overkill to have a separate helper function for each
of these cases ? Perhaps a generic helper function which would somehow
address these cases would be more appropriate ? Thank you for your
time/patience.

-Meghana

> >>Changes in v2:
> >>  -Improved commit message by explaining why the changes were made.
> >>
> >>  drivers/gpu/drm/tinydrm/core/Makefile    |   2 +-
> >>  drivers/gpu/drm/tinydrm/core/tinydrm-backlight.c | 103
> >>+++
> >>  drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c   |  94
> >>-
> >>  drivers/gpu/drm/tinydrm/mi0283qt.c   |   1 +
> >>  drivers/gpu/drm/tinydrm/mipi-dbi.c   |   1 +
> >>  include/drm/tinydrm/tinydrm-backlight.h  |  18 
> >>  6 files changed, 124 insertions(+), 95 deletions(-)
> >>  create mode 100644 drivers/gpu/drm/tinydrm/core/tinydrm-backlight.c
> >>  create mode 100644 include/drm/tinydrm/tinydrm-backlight.h
> >>
> >>diff --git a/drivers/gpu/drm/tinydrm/core/Makefile
> >>b/drivers/gpu/drm/tinydrm/core/Makefile
> >>index fb221e6..389ca7a 100644
> >>--- a/drivers/gpu/drm/tinydrm/core/Makefile
> >>+++ b/drivers/gpu/drm/tinydrm/core/Makefile
> >>@@ -1,3 +1,3 @@
> >>-tinydrm-y := tinydrm-core.o tinydrm-pipe.o tinydrm-helpers.o
> >>+tinydrm-y := tinydrm-core.o 

Re: [Intel-gfx] [RFC V1 0/6] Add Plane Color Properties

[Daniel Vetter]

On Tue, Sep 26, 2017 at 01:32:52PM +0530, Uma Shankar wrote:
> This patch series adds properties for plane color features. It adds
> properties for degamma used to linearize data, CSC used for gamut
> conversion, and gamma used to again non-linearize data as per panel
> supported color space. These can be utilize by user space to convert
> planes from one format to another, one color space to another etc.
> 
> Usersapce can take smart blending decisions and utilize these hardware
> supported plane color features to get accurate color profile. The same
> can help in consistent color quality from source to panel taking
> advantage of advanced color features in hardware.
> 
> These patches just add the property interfaces and enable helper functions.
> Based on community feedabck on this one, we can build up and add hardware
> specific implementation on top of this series.
> 
> Note: This is just to get a design feedback whether these interfaces look ok. 
> Once, designed is agreed will re-send the series with a hardware specific
> implementation along with IGT tests for plane color. 

What's missing from this is the property documentation for the userspace
abi, like we have for the pipe color manager stuff:

https://dri.freedesktop.org/docs/drm/gpu/drm-kms.html#color-management-properties

Otherwise looks like a reasonable series, but the real challenges here is
properly enabling this in a HDR (or at least color space) aware compositor.
-Daniel

> 
> Uma Shankar (6):
>   drm: Add Plane Degamma properties
>   drm: Add Plane CTM property
>   drm: Add Plane Gamma properties
>   drm: Define helper function for plane color enabling
>   drm: Define helper to set legacy gamma table size
>   drm/i915: Enable plane color features
> 
>  drivers/gpu/drm/drm_atomic.c |   29 
>  drivers/gpu/drm/drm_color_mgmt.c |   41 +
>  drivers/gpu/drm/drm_mode_config.c|   35 +
>  drivers/gpu/drm/drm_plane.c  |   48 
> ++
>  drivers/gpu/drm/i915/i915_drv.h  |8 ++
>  drivers/gpu/drm/i915/intel_color.c   |   14 ++
>  drivers/gpu/drm/i915/intel_display.c |4 +++
>  drivers/gpu/drm/i915/intel_drv.h |9 +++
>  drivers/gpu/drm/i915/intel_sprite.c  |4 +++
>  include/drm/drm_color_mgmt.h |8 ++
>  include/drm/drm_mode_config.h|   28 
>  include/drm/drm_plane.h  |   31 ++
>  12 files changed, 259 insertions(+)
> 
> -- 
> 1.7.9.5
> 
> ___
> Intel-gfx mailing list
> intel-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 2/2] drm/tilcdc: replace reference/unreference() with get/put

[Daniel Vetter]

On Tue, Sep 26, 2017 at 12:18:06PM +0300, Jyri Sarha wrote:
> 
> Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. 
> Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
> 
> On 09/26/17 11:30, Aishwarya Pant wrote:
> > For maintaining consistency with kernel coding style replace
> > reference/unreference in ref counting functions with get/put.
> > 
> > The following cocci script was used to generate the tilcdc patch:
> > 
> > @@
> > expression ex;
> > @@
> > 
> > (
> > -drm_framebuffer_unreference(ex);
> > +drm_framebuffer_put(ex);
> > |
> > -drm_dev_unref(ex);
> > +drm_dev_put(ex);
> > |
> > -drm_framebuffer_reference(ex);
> > +drm_framebuffer_get(ex);
> > )
> > 
> > Signed-off-by: Aishwarya Pant 
> 
> Acked-by: Jyri Sarha 
> 
> I guess this should go in via drm-misc at the same time with
> "drm: introduce drm_dev_{get/put} functions".

Yup, this one needs the previous one, both pushed to drm-misc-next.

Aishwarya, while reviewing your patches I've noticed that you've missed to
case of drm_dev_unref() in the drm core code, one in drm_pci.c and one in
drm_prime.c. Can you pls do a follow-up patch to address these two? Fixing
up the core completely is nice, drivers can be done later on (also by
others, this is a prefect newbies tasks). But making sure the core is
consistent is good I think.
-Daniel

> 
> Best regards,
> Jyri
> 
> 
> > ---
> > No changes in v2
> > 
> > drivers/gpu/drm/tilcdc/tilcdc_crtc.c | 6 +++---
> >  drivers/gpu/drm/tilcdc/tilcdc_drv.c  | 2 +-
> >  2 files changed, 4 insertions(+), 4 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c 
> > b/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
> > index 406fe45..d2589f310 100644
> > --- a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
> > +++ b/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
> > @@ -75,7 +75,7 @@ static void unref_worker(struct drm_flip_work *work, void 
> > *val)
> > struct drm_device *dev = tilcdc_crtc->base.dev;
> >  
> > mutex_lock(>mode_config.mutex);
> > -   drm_framebuffer_unreference(val);
> > +   drm_framebuffer_put(val);
> > mutex_unlock(>mode_config.mutex);
> >  }
> >  
> > @@ -456,7 +456,7 @@ static void tilcdc_crtc_set_mode(struct drm_crtc *crtc)
> >  
> > set_scanout(crtc, fb);
> >  
> > -   drm_framebuffer_reference(fb);
> > +   drm_framebuffer_get(fb);
> >  
> > crtc->hwmode = crtc->state->adjusted_mode;
> >  }
> > @@ -633,7 +633,7 @@ int tilcdc_crtc_update_fb(struct drm_crtc *crtc,
> > return -EBUSY;
> > }
> >  
> > -   drm_framebuffer_reference(fb);
> > +   drm_framebuffer_get(fb);
> >  
> > crtc->primary->fb = fb;
> > tilcdc_crtc->event = event;
> > diff --git a/drivers/gpu/drm/tilcdc/tilcdc_drv.c 
> > b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
> > index b0d70f9..74276ef 100644
> > --- a/drivers/gpu/drm/tilcdc/tilcdc_drv.c
> > +++ b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
> > @@ -225,7 +225,7 @@ static void tilcdc_fini(struct drm_device *dev)
> >  
> > pm_runtime_disable(dev->dev);
> >  
> > -   drm_dev_unref(dev);
> > +   drm_dev_put(dev);
> >  }
> >  
> >  static int tilcdc_init(struct drm_driver *ddrv, struct device *dev)
> > 
> 
> 
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Kernel GPU subsytem: Better manual upload for atomic

[Daniel Vetter]

On Tue, Sep 26, 2017 at 03:47:56PM +0530, Harsha Sharma wrote:
> Hello,
> I am working on task "Better manual upload for atomic" in kernel gpu
> subsystem.
> When duplicating the crtc state I need to change drm_rect x2 and y2 to
> MAX_INT.
> I didn't get what is MAX_INT over here. Also, how am I supposed to test my
> code?
> It will be really helpful if you can suggest something.
> Thanks a lot for your time.

This is a very involved task which is more appropriate for an entire
internship, not really good stuff for the application period.

Please chat with Sean or me on irc to pick a better task.

Thanks, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

RE: [RFC v1 5/6] drm: Define helper to set legacy gamma table size

[Shankar, Uma]

>-Original Message-
>From: Lankhorst, Maarten
>Sent: Tuesday, September 26, 2017 3:45 PM
>To: Shankar, Uma ; intel-...@lists.freedesktop.org;
>dri-devel@lists.freedesktop.org
>Cc: Syrjala, Ville 
>Subject: Re: [RFC v1 5/6] drm: Define helper to set legacy gamma table size
>
>Shankar, Uma schreef op di 26-09-2017 om 15:41 [+0530]:
>> > -Original Message-
>> > From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On
>> > Behalf Of Lankhorst, Maarten
>> > Sent: Tuesday, September 26, 2017 3:36 PM
>> > To: Shankar, Uma ; intel-gfx@lists.freedeskt
>> > op.org; dri-devel@lists.freedesktop.org
>> > Cc: Syrjala, Ville 
>> > Subject: Re: [RFC v1 5/6] drm: Define helper to set legacy gamma
>> > table size
>> >
>> > Hey,
>> >
>> > Uma Shankar schreef op di 26-09-2017 om 13:32 [+0530]:
>> > > Define a helper function to set legacy gamma table size for
>> > > planes.
>> > >
>> > > Signed-off-by: Uma Shankar 
>> > > ---
>> > >  drivers/gpu/drm/drm_color_mgmt.c |   41
>> > > ++
>> > >  include/drm/drm_color_mgmt.h |3 +++
>> > >  include/drm/drm_plane.h  |4 
>> > >  3 files changed, 48 insertions(+)
>> >
>> > Is this needed? I'm not aware of legacy tables for planes.
>>
>> I was not getting very concrete info on this. So kept it as per pipe
>> gamma implementation.
>> I will try to get some more info and drop this in case it's not
>> required.
>>
>
>It's not, legacy gamma would only be used in drm_mode_gamma_get_ioctl,
>which if you look at it only works for a crtc. :)
>

Yeah I thought that it was just added for crtc, and implementation for plane 
was not done. 
Was not sure if it can also be extended for plane.

Will drop this change. Thanks for clarifying.

Regards,
Uma Shankar

>~Maarten
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Outreachy kernel] [PATCH] drm/gem: use new idr deletion interface to cleanup drm_gem_handle_delete()

[Julia Lawall]

On Tue, 26 Sep 2017, Daniel Vetter wrote:

> On Tue, Sep 26, 2017 at 10:47 AM, Daniel Vetter  wrote:
> > On Tue, Sep 26, 2017 at 10:38 AM, Julia Lawall  wrote:
> >>
> >>
> >> On Tue, 26 Sep 2017, Daniel Vetter wrote:
> >>
> >>> On Tue, Sep 26, 2017 at 12:17:28AM +0530, Aishwarya Pant wrote:
> >>> > The IDR deletion interface now returns the deleted entry or NULL if it 
> >>> > was not
> >>> > present. So we don't have to do the extra work of checking if we have a
> >>> > reference on the drm_gem_object, this can be handled by checking the 
> >>> > return
> >>> > value from idr_remove() and the extra locks can be dropped.
> >>> >
> >>> > Signed-off-by: Aishwarya Pant 
> >>>
> >>> Haneen is already working on this task, with the patch just merged. Please
> >>> coordinate with mentors (me or Sean Paul) before starting on something to
> >>> avoid such clashes in the future.
> >>>
> >>> Note also that some todo items are just ideas, and need confirmation with
> >>> relevant maintainers first.
> >>
> >> Not sure where the mixup happened, but anyone who starts on a project
> >> specific task should note that on the outreachy kernel wiki and before
> >> starting on a project specific task one should check that no one is
> >> working on it.  If someone started some time ago, and the code doesn't
> >> seem to have changed, ask the person who claimed the task or the mentor.
> >
> > Hm, the dri-devel tasks aren't on the wiki, but in the kernel sources.
> > Where should we put the scratch-pad to avoid such conflicts in the
> > future? E.g. the IIO subsytems has it's task on the wiki, where this
> > works much better.
>
> Ok, I found it. Looks like a few signed up for stuff, but without
> chatting with us first, and ended up picking tasks that need some
> serious GPU expertise. I.e. maybe suitable for a full internship,
> definitely not as starter tasks. I'll send out mails.

Thanks.  Everyone, please discuss with the mentor before picking a task.

julia

> -Daniel
>
>
> > -Daniel
> >
> >>
> >> thanks,
> >>
> >> julia
> >>
> >>>
> >>> Thanks, Daniel
> >>> > ---
> >>> >  drivers/gpu/drm/drm_gem.c | 21 ++---
> >>> >  1 file changed, 2 insertions(+), 19 deletions(-)
> >>> >
> >>> > diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
> >>> > index c55f338..f62757a 100644
> >>> > --- a/drivers/gpu/drm/drm_gem.c
> >>> > +++ b/drivers/gpu/drm/drm_gem.c
> >>> > @@ -282,29 +282,12 @@ drm_gem_handle_delete(struct drm_file *filp, u32 
> >>> > handle)
> >>> >  {
> >>> > struct drm_gem_object *obj;
> >>> >
> >>> > -   /* This is gross. The idr system doesn't let us try a delete and
> >>> > -* return an error code.  It just spews if you fail at deleting.
> >>> > -* So, we have to grab a lock around finding the object and then
> >>> > -* doing the delete on it and dropping the refcount, or the user
> >>> > -* could race us to double-decrement the refcount and cause a
> >>> > -* use-after-free later.  Given the frequency of our handle lookups,
> >>> > -* we may want to use ida for number allocation and a hash table
> >>> > -* for the pointers, anyway.
> >>> > -*/
> >>> > spin_lock(>table_lock);
> >>> > -
> >>> > -   /* Check if we currently have a reference on the object */
> >>> > -   obj = idr_replace(>object_idr, NULL, handle);
> >>> > -   spin_unlock(>table_lock);
> >>> > -   if (IS_ERR_OR_NULL(obj))
> >>> > +   obj = idr_remove(>object_idr, handle);
> >>> > +   if (!obj)
> >>> > return -EINVAL;
> >>> > -
> >>> > /* Release driver's reference and decrement refcount. */
> >>> > drm_gem_object_release_handle(handle, obj, filp);
> >>> > -
> >>> > -   /* And finally make the handle available for future allocations. */
> >>> > -   spin_lock(>table_lock);
> >>> > -   idr_remove(>object_idr, handle);
> >>> > spin_unlock(>table_lock);
> >>> >
> >>> > return 0;
> >>> > --
> >>> > 2.7.4
> >>> >
> >>> > --
> >>> > You received this message because you are subscribed to the Google 
> >>> > Groups "outreachy-kernel" group.
> >>> > To unsubscribe from this group and stop receiving emails from it, send 
> >>> > an email to outreachy-kernel+unsubscr...@googlegroups.com.
> >>> > To post to this group, send email to outreachy-ker...@googlegroups.com.
> >>> > To view this discussion on the web visit 
> >>> > https://groups.google.com/d/msgid/outreachy-kernel/20170925184728.GA8861%40aishwarya.
> >>> > For more options, visit https://groups.google.com/d/optout.
> >>>
> >>> --
> >>> Daniel Vetter
> >>> Software Engineer, Intel Corporation
> >>> http://blog.ffwll.ch
> >>>
> >>> --
> >>> You received this message because you are subscribed to the Google Groups 
> >>> "outreachy-kernel" group.
> >>> To unsubscribe from this group and stop receiving emails from it, send an 
> >>> email to outreachy-kernel+unsubscr...@googlegroups.com.
> >>> To post to this group, send email to 

Re: [RFC v1 5/6] drm: Define helper to set legacy gamma table size

[Lankhorst, Maarten]

Shankar, Uma schreef op di 26-09-2017 om 15:41 [+0530]:
> > -Original Message-
> > From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On
> > Behalf Of
> > Lankhorst, Maarten
> > Sent: Tuesday, September 26, 2017 3:36 PM
> > To: Shankar, Uma ; intel-gfx@lists.freedeskt
> > op.org;
> > dri-devel@lists.freedesktop.org
> > Cc: Syrjala, Ville 
> > Subject: Re: [RFC v1 5/6] drm: Define helper to set legacy gamma
> > table size
> > 
> > Hey,
> > 
> > Uma Shankar schreef op di 26-09-2017 om 13:32 [+0530]:
> > > Define a helper function to set legacy gamma table size for
> > > planes.
> > > 
> > > Signed-off-by: Uma Shankar 
> > > ---
> > >  drivers/gpu/drm/drm_color_mgmt.c |   41
> > > ++
> > >  include/drm/drm_color_mgmt.h |3 +++
> > >  include/drm/drm_plane.h  |4 
> > >  3 files changed, 48 insertions(+)
> > 
> > Is this needed? I'm not aware of legacy tables for planes.
> 
> I was not getting very concrete info on this. So kept it as per pipe
> gamma implementation.
> I will try to get some more info and drop this in case it's not
> required.
> 

It's not, legacy gamma would only be used in drm_mode_gamma_get_ioctl,
which if you look at it only works for a crtc. :)

~Maarten
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

RE: [RFC v1 5/6] drm: Define helper to set legacy gamma table size

[Shankar, Uma]

>-Original Message-
>From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of
>Lankhorst, Maarten
>Sent: Tuesday, September 26, 2017 3:36 PM
>To: Shankar, Uma ; intel-...@lists.freedesktop.org;
>dri-devel@lists.freedesktop.org
>Cc: Syrjala, Ville 
>Subject: Re: [RFC v1 5/6] drm: Define helper to set legacy gamma table size
>
>Hey,
>
>Uma Shankar schreef op di 26-09-2017 om 13:32 [+0530]:
>> Define a helper function to set legacy gamma table size for planes.
>>
>> Signed-off-by: Uma Shankar 
>> ---
>>  drivers/gpu/drm/drm_color_mgmt.c |   41
>> ++
>>  include/drm/drm_color_mgmt.h |3 +++
>>  include/drm/drm_plane.h  |4 
>>  3 files changed, 48 insertions(+)
>
>Is this needed? I'm not aware of legacy tables for planes.

I was not getting very concrete info on this. So kept it as per pipe gamma 
implementation.
I will try to get some more info and drop this in case it's not required.

Regards,
Uma Shankar

>Kind regards,
>Maarten
>___
>dri-devel mailing list
>dri-devel@lists.freedesktop.org
>https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC v1 5/6] drm: Define helper to set legacy gamma table size

[Lankhorst, Maarten]

Hey,

Uma Shankar schreef op di 26-09-2017 om 13:32 [+0530]:
> Define a helper function to set legacy gamma table
> size for planes.
> 
> Signed-off-by: Uma Shankar 
> ---
>  drivers/gpu/drm/drm_color_mgmt.c |   41
> ++
>  include/drm/drm_color_mgmt.h |3 +++
>  include/drm/drm_plane.h  |4 
>  3 files changed, 48 insertions(+)

Is this needed? I'm not aware of legacy tables for planes.

Kind regards,
Maarten
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 11/13] drm/sun4i: hdmi: Add support for A31's HDMI controller

[Maxime Ripard]

On Tue, Sep 26, 2017 at 06:59:17AM +, Chen-Yu Tsai wrote:
> The HDMI controller found in the A31 SoCs is slightly different
> from the one already supported, which is found in the A10s:
> 
>   - Need different initial values for the PLL related registers
> 
>   - Different behavior of the DDC and TMDS clocks
> 
>   - Different register layout for the DDC portion
> 
>   - Separate DDC parent clock
> 
> This patch adds support for it.
> 
> Signed-off-by: Chen-Yu Tsai 

Acked-by: Maxime Ripard 

Thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 09/13] drm/sun4i: hdmi: Add support for controller hardware variants

[Maxime Ripard]

On Tue, Sep 26, 2017 at 06:59:15AM +, Chen-Yu Tsai wrote:
> The HDMI controller found in earlier Allwinner SoCs have slight
> differences between the A10, A10s, and the A31:
> 
>   - Need different initial values for the PLL related registers
> 
>   - Different behavior of the DDC and TMDS clocks
> 
>   - Different register layout for the DDC portion
> 
>   - Separate DDC parent clock on the A31
> 
>   - Explicit reset control
> 
> For the A31, the HDMI TMDS clock has a different value offset for
> the divider. The HDMI DDC block is different from the one in the
> other SoCs. As far as the DDC clock goes, it has no pre-divider,
> as it is clocked from a slower parent clock, not the TMDS clock.
> The divider offset from the register value is different. And the
> clock control register is at a different offset.
> 
> A new variant data structure is created to store pointers to the
> above functions, structures, and the different initial values.
> Another flag notates whether there is a separate DDC parent clock.
> If not, the TMDS clock is passed to the DDC clock create function,
> as before.
> 
> Regmap fields are used to deal with the different register layout
> of the DDC block.
> 
> Signed-off-by: Chen-Yu Tsai 

Acked-by: Maxime Ripard 

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 10/13] drm/sun4i: hdmi: Add A31 specific DDC register definitions

[Maxime Ripard]

On Tue, Sep 26, 2017 at 06:59:16AM +, Chen-Yu Tsai wrote:
> The DDC block for the HDMI controller is different on the A31.
> 
> This patch adds the register definitions.
> 
> Signed-off-by: Chen-Yu Tsai 

Acked-by: Maxime Ripard 

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 1/2] drm/dp: Add defines for latency in sink

[vathsala nagaraju]

Add defines for dpcd register 2009 (synchronization latency
in sink).

v2:
 - add spec version (Daniel)
 - use register name as is in spec,only drop excess
   from end (jani)
 - add the full register contents (jani)

Cc: Rodrigo Vivi 
CC: Puthikorn Voravootivat 
Reviewed-by: Rodrigo Vivi 
Signed-off-by: Vathsala Nagaraju 
---
 include/drm/drm_dp_helper.h | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index 11c39f1..f58dcb9 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -735,6 +735,12 @@
 # define DP_PSR_SINK_INTERNAL_ERROR 7
 # define DP_PSR_SINK_STATE_MASK 0x07
 
+#define DP_SYNCHRONIZATION_LATENCY_IN_SINK 0x2009 /* edp 1.4b */
+# define DP_MAX_RESYNC_FRAME_COUNT_MASK(0xf << 0)
+# define DP_MAX_RESYNC_FRAME_COUNT_SHIFT   0
+# define DP_LAST_ACTUAL_SYNCHRONIZATION_LATENCY_MASK   (0xf << 4)
+# define DP_LAST_ACTUAL_SYNCHRONIZATION_LATENCY_SHIFT  4
+
 #define DP_RECEIVER_ALPM_STATUS0x200b  /* eDP 1.4 */
 # define DP_ALPM_LOCK_TIMEOUT_ERROR(1 << 0)
 
-- 
1.9.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 2/2] drm/i915/psr: Set frames before SU entry for psr2

[vathsala nagaraju]

Set frames before SU entry value for max resync frame count of
dpcd register 2009, bit field 0:3.

v2 :
 - add macro  EDP_PSR2_FRAME_BEFORE_SU (Rodrigo)
 - remove EDP_FRAMES_BEFORE_SU_ENTRY (Rodrigo)
 - add check ==1 for dpcd_read call (ville)

v3 : (Rodrigo)
 - move macro EDP_PSR2_FRAME_BEFORE_SU after EDP_PSR2_FRAME_BEFORE_SU
 - replace with &=

v4 :
 - change the macro to shift value (jani)
 - updated register names

Cc: Rodrigo Vivi 
CC: Puthikorn Voravootivat 
Reviewed-by: Rodrigo Vivi 
Signed-off-by: Vathsala Nagaraju 
---
 drivers/gpu/drm/i915/i915_reg.h  |  2 +-
 drivers/gpu/drm/i915/intel_psr.c | 13 +++--
 2 files changed, 12 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 82f36dd..7e7aa60 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -4047,7 +4047,7 @@ enum {
 #define   EDP_PSR2_FRAME_BEFORE_SU_SHIFT 4
 #define   EDP_PSR2_FRAME_BEFORE_SU_MASK(0xf<<4)
 #define   EDP_PSR2_IDLE_MASK   0xf
-#define   EDP_FRAMES_BEFORE_SU_ENTRY   (1<<4)
+#define   EDP_PSR2_FRAME_BEFORE_SU(a)  ((a)<<4)
 
 #define EDP_PSR2_STATUS_CTL_MMIO(0x6f940)
 #define EDP_PSR2_STATUS_STATE_MASK (0xf<<28)
diff --git a/drivers/gpu/drm/i915/intel_psr.c b/drivers/gpu/drm/i915/intel_psr.c
index 0a17d1f..5419cda 100644
--- a/drivers/gpu/drm/i915/intel_psr.c
+++ b/drivers/gpu/drm/i915/intel_psr.c
@@ -327,6 +327,7 @@ static void hsw_activate_psr2(struct intel_dp *intel_dp)
 */
uint32_t idle_frames = max(6, dev_priv->vbt.psr.idle_frames);
uint32_t val;
+   uint8_t sink_latency;
 
val = idle_frames << EDP_PSR_IDLE_FRAME_SHIFT;
 
@@ -334,8 +335,16 @@ static void hsw_activate_psr2(struct intel_dp *intel_dp)
 * mesh at all with our frontbuffer tracking. And the hw alone isn't
 * good enough. */
val |= EDP_PSR2_ENABLE |
-   EDP_SU_TRACK_ENABLE |
-   EDP_FRAMES_BEFORE_SU_ENTRY;
+   EDP_SU_TRACK_ENABLE;
+
+   if (drm_dp_dpcd_readb(_dp->aux,
+   DP_SYNCHRONIZATION_LATENCY_IN_SINK,
+   _latency) == 1) {
+   sink_latency &= DP_MAX_RESYNC_FRAME_COUNT_MASK;
+   } else {
+   sink_latency = 0;
+   }
+   val |= EDP_PSR2_FRAME_BEFORE_SU(sink_latency + 1);
 
if (dev_priv->vbt.psr.tp2_tp3_wakeup_time > 5)
val |= EDP_PSR2_TP2_TIME_2500;
-- 
1.9.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 06/13] drm/sun4i: hdmi: Allow using second PLL as TMDS clk parent

[Maxime Ripard]

On Tue, Sep 26, 2017 at 06:59:12AM +, Chen-Yu Tsai wrote:
> Allwinner SoCs typically have two PLLs reserved for video related usage.
> At the moment we only support using the first one to feed the HDMI
> transmitter block's TMDS clock.
> 
> Let the HDMI encoder's TMDS clock go through all of its parents when
> calculating possible clock rates. This allows usage of the second video
> PLL as its parent.
> 
> Note that this does not handle conflicting pixel clocks. It is entirely
> possible to have an LCD panel use one pixel clock rate, only to be
> overridden by the HDMI transmitter's clock rate request when the second
> display pipeline is enabled.
> 
> This should be handled by having all the clock drivers honor clock rate
> ranges, and have the consumers use clk_set_rate_min/clk_set_rate_max.

That, or relying on clk_set_rate_protect

Acked-by: Maxime Ripard 

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 05/13] drm/sun4i: hdmi: create a regmap for later use

[Maxime Ripard]

On Tue, Sep 26, 2017 at 06:59:11AM +, Chen-Yu Tsai wrote:
> The HDMI driver is written with readl/writel I/O to the registers.
> However, to support the A31 variant, which has a different layout
> for the DDC registers, it was recommended to use regfields to have
> a cleaner implementation. To use regfields, we need to create an
> underlying regmap.
> 
> This patch only adds the regmap. It does not convert the existing
> driver accesses to use regmap.
> 
> Signed-off-by: Chen-Yu Tsai 

Acked-by: Maxime Ripard 

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 04/13] drm/sun4i: hdmi: Disable clks in bind function error path and unbind function

[Maxime Ripard]

On Tue, Sep 26, 2017 at 06:59:10AM +, Chen-Yu Tsai wrote:
> The HDMI driver enables the bus and mod clocks in the bind function, but
> does not disable them if it then bails our due to any errors. Neither
> does it disable the clocks in the unbind function.
> 
> Fix this by adding a proper error path to the bind function, and
> clk_disable_unprepare calls to the unbind function.
> 
> Also rename the err_cleanup_connector label to err_cleanup_encoder,
> since it is the encoder that gets cleaned up.
> 
> Fixes: 9c5681011a0c ("drm/sun4i: Add HDMI support")
> Signed-off-by: Chen-Yu Tsai 

Acked-by: Maxime Ripard 

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 03/13] drm/sun4i: tcon: Add support for demuxing TCON output on A31

[Maxime Ripard]

Hi,

On Tue, Sep 26, 2017 at 06:59:09AM +, Chen-Yu Tsai wrote:
> On systems with 2 TCONs such as the A31, it is possible to demux the
> output of the TCONs to one encoder.
> 
> Add support for this for the A31.
> 
> Signed-off-by: Chen-Yu Tsai 
> ---
>  drivers/gpu/drm/sun4i/sun4i_tcon.c | 61 
> ++
>  1 file changed, 61 insertions(+)
> 
> diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c 
> b/drivers/gpu/drm/sun4i/sun4i_tcon.c
> index e853dfe51389..770b843a6fa9 100644
> --- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
> +++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
> @@ -14,9 +14,12 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  
> +#include 
> +
>  #include 
>  #include 
>  #include 
> @@ -109,11 +112,69 @@ void sun4i_tcon_enable_vblank(struct sun4i_tcon *tcon, 
> bool enable)
>  }
>  EXPORT_SYMBOL(sun4i_tcon_enable_vblank);
>  
> +static struct sun4i_tcon *sun4i_get_first_tcon(struct drm_device *drm)
> +{
> + struct sun4i_drv *drv = drm->dev_private;
> + struct sun4i_tcon *tcon;
> +
> + list_for_each_entry(tcon, >tcon_list, list)
> + if (tcon->id == 0)
> + return tcon;
> +
> + dev_warn(drm->dev,
> +  "TCON0 not found, display output muxing may not work\n");
> +
> + return tcon;
> +}
> +
> +static int _sun6i_tcon_set_mux(struct drm_encoder *encoder)
> +{
> + struct sun4i_tcon *tcon = sun4i_get_first_tcon(encoder->dev);
> + int tcon_id = drm_crtc_to_sun4i_crtc(encoder->crtc)->tcon->id;
> + u32 shift;
> +
> + DRM_DEBUG_DRIVER("Muxing encoder %s to CRTC %s (TCON %d)\n",
> +  encoder->name, encoder->crtc->name, tcon_id);
> +
> + /* Only 2 TCONs */
> + if (tcon_id >= 2)
> + return -EINVAL;
> +
> + switch (encoder->encoder_type) {
> + case DRM_MODE_ENCODER_TMDS:
> + /* HDMI */
> + shift = 8;
> + break;
> + case DRM_MODE_ENCODER_DSI:
> + /* No MIPI DSI on A31s */
> + if (of_device_is_compatible(tcon->dev->of_node,
> + "allwinner,sun6i-a31s-tcon"))

I'm not sure that test is needed.

We won't end up in that case if we don't have a connected DSI block,
which isn't going to be the case on the A31. And I guess we can tackle
DSI later (when I'll send my patches...).

> + return -EINVAL;
> + shift = 0;
> + break;
> + default:
> + return -EINVAL;
> + }
> +
> + regmap_update_bits(tcon->regs, SUN4I_TCON_MUX_CTRL_REG,
> +0x3 << shift, tcon_id << shift);
> +
> + return 0;
> +}
> +
>  void sun4i_tcon_set_mux(struct sun4i_tcon *tcon, int channel,
>   struct drm_encoder *encoder)
>  {
> + /* Get the device node of the display engine */
> + struct device_node *node = encoder->dev->dev->of_node;
>   u32 val;
>  
> + if (of_device_is_compatible(node, "allwinner,sun6i-a31-display-engine") 
> ||
> + of_device_is_compatible(node, 
> "allwinner,sun6i-a31s-display-engine")) {
> + _sun6i_tcon_set_mux(encoder);
> + return;
> + }
> +

I'd really like to avoid mix and matching the structure defined
behaviour and those of_device_is_compatible calls spread out
everywhere.

You can either add a flag or a function pointer.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 102981] [amdgpu][tahiti xt][vulkan][GL] dota2 tournament drafting screen misses skys when antialiasing is on

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=102981

Sylvain BERTRAND  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |NOTOURBUG

--- Comment #3 from Sylvain BERTRAND  ---
Since it happens on dota2 windows, this is dota2 specific. Closing.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 02/13] clk: sunxi-ng: sun6i: Rename HDMI DDC clock to avoid name collision

[Maxime Ripard]

On Tue, Sep 26, 2017 at 06:59:08AM +, Chen-Yu Tsai wrote:
> The HDMI DDC clock found in the CCU is the parent of the actual DDC
> clock within the HDMI controller. That clock is also named "hdmi-ddc".
> 
> Rename the one in the CCU to "hdmi-ddc-parent". This makes more sense
> than renaming the one in the HDMI controller to something else.
> 
> Fixes: c6e6c96d8fa6 ("clk: sunxi-ng: Add A31/A31s clocks")
> Signed-off-by: Chen-Yu Tsai 

I'd rather stick to the datasheet names. What about "DDC" ?

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 01/13] clk: sunxi-ng: sun6i: Export video PLLs

[Maxime Ripard]

On Tue, Sep 26, 2017 at 06:59:07AM +, Chen-Yu Tsai wrote:
> The 2x outputs of the 2 video PLL clocks are directly used by the
> HDMI controller block.
> 
> Export them so they can be referenced in the device tree.
> 
> Fixes: c6e6c96d8fa6 ("clk: sunxi-ng: Add A31/A31s clocks")
> Signed-off-by: Chen-Yu Tsai 

Acked-by: Maxime Ripard 

Thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 2/2] drm/tilcdc: replace reference/unreference() with get/put

[Jyri Sarha]


Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. 
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

On 09/26/17 11:30, Aishwarya Pant wrote:
> For maintaining consistency with kernel coding style replace
> reference/unreference in ref counting functions with get/put.
> 
> The following cocci script was used to generate the tilcdc patch:
> 
> @@
> expression ex;
> @@
> 
> (
> -drm_framebuffer_unreference(ex);
> +drm_framebuffer_put(ex);
> |
> -drm_dev_unref(ex);
> +drm_dev_put(ex);
> |
> -drm_framebuffer_reference(ex);
> +drm_framebuffer_get(ex);
> )
> 
> Signed-off-by: Aishwarya Pant 

Acked-by: Jyri Sarha 

I guess this should go in via drm-misc at the same time with
"drm: introduce drm_dev_{get/put} functions".

Best regards,
Jyri


> ---
> No changes in v2
> 
> drivers/gpu/drm/tilcdc/tilcdc_crtc.c | 6 +++---
>  drivers/gpu/drm/tilcdc/tilcdc_drv.c  | 2 +-
>  2 files changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c 
> b/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
> index 406fe45..d2589f310 100644
> --- a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
> +++ b/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
> @@ -75,7 +75,7 @@ static void unref_worker(struct drm_flip_work *work, void 
> *val)
>   struct drm_device *dev = tilcdc_crtc->base.dev;
>  
>   mutex_lock(>mode_config.mutex);
> - drm_framebuffer_unreference(val);
> + drm_framebuffer_put(val);
>   mutex_unlock(>mode_config.mutex);
>  }
>  
> @@ -456,7 +456,7 @@ static void tilcdc_crtc_set_mode(struct drm_crtc *crtc)
>  
>   set_scanout(crtc, fb);
>  
> - drm_framebuffer_reference(fb);
> + drm_framebuffer_get(fb);
>  
>   crtc->hwmode = crtc->state->adjusted_mode;
>  }
> @@ -633,7 +633,7 @@ int tilcdc_crtc_update_fb(struct drm_crtc *crtc,
>   return -EBUSY;
>   }
>  
> - drm_framebuffer_reference(fb);
> + drm_framebuffer_get(fb);
>  
>   crtc->primary->fb = fb;
>   tilcdc_crtc->event = event;
> diff --git a/drivers/gpu/drm/tilcdc/tilcdc_drv.c 
> b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
> index b0d70f9..74276ef 100644
> --- a/drivers/gpu/drm/tilcdc/tilcdc_drv.c
> +++ b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
> @@ -225,7 +225,7 @@ static void tilcdc_fini(struct drm_device *dev)
>  
>   pm_runtime_disable(dev->dev);
>  
> - drm_dev_unref(dev);
> + drm_dev_put(dev);
>  }
>  
>  static int tilcdc_init(struct drm_driver *ddrv, struct device *dev)
> 


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/gem: use new idr deletion interface to cleanup drm_gem_handle_delete()

[Chris Wilson]

Quoting Aishwarya Pant (2017-09-25 19:47:28)
> The IDR deletion interface now returns the deleted entry or NULL if it was not
> present. So we don't have to do the extra work of checking if we have a
> reference on the drm_gem_object, this can be handled by checking the return
> value from idr_remove() and the extra locks can be dropped.
> 
> Signed-off-by: Aishwarya Pant 

This reintroduces the bug were the idr entry is available for reuse
before the drivers have had the change to release their resources. So a
new handle may be reused that is then hooked up to the old private data.
See commit f6cd7daecff558fab2c45d15283d3e52f688342d
Author: Chris Wilson 
Date:   Fri Apr 15 12:55:08 2016 +0100

drm: Release driver references to handle before making it available again
-Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Outreachy kernel] [PATCH] drm/gem: use new idr deletion interface to cleanup drm_gem_handle_delete()

[Daniel Vetter]

On Tue, Sep 26, 2017 at 10:47 AM, Daniel Vetter  wrote:
> On Tue, Sep 26, 2017 at 10:38 AM, Julia Lawall  wrote:
>>
>>
>> On Tue, 26 Sep 2017, Daniel Vetter wrote:
>>
>>> On Tue, Sep 26, 2017 at 12:17:28AM +0530, Aishwarya Pant wrote:
>>> > The IDR deletion interface now returns the deleted entry or NULL if it 
>>> > was not
>>> > present. So we don't have to do the extra work of checking if we have a
>>> > reference on the drm_gem_object, this can be handled by checking the 
>>> > return
>>> > value from idr_remove() and the extra locks can be dropped.
>>> >
>>> > Signed-off-by: Aishwarya Pant 
>>>
>>> Haneen is already working on this task, with the patch just merged. Please
>>> coordinate with mentors (me or Sean Paul) before starting on something to
>>> avoid such clashes in the future.
>>>
>>> Note also that some todo items are just ideas, and need confirmation with
>>> relevant maintainers first.
>>
>> Not sure where the mixup happened, but anyone who starts on a project
>> specific task should note that on the outreachy kernel wiki and before
>> starting on a project specific task one should check that no one is
>> working on it.  If someone started some time ago, and the code doesn't
>> seem to have changed, ask the person who claimed the task or the mentor.
>
> Hm, the dri-devel tasks aren't on the wiki, but in the kernel sources.
> Where should we put the scratch-pad to avoid such conflicts in the
> future? E.g. the IIO subsytems has it's task on the wiki, where this
> works much better.

Ok, I found it. Looks like a few signed up for stuff, but without
chatting with us first, and ended up picking tasks that need some
serious GPU expertise. I.e. maybe suitable for a full internship,
definitely not as starter tasks. I'll send out mails.
-Daniel


> -Daniel
>
>>
>> thanks,
>>
>> julia
>>
>>>
>>> Thanks, Daniel
>>> > ---
>>> >  drivers/gpu/drm/drm_gem.c | 21 ++---
>>> >  1 file changed, 2 insertions(+), 19 deletions(-)
>>> >
>>> > diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
>>> > index c55f338..f62757a 100644
>>> > --- a/drivers/gpu/drm/drm_gem.c
>>> > +++ b/drivers/gpu/drm/drm_gem.c
>>> > @@ -282,29 +282,12 @@ drm_gem_handle_delete(struct drm_file *filp, u32 
>>> > handle)
>>> >  {
>>> > struct drm_gem_object *obj;
>>> >
>>> > -   /* This is gross. The idr system doesn't let us try a delete and
>>> > -* return an error code.  It just spews if you fail at deleting.
>>> > -* So, we have to grab a lock around finding the object and then
>>> > -* doing the delete on it and dropping the refcount, or the user
>>> > -* could race us to double-decrement the refcount and cause a
>>> > -* use-after-free later.  Given the frequency of our handle lookups,
>>> > -* we may want to use ida for number allocation and a hash table
>>> > -* for the pointers, anyway.
>>> > -*/
>>> > spin_lock(>table_lock);
>>> > -
>>> > -   /* Check if we currently have a reference on the object */
>>> > -   obj = idr_replace(>object_idr, NULL, handle);
>>> > -   spin_unlock(>table_lock);
>>> > -   if (IS_ERR_OR_NULL(obj))
>>> > +   obj = idr_remove(>object_idr, handle);
>>> > +   if (!obj)
>>> > return -EINVAL;
>>> > -
>>> > /* Release driver's reference and decrement refcount. */
>>> > drm_gem_object_release_handle(handle, obj, filp);
>>> > -
>>> > -   /* And finally make the handle available for future allocations. */
>>> > -   spin_lock(>table_lock);
>>> > -   idr_remove(>object_idr, handle);
>>> > spin_unlock(>table_lock);
>>> >
>>> > return 0;
>>> > --
>>> > 2.7.4
>>> >
>>> > --
>>> > You received this message because you are subscribed to the Google Groups 
>>> > "outreachy-kernel" group.
>>> > To unsubscribe from this group and stop receiving emails from it, send an 
>>> > email to outreachy-kernel+unsubscr...@googlegroups.com.
>>> > To post to this group, send email to outreachy-ker...@googlegroups.com.
>>> > To view this discussion on the web visit 
>>> > https://groups.google.com/d/msgid/outreachy-kernel/20170925184728.GA8861%40aishwarya.
>>> > For more options, visit https://groups.google.com/d/optout.
>>>
>>> --
>>> Daniel Vetter
>>> Software Engineer, Intel Corporation
>>> http://blog.ffwll.ch
>>>
>>> --
>>> You received this message because you are subscribed to the Google Groups 
>>> "outreachy-kernel" group.
>>> To unsubscribe from this group and stop receiving emails from it, send an 
>>> email to outreachy-kernel+unsubscr...@googlegroups.com.
>>> To post to this group, send email to outreachy-ker...@googlegroups.com.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/outreachy-kernel/20170926082047.eqsd2lslpqp4pi5f%40phenom.ffwll.local.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>
>
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch



-- 

[Bug 100443] DMESG: [powerplay] Can't find requested voltage id in vdd_dep_on_sclk table!

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=100443

--- Comment #32 from takeshi ogasawara  ---
Hi

After upgrading from kernel 4.12.5 to 4.13.3, the event recurred again.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Outreachy kernel] [PATCH] drm/gem: use new idr deletion interface to cleanup drm_gem_handle_delete()

[Daniel Vetter]

On Tue, Sep 26, 2017 at 10:38 AM, Julia Lawall  wrote:
>
>
> On Tue, 26 Sep 2017, Daniel Vetter wrote:
>
>> On Tue, Sep 26, 2017 at 12:17:28AM +0530, Aishwarya Pant wrote:
>> > The IDR deletion interface now returns the deleted entry or NULL if it was 
>> > not
>> > present. So we don't have to do the extra work of checking if we have a
>> > reference on the drm_gem_object, this can be handled by checking the return
>> > value from idr_remove() and the extra locks can be dropped.
>> >
>> > Signed-off-by: Aishwarya Pant 
>>
>> Haneen is already working on this task, with the patch just merged. Please
>> coordinate with mentors (me or Sean Paul) before starting on something to
>> avoid such clashes in the future.
>>
>> Note also that some todo items are just ideas, and need confirmation with
>> relevant maintainers first.
>
> Not sure where the mixup happened, but anyone who starts on a project
> specific task should note that on the outreachy kernel wiki and before
> starting on a project specific task one should check that no one is
> working on it.  If someone started some time ago, and the code doesn't
> seem to have changed, ask the person who claimed the task or the mentor.

Hm, the dri-devel tasks aren't on the wiki, but in the kernel sources.
Where should we put the scratch-pad to avoid such conflicts in the
future? E.g. the IIO subsytems has it's task on the wiki, where this
works much better.
-Daniel

>
> thanks,
>
> julia
>
>>
>> Thanks, Daniel
>> > ---
>> >  drivers/gpu/drm/drm_gem.c | 21 ++---
>> >  1 file changed, 2 insertions(+), 19 deletions(-)
>> >
>> > diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
>> > index c55f338..f62757a 100644
>> > --- a/drivers/gpu/drm/drm_gem.c
>> > +++ b/drivers/gpu/drm/drm_gem.c
>> > @@ -282,29 +282,12 @@ drm_gem_handle_delete(struct drm_file *filp, u32 
>> > handle)
>> >  {
>> > struct drm_gem_object *obj;
>> >
>> > -   /* This is gross. The idr system doesn't let us try a delete and
>> > -* return an error code.  It just spews if you fail at deleting.
>> > -* So, we have to grab a lock around finding the object and then
>> > -* doing the delete on it and dropping the refcount, or the user
>> > -* could race us to double-decrement the refcount and cause a
>> > -* use-after-free later.  Given the frequency of our handle lookups,
>> > -* we may want to use ida for number allocation and a hash table
>> > -* for the pointers, anyway.
>> > -*/
>> > spin_lock(>table_lock);
>> > -
>> > -   /* Check if we currently have a reference on the object */
>> > -   obj = idr_replace(>object_idr, NULL, handle);
>> > -   spin_unlock(>table_lock);
>> > -   if (IS_ERR_OR_NULL(obj))
>> > +   obj = idr_remove(>object_idr, handle);
>> > +   if (!obj)
>> > return -EINVAL;
>> > -
>> > /* Release driver's reference and decrement refcount. */
>> > drm_gem_object_release_handle(handle, obj, filp);
>> > -
>> > -   /* And finally make the handle available for future allocations. */
>> > -   spin_lock(>table_lock);
>> > -   idr_remove(>object_idr, handle);
>> > spin_unlock(>table_lock);
>> >
>> > return 0;
>> > --
>> > 2.7.4
>> >
>> > --
>> > You received this message because you are subscribed to the Google Groups 
>> > "outreachy-kernel" group.
>> > To unsubscribe from this group and stop receiving emails from it, send an 
>> > email to outreachy-kernel+unsubscr...@googlegroups.com.
>> > To post to this group, send email to outreachy-ker...@googlegroups.com.
>> > To view this discussion on the web visit 
>> > https://groups.google.com/d/msgid/outreachy-kernel/20170925184728.GA8861%40aishwarya.
>> > For more options, visit https://groups.google.com/d/optout.
>>
>> --
>> Daniel Vetter
>> Software Engineer, Intel Corporation
>> http://blog.ffwll.ch
>>
>> --
>> You received this message because you are subscribed to the Google Groups 
>> "outreachy-kernel" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to outreachy-kernel+unsubscr...@googlegroups.com.
>> To post to this group, send email to outreachy-ker...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/outreachy-kernel/20170926082047.eqsd2lslpqp4pi5f%40phenom.ffwll.local.
>> For more options, visit https://groups.google.com/d/optout.
>>



-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Outreachy kernel] [PATCH] drm/gem: use new idr deletion interface to cleanup drm_gem_handle_delete()

[Julia Lawall]

On Tue, 26 Sep 2017, Daniel Vetter wrote:

> On Tue, Sep 26, 2017 at 12:17:28AM +0530, Aishwarya Pant wrote:
> > The IDR deletion interface now returns the deleted entry or NULL if it was 
> > not
> > present. So we don't have to do the extra work of checking if we have a
> > reference on the drm_gem_object, this can be handled by checking the return
> > value from idr_remove() and the extra locks can be dropped.
> >
> > Signed-off-by: Aishwarya Pant 
>
> Haneen is already working on this task, with the patch just merged. Please
> coordinate with mentors (me or Sean Paul) before starting on something to
> avoid such clashes in the future.
>
> Note also that some todo items are just ideas, and need confirmation with
> relevant maintainers first.

Not sure where the mixup happened, but anyone who starts on a project
specific task should note that on the outreachy kernel wiki and before
starting on a project specific task one should check that no one is
working on it.  If someone started some time ago, and the code doesn't
seem to have changed, ask the person who claimed the task or the mentor.

thanks,

julia

>
> Thanks, Daniel
> > ---
> >  drivers/gpu/drm/drm_gem.c | 21 ++---
> >  1 file changed, 2 insertions(+), 19 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
> > index c55f338..f62757a 100644
> > --- a/drivers/gpu/drm/drm_gem.c
> > +++ b/drivers/gpu/drm/drm_gem.c
> > @@ -282,29 +282,12 @@ drm_gem_handle_delete(struct drm_file *filp, u32 
> > handle)
> >  {
> > struct drm_gem_object *obj;
> >
> > -   /* This is gross. The idr system doesn't let us try a delete and
> > -* return an error code.  It just spews if you fail at deleting.
> > -* So, we have to grab a lock around finding the object and then
> > -* doing the delete on it and dropping the refcount, or the user
> > -* could race us to double-decrement the refcount and cause a
> > -* use-after-free later.  Given the frequency of our handle lookups,
> > -* we may want to use ida for number allocation and a hash table
> > -* for the pointers, anyway.
> > -*/
> > spin_lock(>table_lock);
> > -
> > -   /* Check if we currently have a reference on the object */
> > -   obj = idr_replace(>object_idr, NULL, handle);
> > -   spin_unlock(>table_lock);
> > -   if (IS_ERR_OR_NULL(obj))
> > +   obj = idr_remove(>object_idr, handle);
> > +   if (!obj)
> > return -EINVAL;
> > -
> > /* Release driver's reference and decrement refcount. */
> > drm_gem_object_release_handle(handle, obj, filp);
> > -
> > -   /* And finally make the handle available for future allocations. */
> > -   spin_lock(>table_lock);
> > -   idr_remove(>object_idr, handle);
> > spin_unlock(>table_lock);
> >
> > return 0;
> > --
> > 2.7.4
> >
> > --
> > You received this message because you are subscribed to the Google Groups 
> > "outreachy-kernel" group.
> > To unsubscribe from this group and stop receiving emails from it, send an 
> > email to outreachy-kernel+unsubscr...@googlegroups.com.
> > To post to this group, send email to outreachy-ker...@googlegroups.com.
> > To view this discussion on the web visit 
> > https://groups.google.com/d/msgid/outreachy-kernel/20170925184728.GA8861%40aishwarya.
> > For more options, visit https://groups.google.com/d/optout.
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
>
> --
> You received this message because you are subscribed to the Google Groups 
> "outreachy-kernel" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to outreachy-kernel+unsubscr...@googlegroups.com.
> To post to this group, send email to outreachy-ker...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/outreachy-kernel/20170926082047.eqsd2lslpqp4pi5f%40phenom.ffwll.local.
> For more options, visit https://groups.google.com/d/optout.
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Outreachy kernel] [PATCH] drm/gem: use new idr deletion interface to cleanup drm_gem_handle_delete()

[Daniel Vetter]

On Tue, Sep 26, 2017 at 12:17:28AM +0530, Aishwarya Pant wrote:
> The IDR deletion interface now returns the deleted entry or NULL if it was not
> present. So we don't have to do the extra work of checking if we have a
> reference on the drm_gem_object, this can be handled by checking the return
> value from idr_remove() and the extra locks can be dropped.
> 
> Signed-off-by: Aishwarya Pant 

Haneen is already working on this task, with the patch just merged. Please
coordinate with mentors (me or Sean Paul) before starting on something to
avoid such clashes in the future.

Note also that some todo items are just ideas, and need confirmation with
relevant maintainers first.

Thanks, Daniel
> ---
>  drivers/gpu/drm/drm_gem.c | 21 ++---
>  1 file changed, 2 insertions(+), 19 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
> index c55f338..f62757a 100644
> --- a/drivers/gpu/drm/drm_gem.c
> +++ b/drivers/gpu/drm/drm_gem.c
> @@ -282,29 +282,12 @@ drm_gem_handle_delete(struct drm_file *filp, u32 handle)
>  {
>   struct drm_gem_object *obj;
>  
> - /* This is gross. The idr system doesn't let us try a delete and
> -  * return an error code.  It just spews if you fail at deleting.
> -  * So, we have to grab a lock around finding the object and then
> -  * doing the delete on it and dropping the refcount, or the user
> -  * could race us to double-decrement the refcount and cause a
> -  * use-after-free later.  Given the frequency of our handle lookups,
> -  * we may want to use ida for number allocation and a hash table
> -  * for the pointers, anyway.
> -  */
>   spin_lock(>table_lock);
> -
> - /* Check if we currently have a reference on the object */
> - obj = idr_replace(>object_idr, NULL, handle);
> - spin_unlock(>table_lock);
> - if (IS_ERR_OR_NULL(obj))
> + obj = idr_remove(>object_idr, handle);
> + if (!obj)
>   return -EINVAL;
> -
>   /* Release driver's reference and decrement refcount. */
>   drm_gem_object_release_handle(handle, obj, filp);
> -
> - /* And finally make the handle available for future allocations. */
> - spin_lock(>table_lock);
> - idr_remove(>object_idr, handle);
>   spin_unlock(>table_lock);
>  
>   return 0;
> -- 
> 2.7.4
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "outreachy-kernel" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to outreachy-kernel+unsubscr...@googlegroups.com.
> To post to this group, send email to outreachy-ker...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/outreachy-kernel/20170925184728.GA8861%40aishwarya.
> For more options, visit https://groups.google.com/d/optout.

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: RFC: page-flip with damage?

[Daniel Vetter]

On Sun, Sep 24, 2017 at 07:41:45PM +0200, Thomas Hellstrom wrote:
> Hi, list!
> 
> Page flips, while efficient on real hardware, aren't that efficient in other
> situations, like for virtual devices with local, or even worse, remote
> desktops.
> We might ending up forwarding or encoding a couple of full frames worth of
> data instead of a small region at a cursor blink.
> 
> Now there is this extension EGL_KHR_swap_buffers_with_damage, and
> gnome-shell/wayland on KMS also has a damage region that it forwards all the
> way down to the function where page-flip is called.
> 
> So I'd like to start looking at page-flips with damage, meaning that the
> damage is an optional hint to the device about what part of the contents is
> actually updated. What would be the best way to implement this? I figure
> this can be done within the atomic context with a region attached to the
> plane state? Would we want to follow the EGL extension and forward an array
> of rects or for simplicity use a single bounding box? Both these options
> would be a great win.

So my rough plan for all this was:

- Add damage to drm_crtc_state, in screen coordinates. I think this is the
  most natural place for this, since it's what PSR/manual upload DSI want.
  It should also fit well for udl and tinydrm.  Virtual drivers like
  vmwgfx might need helpers to wrap this back to framebuffer rectangles,
  but that seems the odd case out - the framebuffer-based approach in the
  DIRTY_IOCTL forces most drivers to do a fancy lookup from fb to the
  crtc.

  Per-plane dirty rectangle seems to be an awkward in-betwen state, with
  all the confusion about whether it's pre/post scaled and how to best
  combine them. And then someone changes the background color of the crtc
  (or something like that), what happens then? I think pushing all that
  onto userspace is best, it can always ask for a complete flip if it's
  unclear whether it damaged the entire screen or not.

- Add a helper to the atomic core to implement fb_funcs->dirty on top of
  this new atomic state, so that drivers don't have to implement both the
  frontbuffer and the pageflip version of the _with_damage update. Just
  doing a flip (or an async one, if the driver supports that) should work
  well I think.

Wrt single dirty rect vs. rectlist: I'd opt for a single rect since that
makes the interface easier. Currently most drivers collapes the list
passed to fb_funcs->dirty to a single rect, so that seems good enough, and
a nice simplification of the interface (both uapi and driver).

Wrt enabling this on the legacy pageflip ioctl: I wouldn't bother, since
all drivers we reasonable care about are atomic already. One exception is
amdgpu, but that's going to be fixed soonish by merging the DC branch I
hope.

There's definitely lots of people who want to see this happen, that part
is for sure.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 0/3] Split default display handling out from VGA arbiter

[Bjorn Helgaas]

On Fri, Sep 01, 2017 at 05:27:41PM +1000, Daniel Axtens wrote:
> This patch set:
> 
>  - splits the default display handling out from VGA arbiter, into its
>own file and behind its own Kconfig option (and gives the functions
>better names).
> 
>  - adds extra detection of default devices. To be nominated, the vga
>arbiter and platform hooks must not have nominated a default. A
>card will then only be nominated if it has a driver attached and
>has IO or memory decoding enabled.
> 
>  - adds relevant documentation.
> 
> The practical impact of this is improved X autoconfiguration on some
> arm64 systems.

I think I gave you bad advice about trying to separate the "default
device" idea from the VGA arbiter.

It is true that the "VGA arbiter" per se is related to routing the
legacy VGA resources, and the arbiter currently only selects a default
device if it finds a device to which those resources are routed.

We have some cases where we want to select a default device that may
not support the legacy VGA resources, or where they might not be
routed to the device:

  - systems where we match the EFI framebuffer address with a BAR, and
select that device as default,

  - powerpc systems where there may be no host bridge window that maps
to the legacy VGA resources,

  - your ARM64 systems where the default device may be behind a bridge
that doesn't support legacy VGA routing (PCI_BRIDGE_CTL_VGA)

But I think trying to split the "default device" part out from the VGA
arbiter ends up being overkill and making things more complicated
instead of simpler.

Would something like the following work for you as well as the powerpc
case?  On powerpc, we already use vga_set_default_device() to select a
device that doesn't use legacy VGA resources, so maybe we can just do
the same on ARM64?

I suppose there might be wrinkles in how the arbiter deals with
multiple graphics devices on those systems, since I don't think it
identifies these devices that don't use the legacy resources, but it
seems like we live with whatever those on are powerpc and probably can
on ARM64 as well.


diff --git a/arch/powerpc/kernel/pci-common.c b/arch/powerpc/kernel/pci-common.c
index 02831a396419..0ac7aa346c69 100644
--- a/arch/powerpc/kernel/pci-common.c
+++ b/arch/powerpc/kernel/pci-common.c
@@ -1740,15 +1740,3 @@ static void fixup_hide_host_resource_fsl(struct pci_dev 
*dev)
 }
 DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_MOTOROLA, PCI_ANY_ID, 
fixup_hide_host_resource_fsl);
 DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_FREESCALE, PCI_ANY_ID, 
fixup_hide_host_resource_fsl);
-
-static void fixup_vga(struct pci_dev *pdev)
-{
-   u16 cmd;
-
-   pci_read_config_word(pdev, PCI_COMMAND, );
-   if ((cmd & (PCI_COMMAND_IO | PCI_COMMAND_MEMORY)) || 
!vga_default_device())
-   vga_set_default_device(pdev);
-
-}
-DECLARE_PCI_FIXUP_CLASS_FINAL(PCI_ANY_ID, PCI_ANY_ID,
- PCI_CLASS_DISPLAY_VGA, 8, fixup_vga);
diff --git a/drivers/gpu/vga/vgaarb.c b/drivers/gpu/vga/vgaarb.c
index 76875f6299b8..9df4802c5f04 100644
--- a/drivers/gpu/vga/vgaarb.c
+++ b/drivers/gpu/vga/vgaarb.c
@@ -1468,6 +1468,21 @@ static int __init vga_arb_device_init(void)
vgaarb_info(dev, "no bridge control possible\n");
}
 
+   if (!vga_default_device()) {
+   list_for_each_entry(vgadev, _list, list) {
+   struct device *dev = >pdev->dev;
+   u16 cmd;
+
+   pdev = vgadev->pdev;
+   pci_read_config_word(pdev, PCI_COMMAND, );
+   if (cmd & (PCI_COMMAND_IO | PCI_COMMAND_MEMORY)) {
+   vgaarb_info(dev, "setting as boot device\n");
+   vga_set_default_device(pdev);
+   break;
+   }
+   }
+   }
+
pr_info("loaded\n");
return rc;
 }
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 0/8] Add support RK3328 drm hdmi

[Kever Yang]

Hi Algea,

Pls also cc linux-rockc...@lists.infradead.org next time.


Thanks,
- Kever
On 09/25/2017 07:39 PM, Algea Cao wrote:

These patches add support drm hdmi in RK3328 and has been tested in RK 
development
board. Because RK3328 use inno hdmi phy, rockchip-inno-hdmi-phy driver should 
be added.
We add dev_type to distinguish different rockchip chips. Hdmi phy or some regs
configuration can't be switched according to dev_type, that hdmi driver's 
compatibility
will be better.

Algea Cao (8):
   drm/rockchip: dw_hdmi: update dw_hdmi_rockchip_dt_ids
   drm/rockchip: dw_hdmi: add device type
   drm: bridge: dw-hdmi: change hdmi phy hpd read function to export
   drm/rockchip: dw_hdmi: add inno hdmi phy ops
   drm/rockchip: dw_hdmi: add hclk_vio
   drm/rockchip: dw_hdmi: update dw-hdmi encoder enable
   drm: bridge: dw-hdmi: get phy ops by device type
   phy: rockchip: add inno hdmi phy to makefile

  drivers/gpu/drm/bridge/synopsys/dw-hdmi.c   |  11 +-
  drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 162 +++-
  drivers/phy/rockchip/Kconfig|   7 ++
  drivers/phy/rockchip/Makefile   |   1 +
  include/drm/bridge/dw_hdmi.h|  13 ++-
  5 files changed, 186 insertions(+), 8 deletions(-)




___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 8/8] phy: rockchip: add inno hdmi phy to makefile

[Algea Cao]

Support some SOCs,such as RK3328.

Signed-off-by: Algea Cao 
---
 drivers/phy/rockchip/Kconfig  | 7 +++
 drivers/phy/rockchip/Makefile | 1 +
 2 files changed, 8 insertions(+)

diff --git a/drivers/phy/rockchip/Kconfig b/drivers/phy/rockchip/Kconfig
index f5325b2..b021dc7 100644
--- a/drivers/phy/rockchip/Kconfig
+++ b/drivers/phy/rockchip/Kconfig
@@ -8,6 +8,13 @@ config PHY_ROCKCHIP_DP
help
  Enable this to support the Rockchip Display Port PHY.
 
+config PHY_ROCKCHIP_INNO_HDMI_PHY
+   tristate "Rockchip INNO HDMI PHY Driver"
+   depends on ARCH_ROCKCHIP && OF
+   select GENERIC_PHY
+   help
+ Enable this to support the Rockchip HDMI PHY with Innosilicon IP 
block.
+
 config PHY_ROCKCHIP_EMMC
tristate "Rockchip EMMC PHY Driver"
depends on ARCH_ROCKCHIP && OF
diff --git a/drivers/phy/rockchip/Makefile b/drivers/phy/rockchip/Makefile
index bd0acdf..6c1adc0 100644
--- a/drivers/phy/rockchip/Makefile
+++ b/drivers/phy/rockchip/Makefile
@@ -4,3 +4,4 @@ obj-$(CONFIG_PHY_ROCKCHIP_INNO_USB2)+= 
phy-rockchip-inno-usb2.o
 obj-$(CONFIG_PHY_ROCKCHIP_PCIE)+= phy-rockchip-pcie.o
 obj-$(CONFIG_PHY_ROCKCHIP_TYPEC)   += phy-rockchip-typec.o
 obj-$(CONFIG_PHY_ROCKCHIP_USB) += phy-rockchip-usb.o
+obj-$(CONFIG_PHY_ROCKCHIP_INNO_HDMI_PHY)   += phy-rockchip-inno-hdmi-phy.o
\ No newline at end of file
-- 
2.7.4


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 3/8] drm: bridge: dw-hdmi: change hdmi phy hpd read function to export

[Algea Cao]

Change dw_hdmi_phy_read_hpd from static to export.
inno hdmi phy ops will call this interface to get
hpd status.

Signed-off-by: Algea Cao 
---
 drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 5 +++--
 include/drm/bridge/dw_hdmi.h  | 3 ++-
 2 files changed, 5 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c 
b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
index 5e023cb..5adb04b 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
@@ -1239,12 +1239,13 @@ static void dw_hdmi_phy_disable(struct dw_hdmi *hdmi, 
void *data)
dw_hdmi_phy_power_off(hdmi);
 }
 
-static enum drm_connector_status dw_hdmi_phy_read_hpd(struct dw_hdmi *hdmi,
- void *data)
+enum drm_connector_status dw_hdmi_phy_read_hpd(struct dw_hdmi *hdmi,
+  void *data)
 {
return hdmi_readb(hdmi, HDMI_PHY_STAT0) & HDMI_PHY_HPD ?
connector_status_connected : connector_status_disconnected;
 }
+EXPORT_SYMBOL_GPL(dw_hdmi_phy_read_hpd);
 
 static void dw_hdmi_phy_update_hpd(struct dw_hdmi *hdmi, void *data,
   bool force, bool disabled, bool rxsense)
diff --git a/include/drm/bridge/dw_hdmi.h b/include/drm/bridge/dw_hdmi.h
index fdb1f0a..01e4979 100644
--- a/include/drm/bridge/dw_hdmi.h
+++ b/include/drm/bridge/dw_hdmi.h
@@ -161,7 +161,8 @@ int dw_hdmi_bind(struct platform_device *pdev, struct 
drm_encoder *encoder,
 const struct dw_hdmi_plat_data *plat_data);
 
 void dw_hdmi_setup_rx_sense(struct device *dev, bool hpd, bool rx_sense);
-
+enum drm_connector_status dw_hdmi_phy_read_hpd(struct dw_hdmi *hdmi,
+  void *data);
 void dw_hdmi_set_sample_rate(struct dw_hdmi *hdmi, unsigned int rate);
 void dw_hdmi_audio_enable(struct dw_hdmi *hdmi);
 void dw_hdmi_audio_disable(struct dw_hdmi *hdmi);
-- 
2.7.4


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/3] drm: rcar-du: Share plane atomic check code between Gen2 and Gen3

[Kieran Bingham]

Hi Laurent,

On 16/08/17 00:03, Laurent Pinchart wrote:
> The plane atomic check implementation is identical on Gen2 (DU planes)
> and Gen3 (VSP planes), but two separate functions exist as they operate
> on different data structures. Refactor the code to share the
> implementation.
> 
> Signed-off-by: Laurent Pinchart 

This looks good to me.

Reviewed-by: Kieran Bingham 

> ---
>  drivers/gpu/drm/rcar-du/rcar_du_plane.c | 27 +--
>  drivers/gpu/drm/rcar-du/rcar_du_plane.h |  4 
>  drivers/gpu/drm/rcar-du/rcar_du_vsp.c   | 22 +-
>  3 files changed, 22 insertions(+), 31 deletions(-)
> 
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_plane.c 
> b/drivers/gpu/drm/rcar-du/rcar_du_plane.c
> index 61833cc1c699..4f076c364f25 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_plane.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_plane.c
> @@ -565,27 +565,26 @@ void __rcar_du_plane_setup(struct rcar_du_group *rgrp,
>   }
>  }
>  
> -static int rcar_du_plane_atomic_check(struct drm_plane *plane,
> -   struct drm_plane_state *state)
> +int __rcar_du_plane_atomic_check(struct drm_plane *plane,
> +  struct drm_plane_state *state,
> +  const struct rcar_du_format_info **format)
>  {
> - struct rcar_du_plane_state *rstate = to_rcar_plane_state(state);
> - struct rcar_du_plane *rplane = to_rcar_plane(plane);
> - struct rcar_du_device *rcdu = rplane->group->dev;
> + struct drm_device *dev = plane->dev;
>  
>   if (!state->fb || !state->crtc) {
> - rstate->format = NULL;
> + *format = NULL;
>   return 0;
>   }
>  
>   if (state->src_w >> 16 != state->crtc_w ||
>   state->src_h >> 16 != state->crtc_h) {
> - dev_dbg(rcdu->dev, "%s: scaling not supported\n", __func__);
> + dev_dbg(dev->dev, "%s: scaling not supported\n", __func__);
>   return -EINVAL;
>   }
>  
> - rstate->format = rcar_du_format_info(state->fb->format->format);
> - if (rstate->format == NULL) {
> - dev_dbg(rcdu->dev, "%s: unsupported format %08x\n", __func__,
> + *format = rcar_du_format_info(state->fb->format->format);
> + if (*format == NULL) {
> + dev_dbg(dev->dev, "%s: unsupported format %08x\n", __func__,
>   state->fb->format->format);
>   return -EINVAL;
>   }
> @@ -593,6 +592,14 @@ static int rcar_du_plane_atomic_check(struct drm_plane 
> *plane,
>   return 0;
>  }
>  
> +static int rcar_du_plane_atomic_check(struct drm_plane *plane,
> +   struct drm_plane_state *state)
> +{
> + struct rcar_du_plane_state *rstate = to_rcar_plane_state(state);
> +
> + return __rcar_du_plane_atomic_check(plane, state, >format);
> +}
> +
>  static void rcar_du_plane_atomic_update(struct drm_plane *plane,
>   struct drm_plane_state *old_state)
>  {
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_plane.h 
> b/drivers/gpu/drm/rcar-du/rcar_du_plane.h
> index f62e09f195de..890321b4665d 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_plane.h
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_plane.h
> @@ -73,6 +73,10 @@ to_rcar_plane_state(struct drm_plane_state *state)
>  int rcar_du_atomic_check_planes(struct drm_device *dev,
>   struct drm_atomic_state *state);
>  
> +int __rcar_du_plane_atomic_check(struct drm_plane *plane,
> +  struct drm_plane_state *state,
> +  const struct rcar_du_format_info **format);
> +
>  int rcar_du_planes_init(struct rcar_du_group *rgrp);
>  
>  void __rcar_du_plane_setup(struct rcar_du_group *rgrp,
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c 
> b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
> index 2c96147bc444..dd66dcb8da23 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
> @@ -268,28 +268,8 @@ static int rcar_du_vsp_plane_atomic_check(struct 
> drm_plane *plane,
> struct drm_plane_state *state)
>  {
>   struct rcar_du_vsp_plane_state *rstate = to_rcar_vsp_plane_state(state);
> - struct rcar_du_vsp_plane *rplane = to_rcar_vsp_plane(plane);
> - struct rcar_du_device *rcdu = rplane->vsp->dev;
> -
> - if (!state->fb || !state->crtc) {
> - rstate->format = NULL;
> - return 0;
> - }
>  
> - if (state->src_w >> 16 != state->crtc_w ||
> - state->src_h >> 16 != state->crtc_h) {
> - dev_dbg(rcdu->dev, "%s: scaling not supported\n", __func__);
> - return -EINVAL;
> - }
> -
> - rstate->format = rcar_du_format_info(state->fb->format->format);
> - if (rstate->format == NULL) {
> - dev_dbg(rcdu->dev, "%s: unsupported 

Re: [PATCH] panel: display: Add support for Mitsubishi aa070mc01 TFT panel

[Łukasz Majewski]

On 09/08/2017 11:43 AM, Lukasz Majewski wrote:

This commit adds support for Mitsubishi aa070mc01 TFT panel working
with 8 bit ISP mode (pin 19 "mode" HIGH for 20 pin TFT connector).

Signed-off-by: Lukasz Majewski 


Gentle ping on this patch.

Anyone could express their opinion?

Thanks in advance,
Łukasz


---
  drivers/gpu/drm/panel/panel-simple.c | 35 +++
  1 file changed, 35 insertions(+)

diff --git a/drivers/gpu/drm/panel/panel-simple.c 
b/drivers/gpu/drm/panel/panel-simple.c
index 3d2cb8b..0c64ec6 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -1141,6 +1141,38 @@ static const struct panel_desc innolux_g121x1_l03 = {
},
  };
  
+static const struct drm_display_mode mitsubishi_aa070mc01_mode = {

+   .clock = 30400,
+   .hdisplay = 800,
+   .hsync_start = 800 + 0,
+   .hsync_end = 800 + 1,
+   .htotal = 800 + 0 + 1 + 160,
+   .vdisplay = 480,
+   .vsync_start = 480 + 0,
+   .vsync_end = 480 + 48 + 1,
+   .vtotal = 480 + 48 + 1 + 0,
+   .vrefresh = 60,
+   .flags = DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC,
+};
+
+static const struct panel_desc mitsubishi_aa070mc01 = {
+   .modes = _aa070mc01_mode,
+   .num_modes = 1,
+   .bpc = 8,
+   .size = {
+   .width = 152,
+   .height = 91,
+   },
+
+   .delay = {
+   .enable = 200,
+   .unprepare = 200,
+   .disable = 400,
+   },
+   .bus_format = MEDIA_BUS_FMT_RGB888_1X7X4_SPWG,
+   .bus_flags = DRM_BUS_FLAG_DE_HIGH,
+};
+
  static const struct drm_display_mode innolux_n116bge_mode = {
.clock = 76420,
.hdisplay = 1366,
@@ -2029,6 +2061,9 @@ static const struct of_device_id platform_of_match[] = {
.compatible = "innolux,g121x1-l03",
.data = _g121x1_l03,
}, {
+   .compatible = "mitsubishi,aa070mc01-ca1",
+   .data = _aa070mc01,
+   }, {
.compatible = "innolux,n116bge",
.data = _n116bge,
}, {




--
Best regards,

Lukasz Majewski

--

DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 4/8] drm/rockchip: dw_hdmi: add inno hdmi phy ops

[Algea Cao]

Because some RK chips use inno hdmi phy, such as RK3328, we add
inno hdmi phy ops. Ultimately, these ops will call functions in
/drivers/phy/rockchip/phy-rockchip-inno-hdmi-phy.c.

Signed-off-by: Algea Cao 
---
 drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 110 +++-
 1 file changed, 107 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c 
b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
index fdab383..35b466b 100644
--- a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
+++ b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
@@ -12,7 +12,7 @@
 #include 
 #include 
 #include 
-
+#include 
 #include 
 #include 
 #include 
@@ -26,6 +26,18 @@
 #define RK3288_HDMI_LCDC_SEL   BIT(4)
 #define RK3399_GRF_SOC_CON20   0x6250
 #define RK3399_HDMI_LCDC_SEL   BIT(6)
+#define RK3328_GRF_SOC_CON20x0408
+#define RK3328_DDC_MASK_EN ((3 << 10) | (3 << (10 + 16)))
+#define RK3328_GRF_SOC_CON30x040c
+#define RK3328_IO_CTRL_BY_HDMI (0xf000 | BIT(13) | BIT(12))
+#define RK3328_GRF_SOC_CON40x0410
+#define RK3328_IO_3V_DOMAIN(7 << (9 + 16))
+#define RK3328_IO_5V_DOMAIN((7 << 9) | (3 << (9 + 16)))
+#define RK3328_HPD_3V  (BIT(8 + 16) | BIT(13 + 16))
+#define RK3228_GRF_SOC_CON20x0408
+#define RK3228_DDC_MASK_EN ((3 << 13) | (3 << (13 + 16)))
+#define RK3228_GRF_SOC_CON60x0418
+#define RK3228_IO_3V_DOMAIN((7 << 4) | (7 << (4 + 16)))
 
 #define HIWORD_UPDATE(val, mask)   (val | (mask) << 16)
 
@@ -49,10 +61,82 @@ struct rockchip_hdmi {
enum dw_hdmi_devtype dev_type;
struct clk *vpll_clk;
struct clk *grf_clk;
+   struct phy *phy;
 };
 
 #define to_rockchip_hdmi(x)container_of(x, struct rockchip_hdmi, x)
 
+static int
+inno_dw_hdmi_phy_init(struct dw_hdmi *dw_hdmi, void *data,
+ struct drm_display_mode *mode)
+{
+   struct rockchip_hdmi *hdmi = (struct rockchip_hdmi *)data;
+
+   return phy_power_on(hdmi->phy);
+}
+
+static void inno_dw_hdmi_phy_disable(struct dw_hdmi *dw_hdmi, void *data)
+{
+   struct rockchip_hdmi *hdmi = (struct rockchip_hdmi *)data;
+
+   phy_power_off(hdmi->phy);
+}
+
+static enum drm_connector_status
+inno_dw_hdmi_phy_read_hpd(struct dw_hdmi *dw_hdmi, void *data)
+{
+   struct rockchip_hdmi *hdmi = (struct rockchip_hdmi *)data;
+   enum drm_connector_status status;
+
+   status = dw_hdmi_phy_read_hpd(dw_hdmi, data);
+
+   if (hdmi->dev_type == RK3228_HDMI)
+   return status;
+
+   if (status == connector_status_connected)
+   regmap_write(hdmi->regmap,
+RK3328_GRF_SOC_CON4,
+RK3328_IO_5V_DOMAIN);
+   else
+   regmap_write(hdmi->regmap,
+RK3328_GRF_SOC_CON4,
+RK3328_IO_3V_DOMAIN);
+   return status;
+}
+
+static int inno_dw_hdmi_init(struct rockchip_hdmi *hdmi)
+{
+   int ret;
+
+   ret = clk_prepare_enable(hdmi->grf_clk);
+   if (ret < 0) {
+   dev_err(hdmi->dev, "failed to enable grfclk %d\n", ret);
+   return -EPROBE_DEFER;
+   }
+   if (hdmi->dev_type == RK3328_HDMI) {
+   /* Map HPD pin to 3V io */
+   regmap_write(hdmi->regmap,
+RK3328_GRF_SOC_CON4,
+RK3328_IO_3V_DOMAIN |
+RK3328_HPD_3V);
+   /* Map ddc pin to 5V io */
+   regmap_write(hdmi->regmap,
+RK3328_GRF_SOC_CON3,
+RK3328_IO_CTRL_BY_HDMI);
+   regmap_write(hdmi->regmap,
+RK3328_GRF_SOC_CON2,
+RK3328_DDC_MASK_EN |
+BIT(18));
+   } else {
+   regmap_write(hdmi->regmap, RK3228_GRF_SOC_CON2,
+RK3228_DDC_MASK_EN);
+   regmap_write(hdmi->regmap, RK3228_GRF_SOC_CON6,
+RK3228_IO_3V_DOMAIN);
+   }
+   clk_disable_unprepare(hdmi->grf_clk);
+   return 0;
+}
+
 static const struct dw_hdmi_mpll_config rockchip_mpll_cfg[] = {
{
2700, {
@@ -294,6 +378,12 @@ static const struct drm_encoder_helper_funcs 
dw_hdmi_rockchip_encoder_helper_fun
.atomic_check = dw_hdmi_rockchip_encoder_atomic_check,
 };
 
+static const struct dw_hdmi_phy_ops inno_dw_hdmi_phy_ops = {
+   .init   = inno_dw_hdmi_phy_init,
+   .disable= inno_dw_hdmi_phy_disable,
+   .read_hpd   = inno_dw_hdmi_phy_read_hpd,
+};
+
 static struct rockchip_hdmi_chip_data rk3288_chip_data = {
.lcdsel_grf_reg = RK3288_GRF_SOC_CON6,
.lcdsel_big = HIWORD_UPDATE(0, RK3288_HDMI_LCDC_SEL),
@@ -317,6 +407,8 @@ static struct 

[next] drm/atomic: NULL pointer dereference

[Sergey Senozhatsky]

Hello,

after commit 669c9215afea4e ("drm/atomic: Make async plane update
checks work as intended") drm_atomic_helper_async_check() can NULL
deference the `new_plane_state' pointer and crashe the kernel at
'new_plane_state->crtc':

BUG: unable to handle kernel NULL pointer dereference at 0008
IP: drm_atomic_helper_async_check+0x70/0xcb
PGD 0 P4D 0
Oops:  [#1] PREEMPT SMP
[..]
task: 880131ac2280 task.stack: c9464000
RIP: 0010:drm_atomic_helper_async_check+0x70/0xcb
RSP: 0018:c9467a48 EFLAGS: 00010246
RAX: 880131917b60 RBX:  RCX: 
RDX: 0004 RSI: 880131753480 RDI: 
RBP:  R08: 0004 R09: 0001
R10: 880130d3255c R11: 880130e56e18 R12: 88013167
R13:  R14: 88013167 R15: 0004
FS:  7fc218f6e940() GS:880137d8() knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2: 0008 CR3: 000132aca000 CR4: 06e0
Call Trace:
 drm_atomic_helper_check+0x3c/0x5a
 nv50_disp_atomic_check+0x15/0x10b
 drm_atomic_check_only+0x2c0/0x42a
 drm_atomic_commit+0x13/0x4d
 drm_atomic_helper_update_plane+0xc9/0xe6
 __setplane_internal+0x1c8/0x229
 ? drm_internal_framebuffer_create+0x314/0x35a
 drm_mode_cursor_universal+0x130/0x15f
 drm_mode_cursor_common+0xcc/0x184
 ? drm_mode_setplane+0x183/0x183
 drm_mode_cursor_ioctl+0x2f/0x34
 drm_ioctl_kernel+0x61/0x9a
 drm_ioctl+0x1d6/0x2a8
 ? drm_mode_setplane+0x183/0x183
 ? _raw_spin_unlock+0x12/0x23
 ? do_wp_page+0x159/0x22e
 ? _raw_spin_unlock_irqrestore+0x14/0x25
 nouveau_drm_ioctl+0x71/0xa4
 vfs_ioctl+0x1b/0x28
 do_vfs_ioctl+0x5a9/0x5bc
 ? handle_mm_fault+0x98/0x9e
 ? __fget+0x5d/0x67
 SyS_ioctl+0x3e/0x5a
 entry_SYSCALL_64_fastpath+0x13/0x94


the below patch fixes the issues for me.

---
 drivers/gpu/drm/drm_atomic_helper.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index 01c34bc5b5b0..922f4d3b17aa 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -1405,7 +1405,7 @@ int drm_atomic_helper_async_check(struct drm_device *dev,
if (n_planes != 1)
return -EINVAL;
 
-   if (!new_plane_state->crtc)
+   if (!new_plane_state || !new_plane_state->crtc)
return -EINVAL;
 
funcs = plane->helper_private;
-- 
2.14.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 0/8] Add support RK3328 drm hdmi

[Algea Cao]

These patches add support drm hdmi in RK3328 and has been tested in RK 
development
board. Because RK3328 use inno hdmi phy, rockchip-inno-hdmi-phy driver should 
be added.
We add dev_type to distinguish different rockchip chips. Hdmi phy or some regs
configuration can't be switched according to dev_type, that hdmi driver's 
compatibility
will be better.

Algea Cao (8):
  drm/rockchip: dw_hdmi: update dw_hdmi_rockchip_dt_ids
  drm/rockchip: dw_hdmi: add device type
  drm: bridge: dw-hdmi: change hdmi phy hpd read function to export
  drm/rockchip: dw_hdmi: add inno hdmi phy ops
  drm/rockchip: dw_hdmi: add hclk_vio
  drm/rockchip: dw_hdmi: update dw-hdmi encoder enable
  drm: bridge: dw-hdmi: get phy ops by device type
  phy: rockchip: add inno hdmi phy to makefile

 drivers/gpu/drm/bridge/synopsys/dw-hdmi.c   |  11 +-
 drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 162 +++-
 drivers/phy/rockchip/Kconfig|   7 ++
 drivers/phy/rockchip/Makefile   |   1 +
 include/drm/bridge/dw_hdmi.h|  13 ++-
 5 files changed, 186 insertions(+), 8 deletions(-)

-- 
2.7.4


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 7/8] drm: bridge: dw-hdmi: get phy ops by device type

[Algea Cao]

Add device type to distinguish different chips.Different chips
use different phy ops, get them by device type.

Signed-off-by: Algea Cao 
---
 drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c 
b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
index 5adb04b..bfb76cd 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
@@ -139,6 +139,7 @@ struct dw_hdmi {
const struct dw_hdmi_plat_data *plat_data;
 
int vic;
+   enum dw_hdmi_devtype dev_type;
 
u8 edid[HDMI_EDID_LEN];
bool cable_plugin;
@@ -2185,7 +2186,9 @@ static int dw_hdmi_detect_phy(struct dw_hdmi *hdmi)
 
phy_type = hdmi_readb(hdmi, HDMI_CONFIG2_ID);
 
-   if (phy_type == DW_HDMI_PHY_VENDOR_PHY) {
+   if (phy_type == DW_HDMI_PHY_VENDOR_PHY ||
+   hdmi->dev_type == RK3328_HDMI ||
+   hdmi->dev_type == RK3228_HDMI) {
/* Vendor PHYs require support from the glue layer. */
if (!hdmi->plat_data->phy_ops || !hdmi->plat_data->phy_name) {
dev_err(hdmi->dev,
@@ -2257,6 +2260,7 @@ __dw_hdmi_probe(struct platform_device *pdev,
if (!hdmi)
return ERR_PTR(-ENOMEM);
 
+   hdmi->dev_type = plat_data->dev_type;
hdmi->plat_data = plat_data;
hdmi->dev = dev;
hdmi->sample_rate = 48000;
-- 
2.7.4


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 2/8] drm/rockchip: dw_hdmi: add device type

[Algea Cao]

To determine type of SOC, we add a parameter dev_type.

Signed-off-by: Algea Cao 
---
 drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c |  5 +
 include/drm/bridge/dw_hdmi.h| 10 ++
 2 files changed, 15 insertions(+)

diff --git a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c 
b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
index b031005..fdab383 100644
--- a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
+++ b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
@@ -46,6 +46,7 @@ struct rockchip_hdmi {
struct regmap *regmap;
struct drm_encoder encoder;
const struct rockchip_hdmi_chip_data *chip_data;
+   enum dw_hdmi_devtype dev_type;
struct clk *vpll_clk;
struct clk *grf_clk;
 };
@@ -305,6 +306,7 @@ static const struct dw_hdmi_plat_data rk3288_hdmi_drv_data 
= {
.cur_ctr= rockchip_cur_ctr,
.phy_config = rockchip_phy_config,
.phy_data = _chip_data,
+   .dev_type   = RK3288_HDMI,
 };
 
 static struct rockchip_hdmi_chip_data rk3399_chip_data = {
@@ -315,6 +317,7 @@ static struct rockchip_hdmi_chip_data rk3399_chip_data = {
 
 static const struct dw_hdmi_plat_data rk3328_hdmi_drv_data = {
.mode_valid = dw_hdmi_rockchip_mode_valid,
+   .dev_type   = RK3328_HDMI,
 };
 
 static const struct dw_hdmi_plat_data rk3399_hdmi_drv_data = {
@@ -323,6 +326,7 @@ static const struct dw_hdmi_plat_data rk3399_hdmi_drv_data 
= {
.cur_ctr= rockchip_cur_ctr,
.phy_config = rockchip_phy_config,
.phy_data = _chip_data,
+   .dev_type   = RK3399_HDMI,
 };
 
 static const struct of_device_id dw_hdmi_rockchip_dt_ids[] = {
@@ -361,6 +365,7 @@ static int dw_hdmi_rockchip_bind(struct device *dev, struct 
device *master,
plat_data = match->data;
hdmi->dev = >dev;
hdmi->chip_data = plat_data->phy_data;
+   hdmi->dev_type = plat_data->dev_type;
encoder = >encoder;
 
encoder->possible_crtcs = drm_of_find_possible_crtcs(drm, dev->of_node);
diff --git a/include/drm/bridge/dw_hdmi.h b/include/drm/bridge/dw_hdmi.h
index 182f832..fdb1f0a 100644
--- a/include/drm/bridge/dw_hdmi.h
+++ b/include/drm/bridge/dw_hdmi.h
@@ -92,6 +92,15 @@ enum dw_hdmi_phy_type {
DW_HDMI_PHY_VENDOR_PHY = 0xfe,
 };
 
+enum dw_hdmi_devtype {
+   RK3228_HDMI,
+   RK3288_HDMI,
+   RK3328_HDMI,
+   RK3366_HDMI,
+   RK3368_HDMI,
+   RK3399_HDMI,
+};
+
 struct dw_hdmi_mpll_config {
unsigned long mpixelclock;
struct {
@@ -124,6 +133,7 @@ struct dw_hdmi_phy_ops {
 
 struct dw_hdmi_plat_data {
struct regmap *regm;
+   enum dw_hdmi_devtype dev_type;
enum drm_mode_status (*mode_valid)(struct drm_connector *connector,
   const struct drm_display_mode *mode);
unsigned long input_bus_format;
-- 
2.7.4


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/gem: use new idr deletion interface to cleanup drm_gem_handle_delete()

[Aishwarya Pant]

The IDR deletion interface now returns the deleted entry or NULL if it was not
present. So we don't have to do the extra work of checking if we have a
reference on the drm_gem_object, this can be handled by checking the return
value from idr_remove() and the extra locks can be dropped.

Signed-off-by: Aishwarya Pant 
---
 drivers/gpu/drm/drm_gem.c | 21 ++---
 1 file changed, 2 insertions(+), 19 deletions(-)

diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
index c55f338..f62757a 100644
--- a/drivers/gpu/drm/drm_gem.c
+++ b/drivers/gpu/drm/drm_gem.c
@@ -282,29 +282,12 @@ drm_gem_handle_delete(struct drm_file *filp, u32 handle)
 {
struct drm_gem_object *obj;
 
-   /* This is gross. The idr system doesn't let us try a delete and
-* return an error code.  It just spews if you fail at deleting.
-* So, we have to grab a lock around finding the object and then
-* doing the delete on it and dropping the refcount, or the user
-* could race us to double-decrement the refcount and cause a
-* use-after-free later.  Given the frequency of our handle lookups,
-* we may want to use ida for number allocation and a hash table
-* for the pointers, anyway.
-*/
spin_lock(>table_lock);
-
-   /* Check if we currently have a reference on the object */
-   obj = idr_replace(>object_idr, NULL, handle);
-   spin_unlock(>table_lock);
-   if (IS_ERR_OR_NULL(obj))
+   obj = idr_remove(>object_idr, handle);
+   if (!obj)
return -EINVAL;
-
/* Release driver's reference and decrement refcount. */
drm_gem_object_release_handle(handle, obj, filp);
-
-   /* And finally make the handle available for future allocations. */
-   spin_lock(>table_lock);
-   idr_remove(>object_idr, handle);
spin_unlock(>table_lock);
 
return 0;
-- 
2.7.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 5/8] drm/rockchip: dw_hdmi: add hclk_vio

[Algea Cao]

Add clk hclk_vio and enable it when hdmi bind.

Signed-off-by: Algea Cao 
---
 drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 21 +
 1 file changed, 21 insertions(+)

diff --git a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c 
b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
index 35b466b..ab44e13 100644
--- a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
+++ b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
@@ -61,6 +61,7 @@ struct rockchip_hdmi {
enum dw_hdmi_devtype dev_type;
struct clk *vpll_clk;
struct clk *grf_clk;
+   struct clk *hclk_vio;
struct phy *phy;
 };
 
@@ -277,12 +278,27 @@ static int rockchip_hdmi_parse_dt(struct rockchip_hdmi 
*hdmi)
return PTR_ERR(hdmi->grf_clk);
}
 
+   hdmi->hclk_vio = devm_clk_get(hdmi->dev, "hclk_vio");
+   if (PTR_ERR(hdmi->hclk_vio) == -ENOENT) {
+   hdmi->hclk_vio = NULL;
+   } else if (PTR_ERR(hdmi->hclk_vio) == -EPROBE_DEFER) {
+   return -EPROBE_DEFER;
+   } else if (IS_ERR(hdmi->hclk_vio)) {
+   dev_dbg(hdmi->dev, "failed to get hclk_vio clock\n");
+   return PTR_ERR(hdmi->hclk_vio);
+   }
ret = clk_prepare_enable(hdmi->vpll_clk);
if (ret) {
dev_err(hdmi->dev, "Failed to enable HDMI vpll: %d\n", ret);
return ret;
}
 
+   ret = clk_prepare_enable(hdmi->hclk_vio);
+   if (ret) {
+   dev_dbg(hdmi->dev, "Failed to eanble HDMI hclk_vio: %d\n",
+   ret);
+   return ret;
+   }
return 0;
 }
 
@@ -507,6 +523,11 @@ static int dw_hdmi_rockchip_bind(struct device *dev, 
struct device *master,
 static void dw_hdmi_rockchip_unbind(struct device *dev, struct device *master,
void *data)
 {
+   struct rockchip_hdmi *hdmi = container_of(, struct rockchip_hdmi,
+ dev);
+
+   clk_disable_unprepare(hdmi->hclk_vio);
+
return dw_hdmi_unbind(dev);
 }
 
-- 
2.7.4


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/atomic: Make async plane update checks actually work as intended.

[Dmitry Osipenko]

On 25.09.2017 09:43, Maarten Lankhorst wrote:
> Op 24-09-17 om 16:33 schreef Dmitry Osipenko:
>> On 04.09.2017 13:48, Maarten Lankhorst wrote:
>>> By always keeping track of the last commit in plane_state, we know
>>> whether there is an active update on the plane or not. With that
>>> information we can reject the fast update, and force the slowpath
>>> to be used as was originally intended.
>>>
>>> We cannot use plane_state->crtc->state here, because this only mentions
>>> the most recent commit for the crtc, but not the planes that were part
>>> of it. We specifically care about what the last commit involving this
>>> plane is, which can only be tracked with a pointer in the plane state.
>>>
>>> Changes since v1:
>>> - Clean up the whole function here, instead of partially earlier.
>>> - Add mention in the commit message why we need commit in plane_state.
>>> - Swap plane->state in intel_legacy_cursor_update, instead of
>>>   reassigning all variables. With this commit We know that the cursor
>>>   is not part of any active commits so this hack can be removed.
>>>
>>> Cc: Gustavo Padovan 
>>> Signed-off-by: Maarten Lankhorst 
>>> Reviewed-by: Gustavo Padovan 
>>> Reviewed-by: Daniel Vetter  #v1
>>> ---
>>>  drivers/gpu/drm/drm_atomic_helper.c  | 53 
>>> ++--
>>>  drivers/gpu/drm/i915/intel_display.c | 27 +++---
>>>  include/drm/drm_plane.h  |  5 ++--
>>>  3 files changed, 35 insertions(+), 50 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
>>> b/drivers/gpu/drm/drm_atomic_helper.c
>>> index c81d46927a74..a2cd432d8b2d 100644
>>> --- a/drivers/gpu/drm/drm_atomic_helper.c
>>> +++ b/drivers/gpu/drm/drm_atomic_helper.c
>>> @@ -1388,35 +1388,31 @@ int drm_atomic_helper_async_check(struct drm_device 
>>> *dev,
>>>  {
>>> struct drm_crtc *crtc;
>>> struct drm_crtc_state *crtc_state;
>>> -   struct drm_crtc_commit *commit;
>>> -   struct drm_plane *__plane, *plane = NULL;
>>> -   struct drm_plane_state *__plane_state, *plane_state = NULL;
>>> +   struct drm_plane *plane;
>>> +   struct drm_plane_state *old_plane_state, *new_plane_state;
>>> const struct drm_plane_helper_funcs *funcs;
>>> -   int i, j, n_planes = 0;
>>> +   int i, n_planes = 0;
>>>  
>>> for_each_new_crtc_in_state(state, crtc, crtc_state, i) {
>>> if (drm_atomic_crtc_needs_modeset(crtc_state))
>>> return -EINVAL;
>>> }
>>>  
>>> -   for_each_new_plane_in_state(state, __plane, __plane_state, i) {
>>> +   for_each_oldnew_plane_in_state(state, plane, old_plane_state, 
>>> new_plane_state, i)
>>> n_planes++;
>>> -   plane = __plane;
>>> -   plane_state = __plane_state;
>>> -   }
>>>  
>>> /* FIXME: we support only single plane updates for now */
>>> -   if (!plane || n_planes != 1)
>>> +   if (n_planes != 1)
>>> return -EINVAL;
>>>  
>>> -   if (!plane_state->crtc)
>>> +   if (!new_plane_state->crtc)
>>> return -EINVAL;
>>>  
>> Hello,
>>
>> It looks like a NULL-checking of new_plane_state is missed here.
>>
>> [   70.138947] [] (drm_atomic_helper_async_check) from []
>> (drm_atomic_helper_check+0x4c/0x64)
>> [   70.138958] [] (drm_atomic_helper_check) from []
>> (drm_atomic_check_only+0x2f4/0x56c)
>> [   70.138969] [] (drm_atomic_check_only) from []
>> (drm_atomic_commit+0x10/0x50)
>> [   70.138979] [] (drm_atomic_commit) from []
>> (drm_atomic_helper_update_plane+0xf0/0x100)
>> [   70.138991] [] (drm_atomic_helper_update_plane) from 
>> []
>> (__setplane_internal+0x178/0x214)
>> [   70.139003] [] (__setplane_internal) from []
>> (drm_mode_cursor_universal+0x118/0x1a8)
>> [   70.139014] [] (drm_mode_cursor_universal) from []
>> (drm_mode_cursor_common+0x174/0x1ec)
>> [   70.139026] [] (drm_mode_cursor_common) from []
>> (drm_mode_cursor_ioctl+0x58/0x60)
>> [   70.139036] [] (drm_mode_cursor_ioctl) from []
>> (drm_ioctl+0x198/0x368)
>> [   70.139047] [] (drm_ioctl) from [] 
>> (do_vfs_ioctl+0x9c/0x8f0)
>> [   70.139058] [] (do_vfs_ioctl) from [] 
>> (SyS_ioctl+0x34/0x5c)
>> [   70.139071] [] (SyS_ioctl) from []
>> (ret_fast_syscall+0x0/0x48)
>>
>> It's triggered by Tegra DRM driver on Xorg's startup. I also should notice 
>> that
>> currently Tegra DRM doesn't have a working HW cursor, I'm going to send out
>> Tegra cursor patches sometime soon.
> 
> Oops.. I messed up there.. for_each_new_plane_in_state overwrites the state 
> internally..
> ->8-
> for_each_oldnew_plane_in_state overwrites the iterator values internally, so 
> we cannot rely
> on it being set to the last valid plane. This was causing a NULL pointer 
> deref when someone
> tries to use the code. Save the plane and use the accessor functions to pull 
> out the relevant
> plane state.
> 
> Cc: Dmitry Osipenko 
> Fixes: 669c9215afea ("drm/atomic: Make async 

Re: [PATCH] drm/i915: Mark wait_for_engine() as maybe_unused

[Nick Desaulniers]

Signed-off-by: Nick Desaulniers 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 6/6] drm/atomic: Make async plane update checks work as intended, v2.

[Dmitry Osipenko]

On 04.09.2017 13:48, Maarten Lankhorst wrote:
> By always keeping track of the last commit in plane_state, we know
> whether there is an active update on the plane or not. With that
> information we can reject the fast update, and force the slowpath
> to be used as was originally intended.
> 
> We cannot use plane_state->crtc->state here, because this only mentions
> the most recent commit for the crtc, but not the planes that were part
> of it. We specifically care about what the last commit involving this
> plane is, which can only be tracked with a pointer in the plane state.
> 
> Changes since v1:
> - Clean up the whole function here, instead of partially earlier.
> - Add mention in the commit message why we need commit in plane_state.
> - Swap plane->state in intel_legacy_cursor_update, instead of
>   reassigning all variables. With this commit We know that the cursor
>   is not part of any active commits so this hack can be removed.
> 
> Cc: Gustavo Padovan 
> Signed-off-by: Maarten Lankhorst 
> Reviewed-by: Gustavo Padovan 
> Reviewed-by: Daniel Vetter  #v1
> ---
>  drivers/gpu/drm/drm_atomic_helper.c  | 53 
> ++--
>  drivers/gpu/drm/i915/intel_display.c | 27 +++---
>  include/drm/drm_plane.h  |  5 ++--
>  3 files changed, 35 insertions(+), 50 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
> b/drivers/gpu/drm/drm_atomic_helper.c
> index c81d46927a74..a2cd432d8b2d 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -1388,35 +1388,31 @@ int drm_atomic_helper_async_check(struct drm_device 
> *dev,
>  {
>   struct drm_crtc *crtc;
>   struct drm_crtc_state *crtc_state;
> - struct drm_crtc_commit *commit;
> - struct drm_plane *__plane, *plane = NULL;
> - struct drm_plane_state *__plane_state, *plane_state = NULL;
> + struct drm_plane *plane;
> + struct drm_plane_state *old_plane_state, *new_plane_state;
>   const struct drm_plane_helper_funcs *funcs;
> - int i, j, n_planes = 0;
> + int i, n_planes = 0;
>  
>   for_each_new_crtc_in_state(state, crtc, crtc_state, i) {
>   if (drm_atomic_crtc_needs_modeset(crtc_state))
>   return -EINVAL;
>   }
>  
> - for_each_new_plane_in_state(state, __plane, __plane_state, i) {
> + for_each_oldnew_plane_in_state(state, plane, old_plane_state, 
> new_plane_state, i)
>   n_planes++;
> - plane = __plane;
> - plane_state = __plane_state;
> - }
>  
>   /* FIXME: we support only single plane updates for now */
> - if (!plane || n_planes != 1)
> + if (n_planes != 1)
>   return -EINVAL;
>  
> - if (!plane_state->crtc)
> + if (!new_plane_state->crtc)
>   return -EINVAL;
>  

Hello,

It looks like a NULL-checking of new_plane_state is missed here.

[   70.138947] [] (drm_atomic_helper_async_check) from []
(drm_atomic_helper_check+0x4c/0x64)
[   70.138958] [] (drm_atomic_helper_check) from []
(drm_atomic_check_only+0x2f4/0x56c)
[   70.138969] [] (drm_atomic_check_only) from []
(drm_atomic_commit+0x10/0x50)
[   70.138979] [] (drm_atomic_commit) from []
(drm_atomic_helper_update_plane+0xf0/0x100)
[   70.138991] [] (drm_atomic_helper_update_plane) from []
(__setplane_internal+0x178/0x214)
[   70.139003] [] (__setplane_internal) from []
(drm_mode_cursor_universal+0x118/0x1a8)
[   70.139014] [] (drm_mode_cursor_universal) from []
(drm_mode_cursor_common+0x174/0x1ec)
[   70.139026] [] (drm_mode_cursor_common) from []
(drm_mode_cursor_ioctl+0x58/0x60)
[   70.139036] [] (drm_mode_cursor_ioctl) from []
(drm_ioctl+0x198/0x368)
[   70.139047] [] (drm_ioctl) from [] 
(do_vfs_ioctl+0x9c/0x8f0)
[   70.139058] [] (do_vfs_ioctl) from [] 
(SyS_ioctl+0x34/0x5c)
[   70.139071] [] (SyS_ioctl) from []
(ret_fast_syscall+0x0/0x48)

It's triggered by Tegra DRM driver on Xorg's startup. I also should notice that
currently Tegra DRM doesn't have a working HW cursor, I'm going to send out
Tegra cursor patches sometime soon.

This variant works for me:

if (!new_plane_state || !new_plane_state->crtc)
return -EINVAL;

>   funcs = plane->helper_private;
>   if (!funcs->atomic_async_update)
>   return -EINVAL;
>  
> - if (plane_state->fence)
> + if (new_plane_state->fence)
>   return -EINVAL;
>  
>   /*
> @@ -1424,31 +1420,11 @@ int drm_atomic_helper_async_check(struct drm_device 
> *dev,
>* the plane.  This prevents our async update's changes from getting
>* overridden by a previous synchronous update's state.
>*/
> - for_each_new_crtc_in_state(state, crtc, crtc_state, i) {
> - if (plane->crtc != crtc)
> - continue;
> -
> - spin_lock(>commit_lock);
> -

Re: [Outreachy kernel] [PATCH v2] drm/tegra: Replace dev_* with DRM_DEV_*

[Harsha Sharma]

Hi,
Thanks a lot for your feedback.
I will send another version for this patch.
Thanks for your time.

Regards,
Harsha Sharma

On Sun, Sep 24, 2017 at 10:30 PM, Julia Lawall  wrote:

>
>
> On Sun, 24 Sep 2017, Harsha Sharma wrote:
>
> > Replace all occurences of dev_info/err/dbg with DRM_DEV_INFO/
> > ERROR/DEBUG as we have DRM_DEV_* variants of drm print macros
> > Done using following coccinelle semantic patch
> >
> > @r@
> > @@
> >
> > (
> > -dev_info
> > +DRM_DEV_INFO
> > |
> > -dev_err
> > +DRM_DEV_ERROR
> > |
> > -dev_dbg
> > +DRM_DEV_DEBUG
> > )
> >
> > Signed-off-by: Harsha Sharma 
> > ---
> > Changes in v2:
> >  -Break line over 80 characters
> >  -Changes in comments not required
> >
> >  drivers/gpu/drm/tegra/dc.c |  53 +++-
> >  drivers/gpu/drm/tegra/dpaux.c  |  24 +++---
> >  drivers/gpu/drm/tegra/dsi.c|  68 ---
> >  drivers/gpu/drm/tegra/falcon.c |  16 ++--
> >  drivers/gpu/drm/tegra/fb.c |  22 +++--
> >  drivers/gpu/drm/tegra/gem.c|   8 +-
> >  drivers/gpu/drm/tegra/gr2d.c   |  10 ++-
> >  drivers/gpu/drm/tegra/gr3d.c   |  20 +++--
> >  drivers/gpu/drm/tegra/hdmi.c   |  66 +--
> >  drivers/gpu/drm/tegra/output.c |   8 +-
> >  drivers/gpu/drm/tegra/rgb.c|  12 +--
> >  drivers/gpu/drm/tegra/sor.c| 184 +-
> ---
> >  drivers/gpu/drm/tegra/vic.c|  15 ++--
> >  13 files changed, 304 insertions(+), 202 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/tegra/dc.c b/drivers/gpu/drm/tegra/dc.c
> > index 4df3911..fbc9cc1 100644
> > --- a/drivers/gpu/drm/tegra/dc.c
> > +++ b/drivers/gpu/drm/tegra/dc.c
> > @@ -1137,7 +1137,7 @@ static void tegra_dc_commit_state(struct tegra_dc
> *dc,
> >
> >   err = clk_set_parent(dc->clk, state->clk);
> >   if (err < 0)
> > - dev_err(dc->dev, "failed to set parent clock: %d\n", err);
> > + DRM_DEV_ERROR(dc->dev, "failed to set parent clock: %d\n",
> err);
> >
> >   /*
> >* Outputs may not want to change the parent clock rate. This is
> only
> > @@ -1150,7 +1150,7 @@ static void tegra_dc_commit_state(struct tegra_dc
> *dc,
> >   if (state->pclk > 0) {
> >   err = clk_set_rate(state->clk, state->pclk);
> >   if (err < 0)
> > - dev_err(dc->dev,
> > + DRM_DEV_ERROR(dc->dev,
> >   "failed to set clock rate to %lu Hz\n",
> >   state->pclk);
> >   }
> > @@ -1195,7 +1195,7 @@ static int tegra_dc_wait_idle(struct tegra_dc *dc,
> unsigned long timeout)
> >   usleep_range(1000, 2000);
> >   }
> >
> > - dev_dbg(dc->dev, "timeout waiting for DC to become idle\n");
> > + DRM_DEV_DEBUG(dc->dev, "timeout waiting for DC to become idle\n");
> >   return -ETIMEDOUT;
> >  }
> >
> > @@ -1763,7 +1763,8 @@ static int tegra_dc_init(struct host1x_client
> *client)
> >   if (tegra->domain) {
> >   err = iommu_attach_device(tegra->domain, dc->dev);
> >   if (err < 0) {
> > - dev_err(dc->dev, "failed to attach to domain:
> %d\n",
> > + DRM_DEV_ERROR(dc->dev,
> > + "failed to attach to domain: %d\n",
> >   err);
> >   return err;
> >   }
> > @@ -1801,7 +1802,8 @@ static int tegra_dc_init(struct host1x_client
> *client)
> >
> >   err = tegra_dc_rgb_init(drm, dc);
> >   if (err < 0 && err != -ENODEV) {
> > - dev_err(dc->dev, "failed to initialize RGB output: %d\n",
> err);
> > + DRM_DEV_ERROR(dc->dev,
> > + "failed to initialize RGB output: %d\n", err);
> >   goto cleanup;
> >   }
> >
> > @@ -1812,13 +1814,15 @@ static int tegra_dc_init(struct host1x_client
> *client)
> >   if (IS_ENABLED(CONFIG_DEBUG_FS)) {
> >   err = tegra_dc_debugfs_init(dc, drm->primary);
> >   if (err < 0)
> > - dev_err(dc->dev, "debugfs setup failed: %d\n",
> err);
> > + DRM_DEV_ERROR(dc->dev,
> > + "debugfs setup failed: %d\n", err);
>
> The string could be on the same line as the function name.  Just the err
> could be moved to the next line, and lined up with the right side of the (.
>
> Overall, looking through the rest, it would probably really be nicer to
> line the extra arguments up with the right side of the (.
>
>
> >   }
> >
> >   err = devm_request_irq(dc->dev, dc->irq, tegra_dc_irq, 0,
> >  dev_name(dc->dev), dc);
> >   if (err < 0) {
> > - dev_err(dc->dev, "failed to request IRQ#%u: %d\n", dc->irq,
> > + DRM_DEV_ERROR(dc->dev,
> > + "failed to request IRQ#%u: %d\n", dc->irq,
>
> Same here.  Try to keep the string on the first line.
>
> >   err);
> > 

Re: [PATCH v2] drm/tegra: Replace dev_* with DRM_DEV_*

[Allen]

Harsha,

>
> @r@
> @@
>
> (
> -dev_info
> +DRM_DEV_INFO
> |
> -dev_err
> +DRM_DEV_ERROR
> |
> -dev_dbg
> +DRM_DEV_DEBUG
> )
>
> Signed-off-by: Harsha Sharma 
> ---
> Changes in v2:
>  -Break line over 80 characters
>  -Changes in comments not required
>
>  drivers/gpu/drm/tegra/dc.c |  53 +++-
>  drivers/gpu/drm/tegra/dpaux.c  |  24 +++---
>  drivers/gpu/drm/tegra/dsi.c|  68 ---
>  drivers/gpu/drm/tegra/falcon.c |  16 ++--
>  drivers/gpu/drm/tegra/fb.c |  22 +++--
>  drivers/gpu/drm/tegra/gem.c|   8 +-
>  drivers/gpu/drm/tegra/gr2d.c   |  10 ++-
>  drivers/gpu/drm/tegra/gr3d.c   |  20 +++--
>  drivers/gpu/drm/tegra/hdmi.c   |  66 +--
>  drivers/gpu/drm/tegra/output.c |   8 +-
>  drivers/gpu/drm/tegra/rgb.c|  12 +--
>  drivers/gpu/drm/tegra/sor.c| 184 
> +
>  drivers/gpu/drm/tegra/vic.c|  15 ++--
>  13 files changed, 304 insertions(+), 202 deletions(-)
>
> diff --git a/drivers/gpu/drm/tegra/dc.c b/drivers/gpu/drm/tegra/dc.c
> index 4df3911..fbc9cc1 100644
> --- a/drivers/gpu/drm/tegra/dc.c
> +++ b/drivers/gpu/drm/tegra/dc.c
> @@ -1137,7 +1137,7 @@ static void tegra_dc_commit_state(struct tegra_dc *dc,
>

 One of the first things you'll probably need to do is to break this
huge patch into
smaller chunks. It becomes difficult to even review this patch(though
the change is
pretty straight forward.).

- Allen
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2] drm/tegra: Replace dev_* with DRM_DEV_*

[Harsha Sharma]

Replace all occurences of dev_info/err/dbg with DRM_DEV_INFO/
ERROR/DEBUG as we have DRM_DEV_* variants of drm print macros
Done using following coccinelle semantic patch

@r@
@@

(
-dev_info
+DRM_DEV_INFO
|
-dev_err
+DRM_DEV_ERROR
|
-dev_dbg
+DRM_DEV_DEBUG
)

Signed-off-by: Harsha Sharma 
---
Changes in v2:
 -Break line over 80 characters
 -Changes in comments not required

 drivers/gpu/drm/tegra/dc.c |  53 +++-
 drivers/gpu/drm/tegra/dpaux.c  |  24 +++---
 drivers/gpu/drm/tegra/dsi.c|  68 ---
 drivers/gpu/drm/tegra/falcon.c |  16 ++--
 drivers/gpu/drm/tegra/fb.c |  22 +++--
 drivers/gpu/drm/tegra/gem.c|   8 +-
 drivers/gpu/drm/tegra/gr2d.c   |  10 ++-
 drivers/gpu/drm/tegra/gr3d.c   |  20 +++--
 drivers/gpu/drm/tegra/hdmi.c   |  66 +--
 drivers/gpu/drm/tegra/output.c |   8 +-
 drivers/gpu/drm/tegra/rgb.c|  12 +--
 drivers/gpu/drm/tegra/sor.c| 184 +
 drivers/gpu/drm/tegra/vic.c|  15 ++--
 13 files changed, 304 insertions(+), 202 deletions(-)

diff --git a/drivers/gpu/drm/tegra/dc.c b/drivers/gpu/drm/tegra/dc.c
index 4df3911..fbc9cc1 100644
--- a/drivers/gpu/drm/tegra/dc.c
+++ b/drivers/gpu/drm/tegra/dc.c
@@ -1137,7 +1137,7 @@ static void tegra_dc_commit_state(struct tegra_dc *dc,
 
err = clk_set_parent(dc->clk, state->clk);
if (err < 0)
-   dev_err(dc->dev, "failed to set parent clock: %d\n", err);
+   DRM_DEV_ERROR(dc->dev, "failed to set parent clock: %d\n", err);
 
/*
 * Outputs may not want to change the parent clock rate. This is only
@@ -1150,7 +1150,7 @@ static void tegra_dc_commit_state(struct tegra_dc *dc,
if (state->pclk > 0) {
err = clk_set_rate(state->clk, state->pclk);
if (err < 0)
-   dev_err(dc->dev,
+   DRM_DEV_ERROR(dc->dev,
"failed to set clock rate to %lu Hz\n",
state->pclk);
}
@@ -1195,7 +1195,7 @@ static int tegra_dc_wait_idle(struct tegra_dc *dc, 
unsigned long timeout)
usleep_range(1000, 2000);
}
 
-   dev_dbg(dc->dev, "timeout waiting for DC to become idle\n");
+   DRM_DEV_DEBUG(dc->dev, "timeout waiting for DC to become idle\n");
return -ETIMEDOUT;
 }
 
@@ -1763,7 +1763,8 @@ static int tegra_dc_init(struct host1x_client *client)
if (tegra->domain) {
err = iommu_attach_device(tegra->domain, dc->dev);
if (err < 0) {
-   dev_err(dc->dev, "failed to attach to domain: %d\n",
+   DRM_DEV_ERROR(dc->dev,
+   "failed to attach to domain: %d\n",
err);
return err;
}
@@ -1801,7 +1802,8 @@ static int tegra_dc_init(struct host1x_client *client)
 
err = tegra_dc_rgb_init(drm, dc);
if (err < 0 && err != -ENODEV) {
-   dev_err(dc->dev, "failed to initialize RGB output: %d\n", err);
+   DRM_DEV_ERROR(dc->dev,
+   "failed to initialize RGB output: %d\n", err);
goto cleanup;
}
 
@@ -1812,13 +1814,15 @@ static int tegra_dc_init(struct host1x_client *client)
if (IS_ENABLED(CONFIG_DEBUG_FS)) {
err = tegra_dc_debugfs_init(dc, drm->primary);
if (err < 0)
-   dev_err(dc->dev, "debugfs setup failed: %d\n", err);
+   DRM_DEV_ERROR(dc->dev,
+   "debugfs setup failed: %d\n", err);
}
 
err = devm_request_irq(dc->dev, dc->irq, tegra_dc_irq, 0,
   dev_name(dc->dev), dc);
if (err < 0) {
-   dev_err(dc->dev, "failed to request IRQ#%u: %d\n", dc->irq,
+   DRM_DEV_ERROR(dc->dev,
+   "failed to request IRQ#%u: %d\n", dc->irq,
err);
goto cleanup;
}
@@ -1850,12 +1854,14 @@ static int tegra_dc_exit(struct host1x_client *client)
if (IS_ENABLED(CONFIG_DEBUG_FS)) {
err = tegra_dc_debugfs_exit(dc);
if (err < 0)
-   dev_err(dc->dev, "debugfs cleanup failed: %d\n", err);
+   DRM_DEV_ERROR(dc->dev,
+   "debugfs cleanup failed: %d\n", err);
}
 
err = tegra_dc_rgb_exit(dc);
if (err) {
-   dev_err(dc->dev, "failed to shutdown RGB output: %d\n", err);
+   DRM_DEV_ERROR(dc->dev,
+   "failed to shutdown RGB output: %d\n", err);
return err;
}
 
@@ -1954,7 +1960,7 @@ static int tegra_dc_parse_dt(struct tegra_dc *dc)
 
err = of_property_read_u32(dc->dev->of_node, "nvidia,head", );
if (err < 0) {
-   dev_err(dc->dev, "missing 

[PATCH 6/8] drm/rockchip: dw_hdmi: update dw-hdmi encoder enable

[Algea Cao]

Writing grf register according to device type.

Signed-off-by: Algea Cao 
---
 drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 19 ++-
 1 file changed, 18 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c 
b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
index ab44e13..e86ea47 100644
--- a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
+++ b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
@@ -349,9 +349,26 @@ static void dw_hdmi_rockchip_encoder_mode_set(struct 
drm_encoder *encoder,
 static void dw_hdmi_rockchip_encoder_enable(struct drm_encoder *encoder)
 {
struct rockchip_hdmi *hdmi = to_rockchip_hdmi(encoder);
-   u32 val;
+   struct drm_crtc *crtc = encoder->crtc;
+   u32 val, lcdsel_grf_reg, lcdsel_mask;
int ret;
 
+   if (WARN_ON(!crtc || !crtc->state))
+   return;
+
+   switch (hdmi->dev_type) {
+   case RK3288_HDMI:
+   lcdsel_grf_reg = RK3288_GRF_SOC_CON6;
+   lcdsel_mask = RK3288_HDMI_LCDC_SEL;
+   break;
+   case RK3399_HDMI:
+   lcdsel_grf_reg = RK3399_GRF_SOC_CON20;
+   lcdsel_mask = RK3399_HDMI_LCDC_SEL;
+   break;
+   default:
+   return;
+   }
+
ret = drm_of_encoder_active_endpoint_id(hdmi->dev->of_node, encoder);
if (ret)
val = hdmi->chip_data->lcdsel_lit;
-- 
2.7.4


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 1/8] drm/rockchip: dw_hdmi: update dw_hdmi_rockchip_dt_ids

[Algea Cao]

Add rk3328-dw-hdmi to support rk3328.

Signed-off-by: Algea Cao 
---
 drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c 
b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
index ccd5d59..b031005 100644
--- a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
+++ b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
@@ -313,6 +313,10 @@ static struct rockchip_hdmi_chip_data rk3399_chip_data = {
.lcdsel_lit = HIWORD_UPDATE(RK3399_HDMI_LCDC_SEL, RK3399_HDMI_LCDC_SEL),
 };
 
+static const struct dw_hdmi_plat_data rk3328_hdmi_drv_data = {
+   .mode_valid = dw_hdmi_rockchip_mode_valid,
+};
+
 static const struct dw_hdmi_plat_data rk3399_hdmi_drv_data = {
.mode_valid = dw_hdmi_rockchip_mode_valid,
.mpll_cfg   = rockchip_mpll_cfg,
@@ -328,6 +332,9 @@ static const struct of_device_id dw_hdmi_rockchip_dt_ids[] 
= {
{ .compatible = "rockchip,rk3399-dw-hdmi",
  .data = _hdmi_drv_data
},
+   { .compatible = "rockchip,rk3328-dw-hdmi",
+ .data = _hdmi_drv_data
+   },
{},
 };
 MODULE_DEVICE_TABLE(of, dw_hdmi_rockchip_dt_ids);
-- 
2.7.4


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 7/7] drm/rockchip: Cocci spatch "vma_pages"

[Daniel Vetter]

On Tue, Sep 26, 2017 at 02:33:07PM +0800, Mark yao wrote:
> On 2017年09月26日 13:12, Daniel Vetter wrote:
> > On Thu, Sep 21, 2017 at 09:02:22AM +0800, Mark yao wrote:
> > > On 2017年09月21日 06:29, Thomas Meyer wrote:
> > > > Use vma_pages function on vma object instead of explicit computation.
> > > > Found by coccinelle spatch "api/vma_pages.cocci"
> > > > 
> > > > Signed-off-by: Thomas Meyer 
> > > > ---
> > > Looks good for me:
> > > Acked-by: Mark Yao 
> > Once more a maintainer who acks a patch and doesn't push it. This is
> > really confusing, who exactly do you expect to handle this patch for you?
> > 
> > Please push to drm-misc-next (also for future patches), thanks.
> > -Daniel
> 
> Hi Daniel
> I Saw the patch title is "[PATCH 7/7]", I guessed it's one of a series of 
> patches and maybe it can pushed by series.
> 
> Ok, Pushed it to drm-misc-next.

Hm right, but I only see 7/7 here. Either way, except when the author asks
for a preferred tree it's best if you just pick things up right away. And
if you're unsure, just ask instead of risking that a patch drops through
the cracks.
-Daniel

> 
> > 
> > > > diff -u -p a/drivers/gpu/drm/rockchip/rockchip_drm_gem.c 
> > > > b/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
> > > > --- a/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
> > > > +++ b/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
> > > > @@ -220,7 +220,7 @@ static int rockchip_drm_gem_object_mmap_
> > > >{
> > > > struct rockchip_gem_object *rk_obj = to_rockchip_obj(obj);
> > > > unsigned int i, count = obj->size >> PAGE_SHIFT;
> > > > -   unsigned long user_count = (vma->vm_end - vma->vm_start) >> 
> > > > PAGE_SHIFT;
> > > > +   unsigned long user_count = vma_pages(vma);
> > > > unsigned long uaddr = vma->vm_start;
> > > > unsigned long offset = vma->vm_pgoff;
> > > > unsigned long end = user_count + offset;
> > > > 
> > > > ___
> > > > Linux-rockchip mailing list
> > > > linux-rockc...@lists.infradead.org
> > > > http://lists.infradead.org/mailman/listinfo/linux-rockchip
> > > > 
> > > > 
> > > > 
> > > -- 
> > > Ｍark Yao
> > > 
> > > 
> > > ___
> > > dri-devel mailing list
> > > dri-devel@lists.freedesktop.org
> > > https://lists.freedesktop.org/mailman/listinfo/dri-devel
> 
> 
> -- 
> Ｍark Ya
> 
> 
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/nouveau/fbcon: fix oops without fbdev emulation

[Daniel Vetter]

On Sat, Sep 23, 2017 at 01:10:33PM -0700, Pavel Roskin wrote:
> This is similar to an earlier commit 52dfcc5ccfbb ("drm/nouveau: fix for
> disabled fbdev emulation"), but protects all occurrences of helper.fbdev
> in the source.
> 
> I see oops in nouveau_fbcon_accel_save_disable() called from
> nouveau_fbcon_set_suspend_work() on Linux 3.13 when
> CONFIG_DRM_FBDEV_EMULATION option is disabled.

3.13 is _very_ old. Can you pls retest this with 4.14-rc kernels first? I
think we've fixed these all, but not sure.

Thanks, Daneil

> 
> Signed-off-by: Pavel Roskin 
> ---
>  drivers/gpu/drm/nouveau/nouveau_fbcon.c | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/nouveau/nouveau_fbcon.c
> b/drivers/gpu/drm/nouveau/nouveau_fbcon.c
> index f7707849bb53..698b8b10b646 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_fbcon.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_fbcon.c
> @@ -223,7 +223,7 @@ void
>  nouveau_fbcon_accel_save_disable(struct drm_device *dev)
>  {
>  struct nouveau_drm *drm = nouveau_drm(dev);
> -if (drm->fbcon) {
> +if (drm->fbcon && drm->fbcon->helper.fbdev) {
>  drm->fbcon->saved_flags = drm->fbcon->helper.fbdev->flags;
>  drm->fbcon->helper.fbdev->flags |= FBINFO_HWACCEL_DISABLED;
>  }
> @@ -233,9 +233,8 @@ void
>  nouveau_fbcon_accel_restore(struct drm_device *dev)
>  {
>  struct nouveau_drm *drm = nouveau_drm(dev);
> -if (drm->fbcon) {
> +if (drm->fbcon && drm->fbcon->helper.fbdev)
>  drm->fbcon->helper.fbdev->flags = drm->fbcon->saved_flags;
> -}
>  }
> 
>  static void
> @@ -245,7 +244,8 @@ nouveau_fbcon_accel_fini(struct drm_device *dev)
>  struct nouveau_fbdev *fbcon = drm->fbcon;
>  if (fbcon && drm->channel) {
>  console_lock();
> -fbcon->helper.fbdev->flags |= FBINFO_HWACCEL_DISABLED;
> +if (drm->fbcon->helper.fbdev)
> +fbcon->helper.fbdev->flags |= FBINFO_HWACCEL_DISABLED;
>  console_unlock();
>  nouveau_channel_idle(drm->channel);
>  nvif_object_fini(>twod);
> -- 
> 2.14.1
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] [PATCH 1/2] drm/dp: Add defines for latency in sink

[Daniel Vetter]

On Mon, Sep 25, 2017 at 11:23:26AM +0300, Jani Nikula wrote:
> On Sat, 23 Sep 2017, vathsala nagaraju  wrote:
> > Add defines for dpcd register 2009 (synchronization latency
> > in sink).
> >
> > Cc: Rodrigo Vivi 
> > CC: Puthikorn Voravootivat 
> > Reviewed-by: Rodrigo Vivi 
> > Signed-off-by: Vathsala Nagaraju 
> > ---
> >  include/drm/drm_dp_helper.h | 3 +++
> >  1 file changed, 3 insertions(+)
> >
> > diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
> > index 11c39f1..846004e6 100644
> > --- a/include/drm/drm_dp_helper.h
> > +++ b/include/drm/drm_dp_helper.h
> > @@ -735,6 +735,9 @@
> >  # define DP_PSR_SINK_INTERNAL_ERROR 7
> >  # define DP_PSR_SINK_STATE_MASK 0x07
> >  
> > +#define DP_SINK_SYNCHRONIZATION_LATENCY0x2009
> > +# define DP_MAX_RESYNC_FRAME_CNT_MASK  0xf
> 
> For the DP spec, please don't invent the names, use the ones from the
> spec. At most drop excess stuff from the end.
> 
> #define DP_SYNCHRONIZATION_LATENCY_IN_SINK
> # define DP_MAX_RESYNC_FRAME_COUNT_SHIFT
> # define DP_MAX_RESYNC_FRAME_COUNT_MASK
> 
> And while at it, please add the full register contents.

Please also annotate in which version of the spec we can find this, e.g.

#define DP_SYNCHRONIZATION_LATENCY_IN_SINK  /* eDP 1.4b */
# define DP_MAX_RESYNC_FRAME_COUNT_SHIFT
# define DP_MAX_RESYNC_FRAME_COUNT_MASK

Bringing this up since previous versions of this confused Rodrigo
-Daniel

> 
> BR,
> Jani.
> 
> > +
> >  #define DP_RECEIVER_ALPM_STATUS0x200b  /* eDP 1.4 */
> >  # define DP_ALPM_LOCK_TIMEOUT_ERROR(1 << 0)
> 
> -- 
> Jani Nikula, Intel Open Source Technology Center
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 7/8] arm64: dts: rockchip: add a grf clk for dw-mipi-dsi

[Nickey Yang]

The clk of grf must be enabled before writing grf
register for rk3399.

Signed-off-by: Nickey Yang 
---
 arch/arm64/boot/dts/rockchip/rk3399.dtsi | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi 
b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
index 6aa43fd..ab7629c 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
@@ -1630,8 +1630,8 @@
reg = <0x0 0xff96 0x0 0x8000>;
interrupts = ;
clocks = < SCLK_DPHY_PLL>, < PCLK_MIPI_DSI0>,
-< SCLK_DPHY_TX0_CFG>;
-   clock-names = "ref", "pclk", "phy_cfg";
+< SCLK_DPHY_TX0_CFG>, < PCLK_VIO_GRF>;
+   clock-names = "ref", "pclk", "phy_cfg", "grf";
power-domains = < RK3399_PD_VIO>;
rockchip,grf = <>;
status = "disabled";
-- 
1.9.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 6/8] arm64: dts: rockchip: rk3399: Correct MIPI DPHY PLL clock

[Nickey Yang]

Mipi-dphy's ref_clk connect to clk_dphy_pll inside rk3399.
clk_24m -> Gate11[14] -> clk_mipidphy_ref -> Gate21[0] -> clk_dphy_pll
So correct it.

Signed-off-by: Nickey Yang 
---
 arch/arm64/boot/dts/rockchip/rk3399.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi 
b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
index d79e9b3..6aa43fd 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
@@ -1629,7 +1629,7 @@
compatible = "rockchip,rk3399-mipi-dsi", "snps,dw-mipi-dsi";
reg = <0x0 0xff96 0x0 0x8000>;
interrupts = ;
-   clocks = < SCLK_MIPIDPHY_REF>, < PCLK_MIPI_DSI0>,
+   clocks = < SCLK_DPHY_PLL>, < PCLK_MIPI_DSI0>,
 < SCLK_DPHY_TX0_CFG>;
clock-names = "ref", "pclk", "phy_cfg";
power-domains = < RK3399_PD_VIO>;
-- 
1.9.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 4/8] drm/rockchip/dsi: correct phy parameter setting

[Nickey Yang]

As MIPI PHY document show, icpctrl<3..0> and lpfctrl<5..0>
should depend on frequency,so fix it.

Signed-off-by: Nickey Yang 
---
 drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 98 --
 1 file changed, 70 insertions(+), 28 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c 
b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
index 191037c..20d3f36 100644
--- a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
+++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
@@ -267,10 +267,21 @@
 #define VCO_IN_CAP_CON_HIGH(0x2 << 1)
 #define REF_BIAS_CUR_SEL   BIT(0)
 
-#define CP_CURRENT_3MA BIT(3)
+#define CP_CURRENT_1_5UA   0x1
+#define CP_CURRENT_4_5UA   0x2
+#define CP_CURRENT_7_5UA   0x6
+#define CP_CURRENT_6UA 0x9
+#define CP_CURRENT_12UA0xb
+#define CP_CURRENT_SEL(val)((val) & 0xf)
 #define CP_PROGRAM_EN  BIT(7)
+
+#define LPF_RESISTORS_15_5KOHM 0x1
+#define LPF_RESISTORS_13KOHM   0x2
+#define LPF_RESISTORS_11_5KOHM 0x4
+#define LPF_RESISTORS_10_5KOHM 0x8
+#define LPF_RESISTORS_8KOHM0x10
 #define LPF_PROGRAM_EN BIT(6)
-#define LPF_RESISTORS_20_KOHM  0
+#define LPF_RESISTORS_SEL(val) ((val) & 0x3f)
 
 #define HSFREQRANGE_SEL(val)   (((val) & 0x3f) << 1)
 
@@ -400,32 +411,63 @@ enum dw_mipi_dsi_mode {
DW_MIPI_DSI_VID_MODE,
 };
 
-struct dphy_pll_testdin_map {
+struct dphy_pll_parameter_map {
unsigned int max_mbps;
-   u8 testdin;
+   u8 hsfreqrange;
+   u8 icpctrl;
+   u8 lpfctrl;
 };
 
 /* The table is based on 27MHz DPHY pll reference clock. */
-static const struct dphy_pll_testdin_map dptdin_map[] = {
-   {  90, 0x00}, { 100, 0x10}, { 110, 0x20}, { 130, 0x01},
-   { 140, 0x11}, { 150, 0x21}, { 170, 0x02}, { 180, 0x12},
-   { 200, 0x22}, { 220, 0x03}, { 240, 0x13}, { 250, 0x23},
-   { 270, 0x04}, { 300, 0x14}, { 330, 0x05}, { 360, 0x15},
-   { 400, 0x25}, { 450, 0x06}, { 500, 0x16}, { 550, 0x07},
-   { 600, 0x17}, { 650, 0x08}, { 700, 0x18}, { 750, 0x09},
-   { 800, 0x19}, { 850, 0x29}, { 900, 0x39}, { 950, 0x0a},
-   {1000, 0x1a}, {1050, 0x2a}, {1100, 0x3a}, {1150, 0x0b},
-   {1200, 0x1b}, {1250, 0x2b}, {1300, 0x3b}, {1350, 0x0c},
-   {1400, 0x1c}, {1450, 0x2c}, {1500, 0x3c}
+static const struct dphy_pll_parameter_map dppa_map[] = {
+   {  90, 0x00, CP_CURRENT_1_5UA, LPF_RESISTORS_13KOHM},
+   { 100, 0x10, CP_CURRENT_1_5UA, LPF_RESISTORS_13KOHM},
+   { 110, 0x20, CP_CURRENT_1_5UA, LPF_RESISTORS_13KOHM},
+   { 130, 0x01, CP_CURRENT_1_5UA, LPF_RESISTORS_15_5KOHM},
+   { 140, 0x11, CP_CURRENT_1_5UA, LPF_RESISTORS_15_5KOHM},
+   { 150, 0x21, CP_CURRENT_1_5UA, LPF_RESISTORS_15_5KOHM},
+   { 170, 0x02, CP_CURRENT_6UA, LPF_RESISTORS_13KOHM},
+   { 180, 0x12, CP_CURRENT_6UA, LPF_RESISTORS_13KOHM},
+   { 200, 0x22, CP_CURRENT_6UA, LPF_RESISTORS_13KOHM},
+   { 220, 0x03, CP_CURRENT_4_5UA, LPF_RESISTORS_13KOHM},
+   { 240, 0x13, CP_CURRENT_4_5UA, LPF_RESISTORS_13KOHM},
+   { 250, 0x23, CP_CURRENT_4_5UA, LPF_RESISTORS_13KOHM},
+   { 270, 0x04, CP_CURRENT_6UA, LPF_RESISTORS_11_5KOHM},
+   { 300, 0x14, CP_CURRENT_6UA, LPF_RESISTORS_11_5KOHM},
+   { 330, 0x05, CP_CURRENT_1_5UA, LPF_RESISTORS_15_5KOHM},
+   { 360, 0x15, CP_CURRENT_1_5UA, LPF_RESISTORS_15_5KOHM},
+   { 400, 0x25, CP_CURRENT_1_5UA, LPF_RESISTORS_15_5KOHM},
+   { 450, 0x06, CP_CURRENT_7_5UA, LPF_RESISTORS_11_5KOHM},
+   { 500, 0x16, CP_CURRENT_7_5UA, LPF_RESISTORS_11_5KOHM},
+   { 550, 0x07, CP_CURRENT_7_5UA, LPF_RESISTORS_10_5KOHM},
+   { 600, 0x17, CP_CURRENT_7_5UA, LPF_RESISTORS_10_5KOHM},
+   { 650, 0x08, CP_CURRENT_7_5UA, LPF_RESISTORS_11_5KOHM},
+   { 700, 0x18, CP_CURRENT_7_5UA, LPF_RESISTORS_11_5KOHM},
+   { 750, 0x09, CP_CURRENT_7_5UA, LPF_RESISTORS_11_5KOHM},
+   { 800, 0x19, CP_CURRENT_7_5UA, LPF_RESISTORS_11_5KOHM},
+   { 850, 0x29, CP_CURRENT_7_5UA, LPF_RESISTORS_11_5KOHM},
+   { 900, 0x39, CP_CURRENT_7_5UA, LPF_RESISTORS_11_5KOHM},
+   { 950, 0x0a, CP_CURRENT_12UA, LPF_RESISTORS_8KOHM},
+   {1000, 0x1a, CP_CURRENT_12UA, LPF_RESISTORS_8KOHM},
+   {1050, 0x2a, CP_CURRENT_12UA, LPF_RESISTORS_8KOHM},
+   {1100, 0x3a, CP_CURRENT_12UA, LPF_RESISTORS_8KOHM},
+   {1150, 0x0b, CP_CURRENT_12UA, LPF_RESISTORS_10_5KOHM},
+   {1200, 0x1b, CP_CURRENT_12UA, LPF_RESISTORS_10_5KOHM},
+   {1250, 0x2b, CP_CURRENT_12UA, LPF_RESISTORS_10_5KOHM},
+   {1300, 0x3b, CP_CURRENT_12UA, LPF_RESISTORS_10_5KOHM},
+   {1350, 0x0c, CP_CURRENT_12UA, LPF_RESISTORS_10_5KOHM},
+   {1400, 0x1c, CP_CURRENT_12UA, LPF_RESISTORS_10_5KOHM},
+   {1450, 0x2c, CP_CURRENT_12UA, LPF_RESISTORS_10_5KOHM},
+   {1500, 0x3c, CP_CURRENT_12UA, LPF_RESISTORS_10_5KOHM}
 };
 
-static int max_mbps_to_testdin(unsigned int max_mbps)
+static int max_mbps_to_parameter(unsigned int max_mbps)
 {
int i;
 
-   for (i = 0; i < ARRAY_SIZE(dptdin_map); i++)
-   if 

[PATCH v2 8/8] arm64: dts: rockchip: add mipi_dsi1 support for rk3399

[Nickey Yang]

This patch adds the mipi_dsi1 related needed information.
e.g.: interrupts, grf, clocks, ports and so on.

Signed-off-by: Nickey Yang 
---
 arch/arm64/boot/dts/rockchip/rk3399.dtsi | 39 
 1 file changed, 39 insertions(+)

diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi 
b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
index ab7629c..82c03fa 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
@@ -1515,6 +1515,11 @@
reg = <2>;
remote-endpoint = <_in_vopl>;
};
+
+   vopl_out_mipi1: endpoint@3 {
+   reg = <3>;
+   remote-endpoint = <_in_vopl>;
+   };
};
};
 
@@ -1562,6 +1567,11 @@
reg = <2>;
remote-endpoint = <_in_vopb>;
};
+
+   vopb_out_mipi1: endpoint@3 {
+   reg = <3>;
+   remote-endpoint = <_in_vopb>;
+   };
};
};
 
@@ -1653,6 +1663,35 @@
};
};
 
+   mipi_dsi1: mipi@ff968000 {
+   compatible = "rockchip,rk3399-mipi-dsi", "snps,dw-mipi-dsi";
+   reg = <0x0 0xff968000 0x0 0x8000>;
+   interrupts = ;
+   clocks = < SCLK_DPHY_PLL>, < PCLK_MIPI_DSI1>,
+< SCLK_DPHY_TX1RX1_CFG>, < PCLK_VIO_GRF>;
+   clock-names = "ref", "pclk", "phy_cfg", "grf";
+   power-domains = < RK3399_PD_VIO>;
+   rockchip,grf = <>;
+   status = "disabled";
+
+   ports {
+   mipi1_in: port {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   mipi1_in_vopb: endpoint@0 {
+   reg = <0>;
+   remote-endpoint = <_out_mipi1>;
+   };
+
+   mipi1_in_vopl: endpoint@1 {
+   reg = <1>;
+   remote-endpoint = <_out_mipi1>;
+   };
+   };
+   };
+   };
+
edp: edp@ff97 {
compatible = "rockchip,rk3399-edp";
reg = <0x0 0xff97 0x0 0x8000>;
-- 
1.9.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 3/8] dt-bindings: add the rockchip, dual-channel for dw-mipi-dsi

[Nickey Yang]

Configure dsi slave channel when driving a panel
which needs 2 DSI links.

Signed-off-by: Nickey Yang 
---
 .../devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.txt   | 2 ++
 1 file changed, 2 insertions(+)

diff --git 
a/Documentation/devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.txt 
b/Documentation/devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.txt
index 6bb59ab..a2bea22 100644
--- 
a/Documentation/devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.txt
+++ 
b/Documentation/devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.txt
@@ -19,6 +19,8 @@ Optional properties:
 - power-domains: a phandle to mipi dsi power domain node.
 - resets: list of phandle + reset specifier pairs, as described in [3].
 - reset-names: string reset name, must be "apb".
+- rockchip,dual-channel: phandle to a 2nd DSI channel, useful as a slave
+channel when driving a panel which needs 2 DSI links.
 
 [1] Documentation/devicetree/bindings/clock/clock-bindings.txt
 [2] Documentation/devicetree/bindings/media/video-interfaces.txt
-- 
1.9.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 2/8] drm/rockchip/dsi: add dual mipi channel support

[Nickey Yang]

This patch add dual mipi channel support:
1.add definition of dsi1 register and grf operation.
2.dsi0 and dsi1 will work in master and slave mode
when driving dual mipi panel.

Signed-off-by: Nickey Yang 
---
 drivers/gpu/drm/rockchip/dw-mipi-dsi.c  | 390 
 drivers/gpu/drm/rockchip/rockchip_drm_drv.h |   1 +
 drivers/gpu/drm/rockchip/rockchip_drm_vop.c |   2 +
 drivers/gpu/drm/rockchip/rockchip_drm_vop.h |   3 +
 4 files changed, 292 insertions(+), 104 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c 
b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
index c933a3a..191037c 100644
--- a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
+++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
@@ -39,8 +39,58 @@
 #define RK3399_DSI1_SEL_VOP_LITBIT(4)
 
 /* disable turnrequest, turndisable, forcetxstopmode, forcerxmode */
-#define RK3399_GRF_SOC_CON22   0x6258
-#define RK3399_GRF_DSI_MODE0x
+#define RK3399_GRF_SOC_CON22   0x6258
+#define DPHY_TX0_TURNREQUEST_SET   ((0xf << 12) << 16)
+#define DPHY_TX0_TURNREQUEST_DISABLE   (0x0 << 12)
+#define DPHY_TX0_TURNREQUEST_ENABLE(0xf << 12)
+#define DPHY_TX0_TURNDISABLE_SET   ((0xf << 8) << 16)
+#define DPHY_TX0_TURNDISABLE_DISABLE   (0x0 << 8)
+#define DPHY_TX0_TURNDISABLE_ENABLE(0xf << 8)
+#define DPHY_TX0_FORCETXSTOPMODE_SET   ((0xf << 4) << 16)
+#define DPHY_TX0_FORCETXSTOPMODE_DISABLE   (0x0 << 4)
+#define DPHY_TX0_FORCETXSTOPMODE_ENABLE(0xf << 4)
+#define DPHY_TX0_FORCETRXMODE_SET  ((0xf << 0) << 16)
+#define DPHY_TX0_FORCETRXMODE_DISABLE  0x0
+#define DPHY_TX0_FORCETRXMODE_ENABLE   0xf
+#define RK3399_GRF_DSI_MODE((DPHY_TX0_TURNREQUEST_SET | \
+DPHY_TX0_TURNDISABLE_SET | \
+DPHY_TX0_FORCETXSTOPMODE_SET | 
\
+DPHY_TX0_FORCETRXMODE_SET) | \
+(DPHY_TX0_TURNREQUEST_DISABLE 
| \
+DPHY_TX0_TURNDISABLE_DISABLE | 
\
+
DPHY_TX0_FORCETXSTOPMODE_DISABLE | \
+DPHY_TX0_FORCETRXMODE_DISABLE))
+
+
+/* disable turndisable, forcetxstopmode, forcerxmode, enable */
+#define RK3399_GRF_SOC_CON23   0x625c
+#define DPHY_TX1RX1_TURNDISABLE_SET((0xf << 12) << 16)
+#define DPHY_TX1RX1_TURNDISABLE_DISABLE(0x0 << 12)
+#define DPHY_TX1RX1_TURNDISABLE_ENABLE (0xf << 12)
+#define DPHY_TX1RX1_FORCETXSTOPMODE_SET((0xf << 8) << 16)
+#define DPHY_TX1RX1_FORCETXSTOPMODE_DISABLE(0x0 << 8)
+#define DPHY_TX1RX1_FORCETXSTOPMODE_ENABLE (0xf << 8)
+#define DPHY_TX1RX1_FORCERXMODE_SET((0xf << 4) << 16)
+#define DPHY_TX1RX1_FORCERXMODE_DISABLE(0x0 << 4)
+#define DPHY_TX1RX1_FORCERXMODE_ENABLE (0xf << 4)
+#define DPHY_TX1RX1_ENABLE_SET ((0xf << 0) << 16)
+#define DPHY_TX1RX1_ENABLE_DISABLE 0x0
+#define DPHY_TX1RX1_ENABLE_ENABLE  0xf
+#define RK3399_GRF_DSI1_MODE   ((DPHY_TX1RX1_TURNDISABLE_SET | 
\
+
DPHY_TX1RX1_FORCETXSTOPMODE_SET | \
+DPHY_TX1RX1_FORCERXMODE_SET | \
+DPHY_TX1RX1_ENABLE_SET) | \
+(DPHY_TX0_TURNREQUEST_DISABLE 
| \
+DPHY_TX0_TURNDISABLE_DISABLE | 
\
+
DPHY_TX0_FORCETXSTOPMODE_DISABLE | \
+DPHY_TX0_FORCETRXMODE_DISABLE))
+#define RK3399_GRF_DSI1_ENABLE ((DPHY_TX1RX1_ENABLE_SET | \
+ DPHY_TX1RX1_ENABLE_ENABLE))
+
+#define RK3399_GRF_SOC_CON24   0x6260
+#define RK3399_TXRX_MASTERSLAVEZ   BIT(7)
+#define RK3399_TXRX_ENABLECLK  BIT(6)
+#define RK3399_TXRX_BASEDIRBIT(5)
 
 #define DSI_VERSION0x00
 #define DSI_PWR_UP 0x04
@@ -304,6 +354,13 @@ struct dw_mipi_dsi_plat_data {
u32 grf_switch_reg;
u32 grf_dsi0_mode;
u32 grf_dsi0_mode_reg;
+   u32 grf_dsi1_mode;
+   u32 grf_dsi1_enable;
+   u32 grf_dsi1_mode_reg1;
+   u32 dsi1_basedir;
+   u32 dsi1_masterslavez;
+   u32 dsi1_enableclk;
+   u32 grf_dsi1_mode_reg2;
unsigned int flags;
unsigned int max_data_lanes;
 };
@@ -322,6 +379,10 @@ struct dw_mipi_dsi {
struct clk *pclk;
struct clk *phy_cfg_clk;
 
+   /* dual-channel */
+   struct dw_mipi_dsi *master;
+   

[PATCH v2 5/8] drm/rockchip/dsi: Use DRM_DEV_ERROR instead of dev_err

[Nickey Yang]

Rockchip driver has been moved to using the
DRM_DEV_ERROR log messages, so change all
instances of dev_err.

Signed-off-by: Nickey Yang 
---
 drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 62 +-
 1 file changed, 31 insertions(+), 31 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c 
b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
index 20d3f36..2ff5da6 100644
--- a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
+++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
@@ -555,7 +555,7 @@ static int dw_mipi_dsi_phy_init(struct dw_mipi_dsi *dsi)
 
i = max_mbps_to_parameter(dsi->lane_mbps);
if (i < 0) {
-   dev_err(dsi->dev,
+   DRM_DEV_ERROR(dsi->dev,
"failed to get parameter for %dmbps lane clock\n",
dsi->lane_mbps);
return i;
@@ -568,7 +568,7 @@ static int dw_mipi_dsi_phy_init(struct dw_mipi_dsi *dsi)
 
ret = clk_prepare_enable(dsi->phy_cfg_clk);
if (ret) {
-   dev_err(dsi->dev, "Failed to enable phy_cfg_clk\n");
+   DRM_DEV_ERROR(dsi->dev, "Failed to enable phy_cfg_clk\n");
return ret;
}
 
@@ -652,7 +652,7 @@ static int dw_mipi_dsi_phy_init(struct dw_mipi_dsi *dsi)
ret = readl_poll_timeout(dsi->base + DSI_PHY_STATUS,
 val, val & LOCK, 1000, PHY_STATUS_TIMEOUT_US);
if (ret < 0) {
-   dev_err(dsi->dev, "failed to wait for phy lock state\n");
+   DRM_DEV_ERROR(dsi->dev, "failed to wait for phy lock state\n");
goto phy_init_end;
}
 
@@ -660,7 +660,7 @@ static int dw_mipi_dsi_phy_init(struct dw_mipi_dsi *dsi)
 val, val & STOP_STATE_CLK_LANE, 1000,
 PHY_STATUS_TIMEOUT_US);
if (ret < 0)
-   dev_err(dsi->dev,
+   DRM_DEV_ERROR(dsi->dev,
"failed to wait for phy clk lane stop state\n");
 
 phy_init_end:
@@ -686,7 +686,7 @@ static int dw_mipi_dsi_get_lane_bps(struct dw_mipi_dsi *dsi,
 
bpp = mipi_dsi_pixel_format_to_bpp(dsi->format);
if (bpp < 0) {
-   dev_err(dsi->dev, "failed to get bpp for pixel format %d\n",
+   DRM_DEV_ERROR(dsi->dev, "failed to get bpp for pixel format 
%d\n",
dsi->format);
return bpp;
}
@@ -701,7 +701,7 @@ static int dw_mipi_dsi_get_lane_bps(struct dw_mipi_dsi *dsi,
if (tmp < max_mbps)
target_mbps = tmp;
else
-   dev_err(dsi->dev, "DPHY clock frequency is out of 
range\n");
+   DRM_DEV_ERROR(dsi->dev, "DPHY clock frequency is out of 
range\n");
}
 
fin = clk_get_rate(dsi->pllref_clk);
@@ -751,7 +751,7 @@ static int dw_mipi_dsi_get_lane_bps(struct dw_mipi_dsi *dsi,
dsi->input_div = best_prediv;
dsi->feedback_div = best_fbdiv;
} else
-   dev_err(dsi->dev, "Can not find best_freq for DPHY\n");
+   DRM_DEV_ERROR(dsi->dev, "Can not find best_freq for DPHY\n");
 
return 0;
 }
@@ -763,7 +763,7 @@ static int dw_mipi_dsi_host_attach(struct mipi_dsi_host 
*host,
int lanes = dsi->slave ? device->lanes / 2 : device->lanes;
 
if (lanes > dsi->pdata->max_data_lanes) {
-   dev_err(dsi->dev, "the number of data lanes(%u) is too many\n",
+   DRM_DEV_ERROR(dsi->dev, "the number of data lanes(%u) is too 
many\n",
lanes);
return -EINVAL;
}
@@ -821,7 +821,7 @@ static int dw_mipi_dsi_gen_pkt_hdr_write(struct dw_mipi_dsi 
*dsi, u32 hdr_val)
 val, !(val & GEN_CMD_FULL), 1000,
 CMD_PKT_STATUS_TIMEOUT_US);
if (ret < 0) {
-   dev_err(dsi->dev, "failed to get available command FIFO\n");
+   DRM_DEV_ERROR(dsi->dev, "failed to get available command 
FIFO\n");
return ret;
}
 
@@ -832,7 +832,7 @@ static int dw_mipi_dsi_gen_pkt_hdr_write(struct dw_mipi_dsi 
*dsi, u32 hdr_val)
 val, (val & mask) == mask,
 1000, CMD_PKT_STATUS_TIMEOUT_US);
if (ret < 0) {
-   dev_err(dsi->dev, "failed to write command FIFO\n");
+   DRM_DEV_ERROR(dsi->dev, "failed to write command FIFO\n");
return ret;
}
 
@@ -852,7 +852,7 @@ static int dw_mipi_dsi_dcs_short_write(struct dw_mipi_dsi 
*dsi,
data |= tx_buf[1] << 8;
 
if (msg->tx_len > 2) {
-   dev_err(dsi->dev, "too long tx buf length %zu for short 
write\n",
+   DRM_DEV_ERROR(dsi->dev, "too long tx buf length %zu for short 
write\n",
msg->tx_len);
return -EINVAL;
}
@@ -871,7 +871,7 @@ static int 

[PATCH v2 1/8] drm/rockchip/dsi: correct Feedback divider setting

[Nickey Yang]

This patch correct Feedback divider setting:
1、Set Feedback divider [8:5] when HIGH_PROGRAM_EN
2、Due to the use of a "by 2 pre-scaler," the range of the
feedback multiplication Feedback divider is limited to even
division numbers, and Feedback divider must be greater than
12, less than 1000.
3、Make the previously configured Feedback divider(LSB)
factors effective
4、Add the definition of the MIPI PHY register.

Signed-off-by: Nickey Yang 
---
 drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 219 ++---
 1 file changed, 146 insertions(+), 73 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c 
b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
index 9a20b9d..c933a3a 100644
--- a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
+++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
@@ -228,7 +228,7 @@
 #define LOW_PROGRAM_EN 0
 #define HIGH_PROGRAM_ENBIT(7)
 #define LOOP_DIV_LOW_SEL(val)  (((val) - 1) & 0x1f)
-#define LOOP_DIV_HIGH_SEL(val) val) - 1) >> 5) & 0x1f)
+#define LOOP_DIV_HIGH_SEL(val) val) - 1) >> 5) & 0xf)
 #define PLL_LOOP_DIV_ENBIT(5)
 #define PLL_INPUT_DIV_EN   BIT(4)
 
@@ -254,6 +254,28 @@
 #define DW_MIPI_NEEDS_PHY_CFG_CLK  BIT(0)
 #define DW_MIPI_NEEDS_GRF_CLK  BIT(1)
 
+#define PLL_BIAS_CUR_SEL_CAP_VCO_CONTROL 0x10
+#define PLL_CP_CONTROL_PLL_LOCK_BYPASS 0x11
+#define PLL_LPF_AND_CP_CONTROL 0x12
+#define PLL_INPUT_DIVIDER_RATIO 0x17
+#define PLL_LOOP_DIVIDER_RATIO 0x18
+#define PLL_INPUT_AND_LOOP_DIVIDER_RATIOS_CONTROL 0x19
+#define BANDGAP_AND_BIAS_CONTROL 0x20
+#define TERMINATION_RESISTER_CONTROL 0x21
+#define AFE_BIAS_BANDGAP_ANALOG_PROGRAMMABILITY 0x22
+#define HS_RX_CONTROL_OF_LANE_0 0x44
+#define HS_TX_CLOCK_LANE_REQUEST_STATE_TIME_CONTROL 0x60
+#define HS_TX_CLOCK_LANE_PREPARE_STATE_TIME_CONTROL 0x61
+#define HS_TX_CLOCK_LANE_HS_ZERO_STATE_TIME_CONTROL 0x62
+#define HS_TX_CLOCK_LANE_TRAIL_STATE_TIME_CONTROL 0x63
+#define HS_TX_CLOCK_LANE_EXIT_STATE_TIME_CONTROL 0x64
+#define HS_TX_CLOCK_LANE_POST_TIME_CONTROL 0x65
+#define HS_TX_DATA_LANE_REQUEST_STATE_TIME_CONTROL 0x70
+#define HS_TX_DATA_LANE_PREPARE_STATE_TIME_CONTROL 0x71
+#define HS_TX_DATA_LANE_HS_ZERO_STATE_TIME_CONTROL 0x72
+#define HS_TX_DATA_LANE_TRAIL_STATE_TIME_CONTROL 0x73
+#define HS_TX_DATA_LANE_EXIT_STATE_TIME_CONTROL 0x74
+
 enum {
BANDGAP_97_07,
BANDGAP_98_05,
@@ -447,53 +469,79 @@ static int dw_mipi_dsi_phy_init(struct dw_mipi_dsi *dsi)
return ret;
}
 
-   dw_mipi_dsi_phy_write(dsi, 0x10, BYPASS_VCO_RANGE |
-VCO_RANGE_CON_SEL(vco) |
-VCO_IN_CAP_CON_LOW |
-REF_BIAS_CUR_SEL);
-
-   dw_mipi_dsi_phy_write(dsi, 0x11, CP_CURRENT_3MA);
-   dw_mipi_dsi_phy_write(dsi, 0x12, CP_PROGRAM_EN | LPF_PROGRAM_EN |
-LPF_RESISTORS_20_KOHM);
-
-   dw_mipi_dsi_phy_write(dsi, 0x44, HSFREQRANGE_SEL(testdin));
-
-   dw_mipi_dsi_phy_write(dsi, 0x17, INPUT_DIVIDER(dsi->input_div));
-   dw_mipi_dsi_phy_write(dsi, 0x18, LOOP_DIV_LOW_SEL(dsi->feedback_div) |
-LOW_PROGRAM_EN);
-   dw_mipi_dsi_phy_write(dsi, 0x18, LOOP_DIV_HIGH_SEL(dsi->feedback_div) |
-HIGH_PROGRAM_EN);
-   dw_mipi_dsi_phy_write(dsi, 0x19, PLL_LOOP_DIV_EN | PLL_INPUT_DIV_EN);
-
-   dw_mipi_dsi_phy_write(dsi, 0x22, LOW_PROGRAM_EN |
-BIASEXTR_SEL(BIASEXTR_127_7));
-   dw_mipi_dsi_phy_write(dsi, 0x22, HIGH_PROGRAM_EN |
-BANDGAP_SEL(BANDGAP_96_10));
-
-   dw_mipi_dsi_phy_write(dsi, 0x20, POWER_CONTROL | INTERNAL_REG_CURRENT |
-BIAS_BLOCK_ON | BANDGAP_ON);
-
-   dw_mipi_dsi_phy_write(dsi, 0x21, TER_RESISTOR_LOW | TER_CAL_DONE |
-SETRD_MAX | TER_RESISTORS_ON);
-   dw_mipi_dsi_phy_write(dsi, 0x21, TER_RESISTOR_HIGH | LEVEL_SHIFTERS_ON |
-SETRD_MAX | POWER_MANAGE |
-TER_RESISTORS_ON);
-
-   dw_mipi_dsi_phy_write(dsi, 0x60, TLP_PROGRAM_EN | ns2bc(dsi, 500));
-   dw_mipi_dsi_phy_write(dsi, 0x61, THS_PRE_PROGRAM_EN | ns2ui(dsi, 40));
-   dw_mipi_dsi_phy_write(dsi, 0x62, THS_ZERO_PROGRAM_EN | ns2bc(dsi, 300));
-   dw_mipi_dsi_phy_write(dsi, 0x63, THS_PRE_PROGRAM_EN | ns2ui(dsi, 100));
-   dw_mipi_dsi_phy_write(dsi, 0x64, BIT(5) | ns2bc(dsi, 100));
-   dw_mipi_dsi_phy_write(dsi, 0x65, BIT(5) | (ns2bc(dsi, 60) + 7));
-
-   dw_mipi_dsi_phy_write(dsi, 0x70, TLP_PROGRAM_EN | ns2bc(dsi, 500));
-   dw_mipi_dsi_phy_write(dsi, 0x71,
+   dw_mipi_dsi_phy_write(dsi, PLL_BIAS_CUR_SEL_CAP_VCO_CONTROL,
+ BYPASS_VCO_RANGE |
+ VCO_RANGE_CON_SEL(vco) |
+

Re: [PATCH 02/22] drm/i915: introduce simple gemfs

[Greg Kroah-Hartman]

On Mon, Sep 25, 2017 at 07:47:17PM +0100, Matthew Auld wrote:
> Not a fully blown gemfs, just our very own tmpfs kernel mount. Doing so
> moves us away from the shmemfs shm_mnt, and gives us the much needed
> flexibility to do things like set our own mount options, namely huge=
> which should allow us to enable the use of transparent-huge-pages for
> our shmem backed objects.
> 
> v2: various improvements suggested by Joonas
> 
> v3: move gemfs instance to i915.mm and simplify now that we have
> file_setup_with_mnt
> 
> v4: fallback to tmpfs shm_mnt upon failure to setup gemfs
> 
> v5: make tmpfs fallback kinder

Why do this only for one specific driver?  Shouldn't the drm core handle
this for you, for all other drivers as well?  Otherwise trying to figure
out how to "contain" this type of thing is going to be a pain (mount
options, selinux options, etc.)

thanks,

greg k-h
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel