[PATCH] drm/gma500: remove the process of stolen page in page fault handler.
Patrik Jakobsson wrote 2016/09/02 21:54:41: > Patrik Jakobsson > 2016/09/02 21:54 > > Re: [PATCH] drm/gma500: remove the process of stolen page in page > fault handler. > > On Fri, Sep 2, 2016 at 11:31 AM, wrote: > > > > JiangBiao162664/user/zte_ltd Wrote 2016/08/31 10:27:34: > > > >> JiangBiao162664/user/zte_ltd > >> 2016/08/31 10:27 > >> > >> From > >> Patrik Jakobsson , > >> Re: [PATCH] drm/gma500: remove the process of stolen page in page > >> fault handler. > >> > >> Patrik Jakobsson wrote on 2016/08/30 > >> 18:21:08: > >> > >> > Patrik Jakobsson > >> > 2016/08/30 18:21 > >> > > >> > From > >> > jiang.biao2 at zte.com.cn, > >> > cc > >> > dri-devel > >> > Re: [PATCH] drm/gma500: remove the process of stolen page in page > >> fault handler. > >> > > >> > On Tue, Aug 30, 2016 at 7:10 AM, wrote: > >> > > > >> > > Direct gtt range is used in the page fault scene in current driver, > >> > > instead of stolen page. So no need to keep relative process. > >> > > >> > Hi > >> > > >> > Are you saying that we don't use stolen memory? Afaik stolen memory > >> > should be accessed through the stolen range so we do need this. > >> > > >> > -Patrik > >> > > >> As far as I can see, the stolen memory is only used by fbdev driver > >> in gma500, > >> but the fbdev driver maps the stloen memory directly in psbfb_vm_fault, > >> not > >> using psb_gem_fault to map the stolen memory. > >> The only scenario using the psb_gem_fault is the gtt range created by > >> psb_gem_create, which alloc the gtt range without stolen memory backed. > > > >> If I missed something, pls enlighten me. > >> Thanks a lot. > > > > Hi Patrik, > > > > Could you please help to confirm my question? > > Thank you very much. > > Hi, > > The assumption that stolen memory will never be used with > psb_gem_create() might not hold true in the future and silently > breaking support for it ito save a few lines of code is not the right > way to do it. Actually, if we find use for stolen memory we would > basically get memory for free since it is already reserved for > graphics usage. > > Cheers > Patrik Understood, but maybe It's better to add it when it's actually used. Indeed, that does not that matter. Thanks for the reply. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160905/a4796298/attachment.html>
[PATCH] drm/fsl-dcu: Add gamma set for crtc
Hi Stefan,
> > + */
> > +static u32 swap_bytes(u16 var)
>
> We certainly don't want a byte swapping function in the driver. I am sure
> Linux
> has appropriate functions for that already, however, I am not convinced that
> we need that at all.
>
Yeah, sure. Actually I had sent the V2 for this feature, which just using
"<<24" to do this
https://patchwork.kernel.org/patch/9252389/
...
> > + };
> > +
> > + struct drm_device *dev = crtc->dev;
> > + struct fsl_dcu_drm_device *fsl_dev = dev->dev_private;
> > + unsigned int i;
> > + struct rgb glut;
> > +
> > + for (i = 0; i < size; i++) {
> > + glut.r[i] = swap_bytes(r[i]);
> > + glut.g[i] = swap_bytes(g[i]);
> > + glut.b[i] = swap_bytes(b[i]);
> > + regmap_write(fsl_dev->regmap, FSL_GAMMA_R + 4 * i,
> glut.r[i]);
> > + regmap_write(fsl_dev->regmap, FSL_GAMMA_G + 4 * i,
> glut.g[i]);
> > + regmap_write(fsl_dev->regmap, FSL_GAMMA_B + 4 * i,
> glut.b[i]);
>
> I guess the problem is that regmap_write does byte swapping because
> ls1021a.dtsi defines the whole DCU register space to be big-endian. So you end
> up doing byte swapping twice.
>
> If the gamma area is really little-endian, then DCU on LS1021a seems to be
> quite a mess... :-(
>
> In this case, we probably should create a second regmap for the different
> areas
> specifically, e.g. change the device tree:
>
> reg = <0x0 0x2ce 0x0 0x2000
> 0x0 0x2ce2000 0x0 0x2000
> 0x0 0x2ce4000 0x0 0xc00
> 0x0 0x2ce4c00 0x0 0x400>;
>
> reg-names = "regs", "palette", "gamma", "cursor";
> i
> /* Use Gamma is always little endian */
> static const struct regmap_config fsl_dcu_regmap_gamma_config = { ...
> .val_format_endian = REGMAP_ENDIAN_LITTLE, ...
> };
>
> res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "gamma");
> base_gamma = devm_ioremap_resource(dev, res);
>
> fsl_dev->regmap_gamma = devm_regmap_init_mmio(...)
>
>
> regmap_write(fsl_dev->regmap_gamma, ...)
>
This is a errta for DCU, Gamma registers are supposed to be big endian, but
actually it is little endian, do we
Really need to create a second regmap?
>
> @Mark, what do you think? Do we have a (better) solution for such cases?
>
> > + }
> > +
> > + return 0;
> > +}
> > +
> > static const struct drm_crtc_funcs fsl_dcu_drm_crtc_funcs = {
> > .atomic_duplicate_state = drm_atomic_helper_crtc_duplicate_state,
> > .atomic_destroy_state = drm_atomic_helper_crtc_destroy_state,
> > @@ -135,6 +197,7 @@ static const struct drm_crtc_funcs
> > fsl_dcu_drm_crtc_funcs = {
> > .page_flip = drm_atomic_helper_page_flip,
> > .reset = drm_atomic_helper_crtc_reset,
> > .set_config = drm_atomic_helper_set_config,
> > + .gamma_set = fsl_crtc_gamma_set,
> > };
> >
> > int fsl_dcu_drm_crtc_create(struct fsl_dcu_drm_device *fsl_dev) diff
> > --git a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.h
> > b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.h
> > index 3b371fe7..d3bc540 100644
> > --- a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.h
> > +++ b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.h
> > @@ -25,6 +25,9 @@
> > #define DCU_MODE_NORMAL1
> > #define DCU_MODE_TEST 2
> > #define DCU_MODE_COLORBAR 3
> > +#define DCU_MODE_EN_GAMMA_MASK 0x04
>
> Nit: In cases where MASK is a single bit, you can use BIT(..)...
>
> > +#define DCU_MODE_GAMMA_ENABLE BIT(2)
> > +#define DCU_MODE_GAMMA_DISABLE 0
>
> That sounds like a useless define to me. In the disable case, just use 0 in
> regmap_update_bits. The .._MASK shows which bit you clear.
>
Yeah, sure. Thanks.
Best Regards,
Meng
[PATCH 4/5] PM / devfreq: rockchip: add devfreq driver for rk3399 dmc
Dear all,
This patch rely on both rockchip.git and devfreq.git.
Already, Rockchip SoC Maintainer (Heiko Stuebner) created
the immutable branch[1]. When applying these patches
on devfreq.git with pulling the immutable branch[1],
It looks like that should not be a problem.
[1] http://www.spinics.net/lists/arm-kernel/msg528298.html
Best Regards,
Chanwoo Choi
On 2016ë
09ì 02ì¼ 10:23, kbuild test robot wrote:
> Hi Lin,
>
> [auto build test ERROR on next-20160825]
> [also build test ERROR on v4.8-rc4]
> [cannot apply to rockchip/for-next devfreq/for-rafael linus/master v4.8-rc4
> v4.8-rc3 v4.8-rc2]
> [if your patch is applied to the wrong git tree, please drop us a note to
> help improve the system]
> [Suggest to use git(>=2.9.0) format-patch --base= (or --base=auto for
> convenience) to record what (public, well-known) commit your patch series was
> built on]
> [Check https://git-scm.com/docs/git-format-patch for more information]
>
> url:
> https://github.com/0day-ci/linux/commits/Lin-Huang/rk3399-support-ddr-frequency-scaling/20160902-063701
> config: arm-allmodconfig (attached as .config)
> compiler: arm-linux-gnueabi-gcc (Debian 5.4.0-6) 5.4.0 20160609
> reproduce:
> wget
> https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
> -O ~/bin/make.cross
> chmod +x ~/bin/make.cross
> # save the attached .config to linux build tree
> make.cross ARCH=arm
>
> All errors (new ones prefixed by >>):
>
>>> drivers/devfreq/rk3399_dmc.c:29:39: fatal error:
>>> soc/rockchip/rockchip_sip.h: No such file or directory
>compilation terminated.
>
> vim +29 drivers/devfreq/rk3399_dmc.c
>
> 23#include
> 24#include
> 25#include
> 26#include
> 27#include
> 28
> > 29#include
> 30
> 31struct dram_timing {
> 32unsigned int ddr3_speed_bin;
>
> ---
> 0-DAY kernel test infrastructureOpen Source Technology Center
> https://lists.01.org/pipermail/kbuild-all Intel Corporation
>
[PATCH v10 3/5] Documentation: bindings: add dt documentation for rk3399 dmc
This patch adds the documentation for rockchip rk3399 dmc driver. Signed-off-by: Lin Huang Reviewed-by: Chanwoo Choi --- Changes in v10: - add rockchip prefix in property describe Changes in v9: - add ddr timing property to node Changes in v8: - add ddr timing properties Changes in v7: - None Changes in v6: -Add more detail in Documentation Changes in v5: -None Changes in v4: -None Changes in v3: -None Changes in v2: -None Changes in v1: -None .../devicetree/bindings/devfreq/rk3399_dmc.txt | 202 + 1 file changed, 202 insertions(+) create mode 100644 Documentation/devicetree/bindings/devfreq/rk3399_dmc.txt diff --git a/Documentation/devicetree/bindings/devfreq/rk3399_dmc.txt b/Documentation/devicetree/bindings/devfreq/rk3399_dmc.txt new file mode 100644 index 000..84660a3 --- /dev/null +++ b/Documentation/devicetree/bindings/devfreq/rk3399_dmc.txt @@ -0,0 +1,210 @@ +* Rockchip rk3399 DMC(Dynamic Memory Controller) device + +Required properties: +- compatible: Must be "rockchip,rk3399-dmc". +- devfreq-events: Node to get DDR loading, Refer to +Documentation/devicetree/bindings/devfreq/ +rockchip-dfi.txt +- interrupts: The interrupt number to the CPU. The interrupt +specifier format depends on the interrupt controller. +It should be DCF interrupts, when DDR dvfs finish, +it will happen. +- clocks: Phandles for clock specified in "clock-names" property +- clock-names : The name of clock used by the DFI, must be +"pclk_ddr_mon"; +- operating-points-v2: Refer to Documentation/devicetree/bindings/power/opp.txt +for details. +- center-supply:DMC supply node. +- status: Marks the node enabled/disabled. + +Following properties are ddr timing: + +- rockchip,dram_speed_bin : Value reference include/dt-bindings/clock/ddr.h, + it select ddr3 cl-trp-trcd type, default value + "DDR3_DEFAULT".it must selected according to + "Speed Bin" in ddr3 datasheet, DO NOT use + smaller "Speed Bin" than ddr3 exactly is. + +- rockchip,pd_idle : Config the PD_IDLE value, defined the power-down + idle period, memories are places into power-down + mode if bus is idle for PD_IDLE DFI clocks. + +- rockchip,sr_idle : Configure the SR_IDLE value, defined the + selfrefresh idle period, memories are places + into self-refresh mode if bus is idle for + SR_IDLE*1024 DFI clocks (DFI clocks freq is + half of dram's clocks), defaule value is "0". + +- rockchip,sr_mc_gate_idle : Defined the self-refresh with memory and + controller clock gating idle period, memories + are places into self-refresh mode and memory + controller clock arg gating if bus is idle for + sr_mc_gate_idle*1024 DFI clocks. + +- rockchip,srpd_lite_idle : Defined the self-refresh power down idle + period, memories are places into self-refresh + power down mode if bus is idle for + srpd_lite_idle*1024 DFI clocks. This parameter + is for LPDDR4 only. + +- rockchip,standby_idle :Defined the standby idle period, memories are + places into self-refresh than controller, pi, + phy and dram clock will gating if bus is idle + for standby_idle * DFI clocks. + +- rockchip,dram_dll_disb_freq : It's defined the DDR3 dll bypass frequency in + MHz, when ddr freq less than DRAM_DLL_DISB_FREQ, + ddr3 dll will bypssed note: if dll was bypassed, + the odt also stop working. + +- rockchip,phy_dll_disb_freq : Defined the PHY dll bypass frequency in + MHz (Mega Hz), when ddr freq less than + DRAM_DLL_DISB_FREQ, phy dll will bypssed. + note: phy dll and phy odt are independent. + +- rockchip,ddr3_odt_disb_freq : When dram type is DDR3, this parameter defined + the odt disable frequency in MHz (Mega Hz), + when ddr frequency less then ddr3_odt_disb_freq, + the odt on dram side and controller side are +
[PATCH 4/7] drm/panel: Add Sinlinx SinA33 7" panel
Hi Everyone,
01.09.2016, 23:40, "Maxime Ripard" :
> Â The SinA33 has an unidentified panel. Add the timings for it under a new
> Â compatible.
Excuse me...
I will ask a question which is not fully related to the patch here...
If I want to add a generic panel for Q8 tablets, what should it be called?
"allwinner,q8-lcd-panel-800x480"?
And, Hans, do you have any examples for a 1024x600 Q8 A33 tablet?
(If the answer is yes, I think sun8i-a33-q8-tablet.dts will met a split...)
Thanks,
Icenowy
> Â Signed-off-by: Maxime Ripard
> Â ---
> Â Â drivers/gpu/drm/panel/panel-simple.c | 26 ++
> Â Â 1 file changed, 26 insertions(+)
>
> Â diff --git a/drivers/gpu/drm/panel/panel-simple.c
> b/drivers/gpu/drm/panel/panel-simple.c
> Â index 85143d1b9b31..af142e804245 100644
> Â --- a/drivers/gpu/drm/panel/panel-simple.c
> Â +++ b/drivers/gpu/drm/panel/panel-simple.c
> Â @@ -1409,6 +1409,29 @@ static const struct panel_desc
> shelly_sca07010_bfn_lnn = {
> Â Â Â Â Â Â Â Â Â Â .bus_format = MEDIA_BUS_FMT_RGB666_1X18,
> Â Â };
>
> Â +static const struct drm_display_mode sinlinx_sina33_lcd_7_mode = {
> Â + .clock = 66000,
> Â + .hdisplay = 1024,
> Â + .hsync_start = 1024 + 160,
> Â + .hsync_end = 1024 + 160 + 70,
> Â + .htotal = 1024 + 160 + 70 + 90,
> Â + .vdisplay = 600,
> Â + .vsync_start = 600 + 127,
> Â + .vsync_end = 600 + 127 + 20,
> Â + .vtotal = 600 + 127 + 20 + 3,
> Â + .vrefresh = 60,
> Â +};
> Â +
> Â +static const struct panel_desc sinlinx_sina33_lcd_7 = {
> Â + .modes = &sinlinx_sina33_lcd_7_mode,
> Â + .num_modes = 1,
> Â + .size = {
> Â + .width = 154,
> Â + .height = 87,
> Â + },
> Â + .bus_format = MEDIA_BUS_FMT_RGB666_1X18,
> Â +};
> Â +
> Â Â static const struct drm_display_mode starry_kr122ea0sra_mode = {
> Â Â Â Â Â Â Â Â Â Â .clock = 147000,
> Â Â Â Â Â Â Â Â Â Â .hdisplay = 1920,
> Â @@ -1644,6 +1667,9 @@ static const struct of_device_id platform_of_match[]
> = {
> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â .compatible = "shelly,sca07010-bfn-lnn",
> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â .data = &shelly_sca07010_bfn_lnn,
> Â Â Â Â Â Â Â Â Â Â }, {
> Â + .compatible = "sinlinx,sina33-lcd-7",
> Â + .data = &sinlinx_sina33_lcd_7,
> Â + }, {
> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â .compatible = "starry,kr122ea0sra",
> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â .data = &starry_kr122ea0sra,
> Â Â Â Â Â Â Â Â Â Â }, {
> Â --
> Â 2.9.2
>
> Â ___
> Â linux-arm-kernel mailing list
> Â linux-arm-kernel at lists.infradead.org
> Â http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
[PATCH v9 3/5] Documentation: bindings: add dt documentation for rk3399 dmc
Hi Lin, Looks good to me. I add one comment on below. If you modify it according to my comment, feel free to add my tag. Reviewed-by: Chanwoo Choi On 2016ë 09ì 03ì¼ 06:08, Lin Huang wrote: > This patch adds the documentation for rockchip rk3399 dmc driver. > > Signed-off-by: Lin Huang > --- > Changes in v9: > - add ddr timing property to node > > Changes in v8: > - add ddr timing properties > > Changes in v7: > - None > > Changes in v6: > -Add more detail in Documentation > > Changes in v5: > -None > > Changes in v4: > -None > > Changes in v3: > -None > > Changes in v2: > -None > > Changes in v1: > -None > .../devicetree/bindings/devfreq/rk3399_dmc.txt | 202 > + > 1 file changed, 202 insertions(+) > create mode 100644 Documentation/devicetree/bindings/devfreq/rk3399_dmc.txt > > diff --git a/Documentation/devicetree/bindings/devfreq/rk3399_dmc.txt > b/Documentation/devicetree/bindings/devfreq/rk3399_dmc.txt > new file mode 100644 > index 000..f187c8fa > --- /dev/null > +++ b/Documentation/devicetree/bindings/devfreq/rk3399_dmc.txt > @@ -0,0 +1,202 @@ > +* Rockchip rk3399 DMC(Dynamic Memory Controller) device > + > +Required properties: > +- compatible: Must be "rockchip,rk3399-dmc". > +- devfreq-events: Node to get DDR loading, Refer to > + Documentation/devicetree/bindings/devfreq/ > + rockchip-dfi.txt > +- interrupts: The interrupt number to the CPU. The interrupt > + specifier format depends on the interrupt controller. > + It should be DCF interrupts, when DDR dvfs finish, > + it will happen. > +- clocks: Phandles for clock specified in "clock-names" property > +- clock-names : The name of clock used by the DFI, must be > + "pclk_ddr_mon"; > +- operating-points-v2:Refer to > Documentation/devicetree/bindings/power/opp.txt > + for details. > +- center-supply: DMC supply node. > +- status: Marks the node enabled/disabled. > + > +Following properties are ddr timing: > + > +- dram_speed_bin :Value is defined at include/dt-bindings/clock/ddr.h, > + it select ddr3 cl-trp-trcd type, default value > + "DDR3_DEFAULT".it must selected according to > + "Speed Bin" in ddr3 datasheet, DO NOT use smaller > + "Speed Bin" than ddr3 exactly is. > + > +- pd_idle : Config the PD_IDLE value, defined the power-down idle > + period, memories are places into power-down mode if > + bus is idle for PD_IDLE DFI clocks. > + > +- sr_idle : Configure the SR_IDLE value, defined the selfrefresh > + idle period, memories are places into self-refresh > + mode if bus is idle for SR_IDLE*1024 DFI clocks > + (DFI clocks freq is half of dram's clocks), defaule > + value is "0". > + > +- sr_mc_gate_idle : Defined the self-refresh with memory and controller > + clock gating idle period, memories are places into > + self-refresh mode and memory controller clock arg > + gating if bus is idle for sr_mc_gate_idle*1024 DFI > + clocks. > + > +- srpd_lite_idle :Defined the self-refresh power down idle period, > + memories are places into self-refresh power down > + mode if bus is idle for srpd_lite_idle*1024 DFI > + clocks. This parameter is for LPDDR4 only. > + > +- standby_idle : Defined the standby idle period, memories are places > + into self-refresh than controller, pi, phy and dram > + clock will gating if bus is idle for > + standby_idle * DFI clocks. > + > +- dram_dll_disb_freq :It's defined the DDR3 dll bypass frequency in > MHz > + when ddr freq less than DRAM_DLL_DISB_FREQ, ddr3 > + dll will bypssed note: if dll was bypassed, the > + odt also stop working. > + > +- phy_dll_disb_freq : Defined the PHY dll bypass frequency in MHz > (Mega Hz), > + when ddr freq less than DRAM_DLL_DISB_FREQ, phy dll > + will bypssed. note: phy dll and phy odt are > + independent > + > +- ddr3_odt_disb_freq :When dram type is DDR3, this parameter defined > the > + odt disable frequency in MHz (Mega Hz), when ddr > + frequency less then ddr3_odt_disb_freq, the odt > + on dram side and controller side are both disabled. > + > +- ddr3_drv : When dram type is DDR3, this parameter define the > +
[PATCH v9 1/5] Documentation: bindings: add dt documentation for dfi controller
Hi Lin,
Looks good to me.
Acked-by: Chanwoo Choi
Best Regards,
Chanwoo Choi
On 2016ë
09ì 03ì¼ 06:08, Lin Huang wrote:
> This patch adds the documentation for rockchip dfi devfreq-event driver.
>
> Signed-off-by: Lin Huang
> ---
> Changes in v9:
> - reorder compatible and reg
>
> Changes in v8:
> - delete a unuse blank line
>
> Changes in v7:
> - None
>
> Changes in v6:
> - None
>
> Changes in v5:
> - None
>
> Changes in v4:
> - None
>
> Changes in v3:
> - None
>
> Changes in v2:
> - None
>
> Changes in v1:
> - None
>
> .../bindings/devfreq/event/rockchip-dfi.txt | 19
> +++
> 1 file changed, 19 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/devfreq/event/rockchip-dfi.txt
>
> diff --git a/Documentation/devicetree/bindings/devfreq/event/rockchip-dfi.txt
> b/Documentation/devicetree/bindings/devfreq/event/rockchip-dfi.txt
> new file mode 100644
> index 000..f223313
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/devfreq/event/rockchip-dfi.txt
> @@ -0,0 +1,19 @@
> +
> +* Rockchip rk3399 DFI device
> +
> +Required properties:
> +- compatible: Must be "rockchip,rk3399-dfi".
> +- reg: physical base address of each DFI and length of memory mapped region
> +- rockchip,pmu: phandle to the syscon managing the "pmu general register
> files"
> +- clocks: phandles for clock specified in "clock-names" property
> +- clock-names : the name of clock used by the DFI, must be "pclk_ddr_mon";
> +
> +Example:
> + dfi: dfi at 0xff63 {
> + compatible = "rockchip,rk3399-dfi";
> + reg = <0x00 0xff63 0x00 0x4000>;
> + rockchip,pmu = <&pmugrf>;
> + clocks = <&cru PCLK_DDR_MON>;
> + clock-names = "pclk_ddr_mon";
> + status = "disabled";
> + };
>
[PATCH v10 0/5] rk3399 support ddr frequency scaling
rk3399 platform have dfi controller can monitor ddr load, and dcf controller to handle ddr register so we can get the right ddr frequency and make ddr controller happy work(which will implement in bl31). So we do ddr frequency scaling with following flow: kernelbl31 monitor ddr load | | get_target_rate | | pass rate to bl31 clk_set_rate(ddr) ->run dcf flow | | | | wait dcf interrupt<---trigger dcf interrupt | | return Lin Huang (5): Documentation: bindings: add dt documentation for dfi controller PM / devfreq: event: support rockchip dfi controller Documentation: bindings: add dt documentation for rk3399 dmc PM / devfreq: rockchip: add devfreq driver for rk3399 dmc drm/rockchip: Add dmc notifier in vop driver Following patch: clk: rockchip: add new clock-type for the ddrclk clk: rockchip: rk3399: add SCLK_DDRCLK ID for ddrc clk: rockchip: rk3399: add ddrc clock support have applied to: http://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip.git/v4.9-clk/next .../bindings/devfreq/event/rockchip-dfi.txt| 19 + .../devicetree/bindings/devfreq/rk3399_dmc.txt | 210 + drivers/devfreq/Kconfig| 11 + drivers/devfreq/Makefile | 1 + drivers/devfreq/event/Kconfig | 7 + drivers/devfreq/event/Makefile | 1 + drivers/devfreq/event/rockchip-dfi.c | 256 +++ drivers/devfreq/rk3399_dmc.c | 480 + drivers/gpu/drm/rockchip/rockchip_drm_vop.c| 116 + 9 files changed, 1101 insertions(+) create mode 100644 Documentation/devicetree/bindings/devfreq/event/rockchip-dfi.txt create mode 100644 Documentation/devicetree/bindings/devfreq/rk3399_dmc.txt create mode 100644 drivers/devfreq/event/rockchip-dfi.c create mode 100644 drivers/devfreq/rk3399_dmc.c -- 2.6.6
[PATCH v10 1/5] Documentation: bindings: add dt documentation for dfi controller
This patch adds the documentation for rockchip dfi devfreq-event driver.
Signed-off-by: Lin Huang
Acked-by: Chanwoo Choi
---
Changes in v10:
- None
Changes in v9:
- reorder compatible and reg
Changes in v8:
- delete a unuse blank line
Changes in v7:
- None
Changes in v6:
- None
Changes in v5:
- None
Changes in v4:
- None
Changes in v3:
- None
Changes in v2:
- None
Changes in v1:
- None
.../bindings/devfreq/event/rockchip-dfi.txt | 19 +++
1 file changed, 19 insertions(+)
create mode 100644
Documentation/devicetree/bindings/devfreq/event/rockchip-dfi.txt
diff --git a/Documentation/devicetree/bindings/devfreq/event/rockchip-dfi.txt
b/Documentation/devicetree/bindings/devfreq/event/rockchip-dfi.txt
new file mode 100644
index 000..f223313
--- /dev/null
+++ b/Documentation/devicetree/bindings/devfreq/event/rockchip-dfi.txt
@@ -0,0 +1,19 @@
+
+* Rockchip rk3399 DFI device
+
+Required properties:
+- compatible: Must be "rockchip,rk3399-dfi".
+- reg: physical base address of each DFI and length of memory mapped region
+- rockchip,pmu: phandle to the syscon managing the "pmu general register files"
+- clocks: phandles for clock specified in "clock-names" property
+- clock-names : the name of clock used by the DFI, must be "pclk_ddr_mon";
+
+Example:
+ dfi: dfi at 0xff63 {
+ compatible = "rockchip,rk3399-dfi";
+ reg = <0x00 0xff63 0x00 0x4000>;
+ rockchip,pmu = <&pmugrf>;
+ clocks = <&cru PCLK_DDR_MON>;
+ clock-names = "pclk_ddr_mon";
+ status = "disabled";
+ };
--
2.6.6
[PATCH v10 2/5] PM / devfreq: event: support rockchip dfi controller
on rk3399 platform, there is dfi conroller can monitor
ddr load, base on this result, we can do ddr freqency
scaling.
Signed-off-by: Lin Huang
Signed-off-by: MyungJoo Ham
Acked-by: Chanwoo Choi
---
Changes in v10:
-None
Changes in v9:
-None
Changes in v8:
-None
Changes in v7:
-access need to *4 to get right DDR loading
Changes in v6:
-None
Changes in v5:
-None
Changes in v4:
-None
Changes in v3:
-None
Changes in v2:
-None
Changes in v1:
-None
drivers/devfreq/event/Kconfig| 7 +
drivers/devfreq/event/Makefile | 1 +
drivers/devfreq/event/rockchip-dfi.c | 256 +++
3 files changed, 264 insertions(+)
create mode 100644 drivers/devfreq/event/rockchip-dfi.c
diff --git a/drivers/devfreq/event/Kconfig b/drivers/devfreq/event/Kconfig
index eb6f74a..20d82c2 100644
--- a/drivers/devfreq/event/Kconfig
+++ b/drivers/devfreq/event/Kconfig
@@ -30,4 +30,11 @@ config DEVFREQ_EVENT_EXYNOS_PPMU
(Platform Performance Monitoring Unit) counters to estimate the
utilization of each module.
+config DEVFREQ_EVENT_ROCKCHIP_DFI
+ tristate "ROCKCHIP DFI DEVFREQ event Driver"
+ depends on ARCH_ROCKCHIP
+ help
+ This add the devfreq-event driver for Rockchip SoC. It provides DFI
+ (DDR Monitor Module) driver to count ddr load.
+
endif # PM_DEVFREQ_EVENT
diff --git a/drivers/devfreq/event/Makefile b/drivers/devfreq/event/Makefile
index 3d6afd3..dda7090 100644
--- a/drivers/devfreq/event/Makefile
+++ b/drivers/devfreq/event/Makefile
@@ -2,3 +2,4 @@
obj-$(CONFIG_DEVFREQ_EVENT_EXYNOS_NOCP) += exynos-nocp.o
obj-$(CONFIG_DEVFREQ_EVENT_EXYNOS_PPMU) += exynos-ppmu.o
+obj-$(CONFIG_DEVFREQ_EVENT_ROCKCHIP_DFI) += rockchip-dfi.o
diff --git a/drivers/devfreq/event/rockchip-dfi.c
b/drivers/devfreq/event/rockchip-dfi.c
new file mode 100644
index 000..43fcc5a
--- /dev/null
+++ b/drivers/devfreq/event/rockchip-dfi.c
@@ -0,0 +1,256 @@
+/*
+ * Copyright (c) 2016, Fuzhou Rockchip Electronics Co., Ltd
+ * Author: Lin Huang
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define RK3399_DMC_NUM_CH 2
+
+/* DDRMON_CTRL */
+#define DDRMON_CTRL0x04
+#define CLR_DDRMON_CTRL(0x1f << 0)
+#define LPDDR4_EN (0x10001 << 4)
+#define HARDWARE_EN(0x10001 << 3)
+#define LPDDR3_EN (0x10001 << 2)
+#define SOFTWARE_EN(0x10001 << 1)
+#define SOFTWARE_DIS (0x1 << 1)
+#define TIME_CNT_EN(0x10001 << 0)
+
+#define DDRMON_CH0_COUNT_NUM 0x28
+#define DDRMON_CH0_DFI_ACCESS_NUM 0x2c
+#define DDRMON_CH1_COUNT_NUM 0x3c
+#define DDRMON_CH1_DFI_ACCESS_NUM 0x40
+
+/* pmu grf */
+#define PMUGRF_OS_REG2 0x308
+#define DDRTYPE_SHIFT 13
+#define DDRTYPE_MASK 7
+
+enum {
+ DDR3 = 3,
+ LPDDR3 = 6,
+ LPDDR4 = 7,
+ UNUSED = 0xFF
+};
+
+struct dmc_usage {
+ u32 access;
+ u32 total;
+};
+
+/*
+ * The dfi controller can monitor DDR load. It has an upper and lower threshold
+ * for the operating points. Whenever the usage leaves these bounds an event is
+ * generated to indicate the DDR frequency should be changed.
+ */
+struct rockchip_dfi {
+ struct devfreq_event_dev *edev;
+ struct devfreq_event_desc *desc;
+ struct dmc_usage ch_usage[RK3399_DMC_NUM_CH];
+ struct device *dev;
+ void __iomem *regs;
+ struct regmap *regmap_pmu;
+ struct clk *clk;
+};
+
+static void rockchip_dfi_start_hardware_counter(struct devfreq_event_dev *edev)
+{
+ struct rockchip_dfi *info = devfreq_event_get_drvdata(edev);
+ void __iomem *dfi_regs = info->regs;
+ u32 val;
+ u32 ddr_type;
+
+ /* get ddr type */
+ regmap_read(info->regmap_pmu, PMUGRF_OS_REG2, &val);
+ ddr_type = (val >> DDRTYPE_SHIFT) & DDRTYPE_MASK;
+
+ /* clear DDRMON_CTRL setting */
+ writel_relaxed(CLR_DDRMON_CTRL, dfi_regs + DDRMON_CTRL);
+
+ /* set ddr type to dfi */
+ if (ddr_type == LPDDR3)
+ writel_relaxed(LPDDR3_EN, dfi_regs + DDRMON_CTRL);
+ else if (ddr_type == LPDDR4)
+ writel_relaxed(LPDDR4_EN, dfi_regs + DDRMON_CTRL);
+
+ /* enable count, use software mode */
+ writel_relaxed(SOFTWARE_EN, dfi_regs + DDRMON_CTRL);
+}
+
+static void rockchip_dfi_stop_hardware_counter(struct devfreq_event_dev *edev)
+{
+ struct rockchip_dfi *info = devfreq_event_get_drvdata(edev);
+ void __iomem *dfi_reg
[PATCH v10 4/5] PM / devfreq: rockchip: add devfreq driver for rk3399 dmc
base on dfi result, we do ddr frequency scaling, register
dmc driver to devfreq framework, and use simple-ondemand
policy.
Signed-off-by: Lin Huang
Signed-off-by: MyngJoo Ham
Reviewed-by: Chanwoo Choi
---
Changes in v10:
- None
Changes in v9:
- None
Changes in v8:
- None
Changes in v8:
- do not use ddr_timing node, get ddr timing directly
Changes in v7:
- remove a blank line
Changes in v6:
- fix some nit suggest by Chanwoo Choi
Changes in v5:
- improve dmc driver suggest by Chanwoo Choi
Changes in v4:
- use arm_smccc_smc() function talk to bl31
- delete rockchip_dmc.c file and config
- delete dmc_notify
- adjust probe order
Changes in v3:
- operate dram setting through sip call
- imporve set rate flow
Changes in v2:
- None
Changes in v1:
- move dfi controller to event
- fix set voltage sequence when set rate fail
- change Kconfig type from tristate to bool
- move unuse EXPORT_SYMBOL_GPL()
drivers/devfreq/Kconfig | 11 +
drivers/devfreq/Makefile | 1 +
drivers/devfreq/rk3399_dmc.c | 480 +++
3 files changed, 492 insertions(+)
create mode 100644 drivers/devfreq/rk3399_dmc.c
diff --git a/drivers/devfreq/Kconfig b/drivers/devfreq/Kconfig
index a5be56e..e848121 100644
--- a/drivers/devfreq/Kconfig
+++ b/drivers/devfreq/Kconfig
@@ -100,6 +100,17 @@ config ARM_TEGRA_DEVFREQ
It reads ACTMON counters of memory controllers and adjusts the
operating frequencies and voltages with OPP support.
+config ARM_RK3399_DMC_DEVFREQ
+ tristate "ARM RK3399 DMC DEVFREQ Driver"
+ depends on ARCH_ROCKCHIP
+ select DEVFREQ_EVENT_ROCKCHIP_DFI
+ select DEVFREQ_GOV_SIMPLE_ONDEMAND
+ select PM_OPP
+ help
+ This adds the DEVFREQ driver for the RK3399 DMC(Dynamic Memory
Controller).
+ It sets the frequency for the memory controller and reads the usage
counts
+ from hardware.
+
source "drivers/devfreq/event/Kconfig"
endif # PM_DEVFREQ
diff --git a/drivers/devfreq/Makefile b/drivers/devfreq/Makefile
index 09f11d9..fbff40a 100644
--- a/drivers/devfreq/Makefile
+++ b/drivers/devfreq/Makefile
@@ -8,6 +8,7 @@ obj-$(CONFIG_DEVFREQ_GOV_PASSIVE) += governor_passive.o
# DEVFREQ Drivers
obj-$(CONFIG_ARM_EXYNOS_BUS_DEVFREQ) += exynos-bus.o
+obj-$(CONFIG_ARM_RK3399_DMC_DEVFREQ) += rk3399_dmc.o
obj-$(CONFIG_ARM_TEGRA_DEVFREQ)+= tegra-devfreq.o
# DEVFREQ Event Drivers
diff --git a/drivers/devfreq/rk3399_dmc.c b/drivers/devfreq/rk3399_dmc.c
new file mode 100644
index 000..54d65f2
--- /dev/null
+++ b/drivers/devfreq/rk3399_dmc.c
@@ -0,0 +1,480 @@
+/*
+ * Copyright (c) 2016, Fuzhou Rockchip Electronics Co., Ltd.
+ * Author: Lin Huang
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+struct dram_timing {
+ unsigned int ddr3_speed_bin;
+ unsigned int pd_idle;
+ unsigned int sr_idle;
+ unsigned int sr_mc_gate_idle;
+ unsigned int srpd_lite_idle;
+ unsigned int standby_idle;
+ unsigned int auto_pd_dis_freq;
+ unsigned int dram_dll_dis_freq;
+ unsigned int phy_dll_dis_freq;
+ unsigned int ddr3_odt_dis_freq;
+ unsigned int ddr3_drv;
+ unsigned int ddr3_odt;
+ unsigned int phy_ddr3_ca_drv;
+ unsigned int phy_ddr3_dq_drv;
+ unsigned int phy_ddr3_odt;
+ unsigned int lpddr3_odt_dis_freq;
+ unsigned int lpddr3_drv;
+ unsigned int lpddr3_odt;
+ unsigned int phy_lpddr3_ca_drv;
+ unsigned int phy_lpddr3_dq_drv;
+ unsigned int phy_lpddr3_odt;
+ unsigned int lpddr4_odt_dis_freq;
+ unsigned int lpddr4_drv;
+ unsigned int lpddr4_dq_odt;
+ unsigned int lpddr4_ca_odt;
+ unsigned int phy_lpddr4_ca_drv;
+ unsigned int phy_lpddr4_ck_cs_drv;
+ unsigned int phy_lpddr4_dq_drv;
+ unsigned int phy_lpddr4_odt;
+};
+
+struct rk3399_dmcfreq {
+ struct device *dev;
+ struct devfreq *devfreq;
+ struct devfreq_simple_ondemand_data ondemand_data;
+ struct clk *dmc_clk;
+ struct devfreq_event_dev *edev;
+ struct mutex lock;
+ struct dram_timing timing;
+
+ /*
+* DDR Converser of Frequency (DCF) is used to implement DDR frequency
+* conversion without the participation of CPU, we will implement and
+* control it in arm trust firmware.
+*/
+ wait_queue_head_t wait_dcf_queue;
[PATCH v10 5/5] drm/rockchip: Add dmc notifier in vop driver
when in ddr frequency scaling process, vop can not do enable or
disable operation, since in dcf we check vop clock to see whether
vop work. If vop work, dcf do ddr frequency scaling when vop
in vblank status, and we need to read vop register to check whether
vop go into vblank status. If vop not work, dcf can do ddr frequency
any time. So when do ddr frequency scaling, you disabled or enable
vop, there may two bad thing happen: 1, the panel flicker(when vop from
disable status change to enable). 2, kernel hang (when vop from enable
status change to disable, dcf need to read vblank status, but if you disable
vop clock, it can not get the status, it will lead soc dead) So we need
register to devfreq notifier, and we can get the dmc status. Also, when
there have two vop enabled, we need to disable dmc, since dcf only base
on one vop vblank time, so the other panel will flicker when do ddr
frequency scaling.
Signed-off-by: Lin Huang
Reviewed-by: Chanwoo Choi
---
Changes in v10:
- None
Changes in v9:
- None
Changes in v8:
- None
Changes in v7:
- None
Changes in v6:
- fix a build error
Changes in v5:
- improve some nits
Changes in v4:
- register notifier to devfreq_register_notifier
- use DEVFREQ_PRECHANGE and DEVFREQ_POSTCHANGE to get dmc status
- when two vop enable, disable dmc
- when two vop back to one vop, enable dmc
Changes in v3:
- when do vop eanble/disable, dmc will wait until it finish
Changes in v2:
- None
Changes in v1:
- use wait_event instead usleep
drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 116
1 file changed, 116 insertions(+)
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index efbc41a..a73f3aa 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -19,6 +19,8 @@
#include
#include
+#include
+#include
#include
#include
#include
@@ -118,6 +120,13 @@ struct vop {
const struct vop_data *data;
+ struct devfreq *devfreq;
+ struct devfreq_event_dev *devfreq_event_dev;
+ struct notifier_block dmc_nb;
+ int dmc_in_process;
+ int vop_switch_status;
+ wait_queue_head_t wait_dmc_queue;
+ wait_queue_head_t wait_vop_switch_queue;
uint32_t *regsbak;
void __iomem *regs;
@@ -428,11 +437,47 @@ static void vop_dsp_hold_valid_irq_disable(struct vop
*vop)
spin_unlock_irqrestore(&vop->irq_lock, flags);
}
+static int dmc_notify(struct notifier_block *nb, unsigned long event,
+ void *data)
+{
+ struct vop *vop = container_of(nb, struct vop, dmc_nb);
+
+ if (event == DEVFREQ_PRECHANGE) {
+ /*
+* check if vop in enable or disable process,
+* if yes, wait until it finishes, use 200ms as
+* timeout.
+*/
+ if (!wait_event_timeout(vop->wait_vop_switch_queue,
+ !vop->vop_switch_status, HZ / 5))
+ dev_warn(vop->dev,
+"Timeout waiting for vop swtich status\n");
+ vop->dmc_in_process = 1;
+ } else if (event == DEVFREQ_POSTCHANGE) {
+ vop->dmc_in_process = 0;
+ wake_up(&vop->wait_dmc_queue);
+ }
+
+ return NOTIFY_OK;
+}
+
static int vop_enable(struct drm_crtc *crtc)
{
struct vop *vop = to_vop(crtc);
+ int num_enabled_crtc = 0;
int ret;
+ /*
+* if in dmc scaling frequency process, wait until it finishes
+* use 200ms as timeout time.
+*/
+ if (!wait_event_timeout(vop->wait_dmc_queue,
+ !vop->dmc_in_process, HZ / 5))
+ dev_warn(vop->dev,
+"Timeout waiting for dmc when vop enable\n");
+
+ vop->vop_switch_status = 1;
+
ret = pm_runtime_get_sync(vop->dev);
if (ret < 0) {
dev_err(vop->dev, "failed to get pm runtime: %d\n", ret);
@@ -479,6 +524,21 @@ static int vop_enable(struct drm_crtc *crtc)
drm_crtc_vblank_on(crtc);
+ vop->vop_switch_status = 0;
+ wake_up(&vop->wait_vop_switch_queue);
+
+ /* check how many VOPs in use now */
+ drm_for_each_crtc(crtc, vop->drm_dev) {
+ if (crtc->state->enable)
+ num_enabled_crtc++;
+ }
+
+ /* if enable two vop, need to disable dmc */
+ if ((num_enabled_crtc > 1) && vop->devfreq) {
+ if (vop->devfreq_event_dev)
+ devfreq_event_disable_edev(vop->devfreq_event_dev);
+ devfreq_suspend_device(vop->devfreq);
+ }
return 0;
err_disable_aclk:
@@ -489,17 +549,31 @@ err_disable_hclk:
clk_disable(vop->hclk);
err_put_pm_runtime:
pm_runtime_put_sync(vop->dev);
+ vop->vop_switch_status = 0;
+ wake_up(&vop->wait_vop_switch_queue);
return ret;
}
Hibernation broken since commit 274ad65c9d02 ("drm/radeon: hard reset r600 and newer GPU when hibernating.")
Recently I got myself a new laptop with the following integrated GPU:
00:01.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI]
Mullins [Radeon R3 Graphics] (rev 40)
I found that hibernation is broken in Linux 4.7+ (it works in Linux 4.6)
and bisected it to commit 274ad65c9d02 ("drm/radeon: hard reset r600 and
newer GPU when hibernating.").
This has already been reported three months ago, but for a much older
GPU, see the thread starting at
https://lists.freedesktop.org/archives/dri-devel/2016-June/110050.html.
The symptoms are exactly the same as described by Boris Petkov in that
thread: after "systemctl hibernate" the screen goes blank, but the
machine remains powered on and needs to be power-cycled.
Any suggestions would be welcome.
Cheers,
Sven
[PATCH] drm/fsl-dcu: Add gamma set for crtc
On 2016-09-04 19:28, Meng Yi wrote:
> Hi Stefan,
>
>> > + */
>> > +static u32 swap_bytes(u16 var)
>>
>> We certainly don't want a byte swapping function in the driver. I am sure
>> Linux
>> has appropriate functions for that already, however, I am not convinced that
>> we need that at all.
>>
>
> Yeah, sure. Actually I had sent the V2 for this feature, which just
> using "<<24" to do this
> https://patchwork.kernel.org/patch/9252389/
>
Oh sorry, missed that patch. However, the discussion below is still
valid:
> ...
>
>> > + };
>> > +
>> > + struct drm_device *dev = crtc->dev;
>> > + struct fsl_dcu_drm_device *fsl_dev = dev->dev_private;
>> > + unsigned int i;
>> > + struct rgb glut;
>> > +
>> > + for (i = 0; i < size; i++) {
>> > + glut.r[i] = swap_bytes(r[i]);
>> > + glut.g[i] = swap_bytes(g[i]);
>> > + glut.b[i] = swap_bytes(b[i]);
>> > + regmap_write(fsl_dev->regmap, FSL_GAMMA_R + 4 * i,
>> glut.r[i]);
>> > + regmap_write(fsl_dev->regmap, FSL_GAMMA_G + 4 * i,
>> glut.g[i]);
>> > + regmap_write(fsl_dev->regmap, FSL_GAMMA_B + 4 * i,
>> glut.b[i]);
>>
>> I guess the problem is that regmap_write does byte swapping because
>> ls1021a.dtsi defines the whole DCU register space to be big-endian. So you
>> end
>> up doing byte swapping twice.
>>
>> If the gamma area is really little-endian, then DCU on LS1021a seems to be
>> quite a mess... :-(
>>
>> In this case, we probably should create a second regmap for the different
>> areas
>> specifically, e.g. change the device tree:
>>
>> reg = <0x0 0x2ce 0x0 0x2000
>> 0x0 0x2ce2000 0x0 0x2000
>> 0x0 0x2ce4000 0x0 0xc00
>> 0x0 0x2ce4c00 0x0 0x400>;
>>
>> reg-names = "regs", "palette", "gamma", "cursor";
>> i
>> /* Use Gamma is always little endian */
>> static const struct regmap_config fsl_dcu_regmap_gamma_config = { ...
>> .val_format_endian = REGMAP_ENDIAN_LITTLE, ...
>> };
>>
>> res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "gamma");
>> base_gamma = devm_ioremap_resource(dev, res);
>>
>> fsl_dev->regmap_gamma = devm_regmap_init_mmio(...)
>>
>>
>> regmap_write(fsl_dev->regmap_gamma, ...)
>>
>
> This is a errta for DCU, Gamma registers are supposed to be big
> endian, but actually it is little endian, do we
> Really need to create a second regmap?
Do you have the exact wording of the errata?
There are two problems to the current approach: First, the two byte
swaps (yours and then the byte swap due to the big-endian configuration
of regmap) seems ugly to me. Second, the gamma value is the lowest byte
in Vybrid, and on Vybrid the regmap is configured little-endian. Hence
your code won't work on Vybrid... Therefor I still think that using a
second regmap would be nicer.
--
Stefan
[PATCH] drm/fsl-dcu: Add gamma set for crtc
On 2016-09-03 03:49, Mark Brown wrote: > On Fri, Sep 02, 2016 at 02:22:46PM -0700, Stefan Agner wrote: >> I guess the problem is that regmap_write does byte swapping because >> ls1021a.dtsi defines the whole DCU register space to be big-endian. So >> you end up doing byte swapping twice. > >> If the gamma area is really little-endian, then DCU on LS1021a seems to >> be quite a mess... :-( > > Let's figure out what the hardware does first, espcially given that it's > this chip where we seem to be seeing a lot of confusion about endianness > issues. > According to Meng it is an errata for that whole area on that particular SoC (LS1021a)... Note that on Vybrid (the SoC I have on the table here) the whole DCU IP is little-endian, including the gamma area. >> @Mark, what do you think? Do we have a (better) solution for such cases? > > Is this area of the register map perhaps supposed to be accessed as a > byte stream? I don't think so, the Vybrid RM calls the area a table: The table is arranged as three separate memory blocks within the DCU4 memory map; one for each of the three color components. Each memory block has one entry for every possible 8-bit value and the entries are stored at 32-bit aligned addresses. This means that the upper 24 bits are not used while reading/writing the gamma memories. See Figure 16-22 for details of the memory arrangement. So, afaik, we deal with 3x 256 32-bit register which happen to be a different endianness on one SoC implementing the DCU IP... -- Stefan
[PATCH] drm/imx: Fix of_node ref counting
Hi Christophe,
Am Sonntag, den 04.09.2016, 08:45 +0200 schrieb Christophe JAILLET:
> This code is spurious.
> It takes a ref on a node, then call 'of_node_put' on it and then store
> this node somewhere.
The node pointer is not stored. Note that np is not dereferenced at all,
we just compare the pointer value against dev->of_node.
It doesn't matter whether we drop the reference before or after that.
> It is likely that taking the ref on the parent node and releasing the child
> node was expected instead.
Initially, np is assigned to the void *data parameter. The caller holds
the reference to that, and we are not allowed to decrement its refcount
(as of_get_next_parent does). Otherwise the iterator calling this match
function would drop references of all the device_nodes it compares
against.
> So, use 'of_get_next_parent' instead. It does all this in just one
> function call.
>
> Signed-off-by: Christophe JAILLET
> ---
> Un-tested
> ---
> drivers/gpu/drm/imx/imx-drm-core.c | 6 ++
> 1 file changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/imx/imx-drm-core.c
> b/drivers/gpu/drm/imx/imx-drm-core.c
> index 438bac8fbc2b..60fb388c80f8 100644
> --- a/drivers/gpu/drm/imx/imx-drm-core.c
> +++ b/drivers/gpu/drm/imx/imx-drm-core.c
> @@ -449,10 +449,8 @@ static int compare_of(struct device *dev, void *data)
> }
>
> /* Special case for LDB, one device for two channels */
> - if (of_node_cmp(np->name, "lvds-channel") == 0) {
> - np = of_get_parent(np);
> - of_node_put(np);
> - }
This could have been written as:
bool match;
/* Special case for LDB, one device for two channels */
if (of_node_cmp(np->name, "lvds-channel") == 0) {
struct device_node *parent = of_get_parent(np);
match = dev->of_node == parent;
of_node_put(parent);
} else {
match = dev->of_node == np;
}
return match;
which does exactly the same. Maybe the reuse of np and the pointer
comparison after of_node_put warrants a comment.
> + if (of_node_cmp(np->name, "lvds-channel") == 0)
> + np = of_get_next_parent(np);
>
> return dev->of_node == np;
> }
thanks
Philipp
[PATCH] drm/atomic: Reject properties not part of the object.
The legacy setprop ioctl doesn't attempt to set properties
that are not enumerated on the object. The atomic ioctl does,
fix this by validating first.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/drm_atomic.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 5cb2e22d5d55..a5126e5c05ee 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -1609,7 +1609,7 @@ int drm_mode_atomic_ioctl(struct drm_device *dev,
struct drm_crtc_state *crtc_state;
unsigned plane_mask;
int ret = 0;
- unsigned int i, j;
+ unsigned int i, j, k;
/* disallow for drivers not supporting atomic: */
if (!drm_core_check_feature(dev, DRIVER_ATOMIC))
@@ -1691,6 +1691,15 @@ retry:
goto out;
}
+ for (k = 0; k < obj->properties->count; k++)
+ if (obj->properties->properties[k]->base.id ==
prop_id)
+ break;
+
+ if (k == obj->properties->count) {
+ ret = -EINVAL;
+ goto out;
+ }
+
prop = drm_property_find(dev, prop_id);
if (!prop) {
drm_mode_object_unreference(obj);
--
2.7.4
[PATCH] drm/imx: Fix of_node ref counting
Am Montag, den 05.09.2016, 10:01 +0200 schrieb Philipp Zabel:
> Hi Christophe,
>
> Am Sonntag, den 04.09.2016, 08:45 +0200 schrieb Christophe JAILLET:
> > This code is spurious.
> > It takes a ref on a node, then call 'of_node_put' on it and then store
> > this node somewhere.
>
> The node pointer is not stored. Note that np is not dereferenced at all,
> we just compare the pointer value against dev->of_node.
> It doesn't matter whether we drop the reference before or after that.
>
> > It is likely that taking the ref on the parent node and releasing the child
> > node was expected instead.
>
> Initially, np is assigned to the void *data parameter. The caller holds
> the reference to that, and we are not allowed to decrement its refcount
> (as of_get_next_parent does). Otherwise the iterator calling this match
> function would drop references of all the device_nodes it compares
> against.
>
> > So, use 'of_get_next_parent' instead. It does all this in just one
> > function call.
> >
> > Signed-off-by: Christophe JAILLET
> > ---
> > Un-tested
> > ---
> > drivers/gpu/drm/imx/imx-drm-core.c | 6 ++
> > 1 file changed, 2 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/imx/imx-drm-core.c
> > b/drivers/gpu/drm/imx/imx-drm-core.c
> > index 438bac8fbc2b..60fb388c80f8 100644
> > --- a/drivers/gpu/drm/imx/imx-drm-core.c
> > +++ b/drivers/gpu/drm/imx/imx-drm-core.c
> > @@ -449,10 +449,8 @@ static int compare_of(struct device *dev, void *data)
> > }
> >
> > /* Special case for LDB, one device for two channels */
> > - if (of_node_cmp(np->name, "lvds-channel") == 0) {
> > - np = of_get_parent(np);
> > - of_node_put(np);
> > - }
>
> This could have been written as:
>
> bool match;
>
> /* Special case for LDB, one device for two channels */
> if (of_node_cmp(np->name, "lvds-channel") == 0) {
> struct device_node *parent = of_get_parent(np);
>
> match = dev->of_node == parent;
> of_node_put(parent);
> } else {
> match = dev->of_node == np;
> }
>
> return match;
>
> which does exactly the same. Maybe the reuse of np and the pointer
> comparison after of_node_put warrants a comment.
Actually, maybe we should just do
- if (of_node_cmp(np->name, "lvds-channel") == 0) {
- np = of_get_parent(np);
- of_node_put(np);
- }
+ if (of_node_cmp(np->name, "lvds-channel") == 0)
+ np = np->parent;
regards
Philipp
[PATCH v4 2/4] drm: Add API for capturing frame CRCs
On 2 September 2016 at 16:50, Emil Velikov wrote:
> Hi Tomeu,
>
> On 5 August 2016 at 11:45, Tomeu Vizoso wrote:
>
>> +#ifdef CONFIG_DEBUG_FS
>> + spin_lock_init(&crtc->crc.lock);
>> + init_waitqueue_head(&crtc->crc.wq);
>> + crtc->crc.source = kstrdup("auto", GFP_KERNEL);
> Pedantic: kstrdup() can never fail ?
Dealt with.
>> +#endif
>> +
>> if (drm_core_check_feature(dev, DRIVER_ATOMIC)) {
>> drm_object_attach_property(&crtc->base, config->prop_active,
>> 0);
>> drm_object_attach_property(&crtc->base,
>> config->prop_mode_id, 0);
>> @@ -764,6 +771,11 @@ void drm_crtc_cleanup(struct drm_crtc *crtc)
>> * the indices on the drm_crtc after us in the crtc_list.
>> */
>>
>> +#ifdef CONFIG_DEBUG_FS
>> + drm_debugfs_crtc_remove(crtc);
>> + kfree(crtc->crc.source);
>> +#endif
>> +
> Worth adding these two as static inlines in the header ?
Have moved the ifdefs to static functions in the same file.
> Things are a bit asymetrical here. drm_debugfs_crtc_add() is in
> drm_minor_register(), so why isn't drm_debugfs_crtc_remove() in
> drm_minor_free() ?
Good call. Have moved drm_debugfs_crtc_remove to drm_minor_unregister.
>> -#endif /* CONFIG_DEBUG_FS */
>> +int drm_debugfs_crtc_add(struct drm_crtc *crtc)
>> +{
>> + struct drm_minor *minor = crtc->dev->primary;
>> + struct dentry *root;
>> + char *name;
>> +
>> + name = kasprintf(GFP_KERNEL, "crtc-%d", crtc->index);
> Mildly related: some userspace projects define convenience helpers
> which you use in order to allocate the correct amount of space on
> stack.
> Is there such a set for the kernel ?
>
> With those the above will become something like:
> char name[5+DECIMAL_STR_MAX] = ksprintf("crtc-%d", crtc->index);
Don't know of those but I think that in this specific case an
allocation is not that much of a problem.
>> --- /dev/null
>> +++ b/drivers/gpu/drm/drm_debugfs_crc.c
>
>> + *
>> + * Authors:
>> + *Eric Anholt
>> + *Keith Packard
>> + *
> Wondering about these authorship lines - is the code copied/derived
> from somewhere ? If so please mention where from.
Done, and also fixed the actual people that should be in there.
>> +/*
>> + * 1 frame field of 10 chars plus a number of CRC fields of 10 chars each,
>> space
>> + * separated and with a newline at the end.
>> + */
>> +#define LINE_LEN(VALUES_CNT) (10 + 11 * VALUES_CNT + 1 + 1)
> Hmm I seem to suck at math. The macro seems larger than expected (comment and
> code wise) by 1, right ?
The comment indeed should mention that it's NULL-terminated, but the
code is correct, isn't it?
>> +#define MAX_LINE_LEN (LINE_LEN(DRM_MAX_CRC_NR))
>> +
> Worth using lowercase VALUES_CNT and less likely to clash macro names ?
Done.
>
>
>> + BUILD_BUG_ON_NOT_POWER_OF_2(DRM_CRC_ENTRIES_NR);
>> + crc->tail = (crc->tail + 1) & (DRM_CRC_ENTRIES_NR - 1);
> It's strange that the kernel does not have a macro for this. But for the sake
> of me I cannot find one.
Yeah.
>> --- a/drivers/gpu/drm/drm_drv.c
>> +++ b/drivers/gpu/drm/drm_drv.c
>> @@ -192,6 +192,7 @@ static void drm_minor_free(struct drm_device *dev,
>> unsigned int type)
>> static int drm_minor_register(struct drm_device *dev, unsigned int type)
>> {
>> struct drm_minor *minor;
>> + struct drm_crtc *crtc;
>> unsigned long flags;
>> int ret;
>>
>> @@ -207,6 +208,14 @@ static int drm_minor_register(struct drm_device *dev,
>> unsigned int type)
>> return ret;
>> }
>>
>> + if (type == DRM_MINOR_LEGACY) {
> Sidenote: If we did not use DRM_MINOR_LEGACY for render-only GPUs we would
> save a couple of cycles here :-)
>
>> + drm_for_each_crtc(crtc, dev) {
>> + ret = drm_debugfs_crtc_add(crtc);
>> + if (ret)
>> + goto err_debugfs;
> IMHO we don't want to bring down the whole setup if this fails, unlike
> where we cannot create debug/dri all together.
>
> Regardless: we seems to be missing the cleanup in the error path ?
Have changed it to only log an error and continue, so no cleanup is necessary.
>> +#if defined(CONFIG_DEBUG_FS)
>> +extern const struct file_operations drm_crc_control_fops;
>> +extern const struct file_operations drm_crtc_crc_fops;
> These seems to be named differently in the code. Namely:
>
> drm_crtc_crc_control_fops
> drm_crtc_crc_data_fops
>
> Then again, you don't seem to use the outside of the file, so I'd make them
> static and drop this hunk.
Oops.
>
>
>> * before data structures are torndown.
>> */
>> void (*early_unregister)(struct drm_crtc *crtc);
>> +
>> + /**
>> +* @set_crc_source:
>> +*
>> +* Changes the source of CRC checksums of frames at the request of
>> +* userspace, typically for testing purposes. The sources available
>> are
>> +* specific of each driver and a %
drm timing problems in sama5d3 Xplained.
Hi All. I am using DRM in a sama5d3 Xplained with display TM43 and I've found with the following problem: I deleted the network interfaces in the device tree for my system to boot faster. My problem is that now the startup script run before the driver has loaded correctly. I explain better: The startup script begin to appear before the creation of the framebuffer message appears. (See LogKernel.txt) atmel-hlcdc-display-controller atmel-hlcdc-dc: fb0: frame buffer device 1 - I can't use the framebuffer until the message is not displayed. (This did not matter. I want to use drm.) 2 - DRM don't work fine. If I try to paint on the screen (using planes) before the message it is created framebuffer appears, nothing appears on the display. This problem I can replicate with the demo atmel if I remove network interfaces in the device tree and adding a startup script that uses drm. I add the demo with the modified device tree so you can prove that occurs. https://drive.google.com/file/d/0B3EMwEbIHhkAbDhGMU1BcEVoYkU/view?usp=sharing You only need to add the startup script in /etc/rcS.d/ #!/bin/sh > modetest -M atmel-hlcdc -P 26:480x272+0+0 at AR15 I also tested with the latest version of kernel 4.8 RC3 and the problem is still happening. Thanks! Regards! -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160905/1161cb33/attachment.html> -- next part -- [0.00] Booting Linux on physical CPU 0x0 [0.00] Linux version 4.1.0-linux4sam_5.3 (ldesroches at ibiza) (gcc version 5.2.0 (GCC) ) #1 Sat Apr 16 13:00:00 CEST 2016 [0.00] CPU: ARMv7 Processor [410fc051] revision 1 (ARMv7), cr=10c53c7d [0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache [0.00] Machine model: Atmel SAMA5D3 Xplained TM43xx [0.00] cma: Reserved 64 MiB at 0x2800 [0.00] Memory policy: Data cache writeback [0.00] On node 0 totalpages: 65536 [0.00] free_area_init_node: node 0, pgdat c06e20c4, node_mem_map cfdda000 [0.00] Normal zone: 512 pages used for memmap [0.00] Normal zone: 0 pages reserved [0.00] Normal zone: 65536 pages, LIFO batch:15 [0.00] CPU: All CPU(s) started in SVC mode. [0.00] pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768 [0.00] pcpu-alloc: [0] 0 [0.00] Built 1 zonelists in Zone order, mobility grouping off. Total pages: 65024 [0.00] Kernel command line: console=ttyS0,115200 mtdparts=atmel_nand:256k(bootstrap)ro,512k(uboot)ro,256k(env),256k(env_redundant),256k(spare),512k(dtb),6M(kernel)ro,-(ro6 [0.00] PID hash table entries: 1024 (order: 0, 4096 bytes) [0.00] Dentry cache hash table entries: 32768 (order: 5, 131072 bytes) [0.00] Inode-cache hash table entries: 16384 (order: 4, 65536 bytes) [0.00] Memory: 186824K/262144K available (4985K kernel code, 179K rwdata, 1660K rodata, 192K init, 159K bss, 9784K reserved, 65536K cma-reserved) [0.00] Virtual kernel memory layout: vector : 0x - 0x1000 ( 4 kB) fixmap : 0xffc0 - 0xfff0 (3072 kB) vmalloc : 0xd080 - 0xff00 ( 744 MB) lowmem : 0xc000 - 0xd000 ( 256 MB) modules : 0xbf00 - 0xc000 ( 16 MB) .text : 0xc0008000 - 0xc0685928 (6647 kB) .init : 0xc0686000 - 0xc06b6000 ( 192 kB) .data : 0xc06b6000 - 0xc06e2ed8 ( 180 kB) .bss : 0xc06e2ed8 - 0xc070ad3c ( 160 kB) [0.00] NR_IRQS:16 nr_irqs:16 16 [0.00] clocksource pit: mask: 0xfff max_cycles: 0xfff, max_idle_ns: 14479245754 ns [0.00] sched_clock: 32 bits at 100 Hz, resolution 1000ns, wraps every 2147483647500ns [0.00] Console: colour dummy device 80x30 [0.05] Calibrating delay loop... 351.43 BogoMIPS (lpj=1757184) [0.06] pid_max: default: 32768 minimum: 301 [0.06] Mount-cache hash table entries: 1024 (order: 0, 4096 bytes) [0.06] Mountpoint-cache hash table entries: 1024 (order: 0, 4096 bytes) [0.06] CPU: Testing write buffer coherency: ok [0.06] Setting up static identity map for 0x20008200 - 0x20008258 [0.06] devtmpfs: initialized [0.07] VFP support v0.3: implementor 41 architecture 2 part 30 variant 5 rev 1 [0.08] clocksource jiffies: mask: 0x max_cycles: 0x, max_idle_ns: 1911260446275 ns [0.08] pinctrl core: initialized pinctrl subsystem [0.08] NET: Registered protocol family 16 [0.11] DMA: preallocated 256 KiB pool for atomic coherent allocations [0.11] cpuidle: using governor ladder [0.11] cpuidle: using governor menu [0.11] AT91: Detected SoC famil
[PATCH] drm/fsl-dcu: fix endian issue when using clk_register_divider
> Subject: [PATCH] drm/fsl-dcu: fix endian issue when using clk_register_divider
>
> Since using clk_register_divider to setup the pixel clock, regmap is no longer
> used. Regmap did take care of DCU using different endianness. Check
> endianness using the device-tree property "big-endian" to determine the
> location of DIV_RATIO.
>
> Cc: stable at vger.kernel.org
> Fixes: 2d701449bce1 ("drm/fsl-dcu: use common clock framework for pixel
> clock divider")
> Reported-by: Meng Yi
> Signed-off-by: Stefan Agner
> ---
> drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c | 7 ++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c b/drivers/gpu/drm/fsl-
> dcu/fsl_dcu_drm_drv.c
> index 7882387..8dd042e 100644
> --- a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
> +++ b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
> @@ -330,6 +330,7 @@ static int fsl_dcu_drm_probe(struct platform_device
> *pdev)
> const char *pix_clk_in_name;
> const struct of_device_id *id;
> int ret;
> + u8 div_ratio_shift = 0;
>
> fsl_dev = devm_kzalloc(dev, sizeof(*fsl_dev), GFP_KERNEL);
> if (!fsl_dev)
> @@ -382,11 +383,15 @@ static int fsl_dcu_drm_probe(struct platform_device
> *pdev)
> pix_clk_in = fsl_dev->clk;
> }
>
> + if (of_property_read_bool(dev->of_node, "big-endian"))
> + div_ratio_shift = 24;
> +
> +
> pix_clk_in_name = __clk_get_name(pix_clk_in);
> snprintf(pix_clk_name, sizeof(pix_clk_name), "%s_pix",
> pix_clk_in_name);
> fsl_dev->pix_clk = clk_register_divider(dev, pix_clk_name,
> pix_clk_in_name, 0, base + DCU_DIV_RATIO,
> - 0, 8, CLK_DIVIDER_ROUND_CLOSEST, NULL);
> + div_ratio_shift, 8, CLK_DIVIDER_ROUND_CLOSEST,
> NULL);
> if (IS_ERR(fsl_dev->pix_clk)) {
> dev_err(dev, "failed to register pix clk\n");
> ret = PTR_ERR(fsl_dev->pix_clk);
> --
> 2.9.0
Tested-by: Meng Yi
On LS1021A-TWR board.
Meng
[Bug 97590] Fury X (Fiji) LEDs do not reflect GPU load
https://bugs.freedesktop.org/show_bug.cgi?id=97590 --- Comment #2 from Adam Bolte --- Ah yep. Found the article you were referring to. http://www.phoronix.com/scan.php?page=news_item&px=Nouveau-LED-Driver -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160905/f7358fe6/attachment.html>
[PATCH v4 3/4] drm/i915: Use new CRC debugfs API
On 2 September 2016 at 17:18, Emil Velikov wrote:
> Hi Tomeu,
>
> IMHO it would be better to split out the refactoring into preparatory
> patch. It brings a minor change which (not 100% sure on that) should
> not cause issues but is worth pointing out.
I think at this point it would make sense to change the series
structure only if there was a strong reason, as a few people have
already looked at the patches already.
> On 5 August 2016 at 11:45, Tomeu Vizoso wrote:
>
>> +static int do_set_crc_source(struct drm_device *dev, enum pipe pipe,
>> +enum intel_pipe_crc_source source)
>> +{
>
>> + if (source == INTEL_PIPE_CRC_SOURCE_NONE) {
> Nit: use !source here or sourse != INTEL_PIPE_CRC_SOURCE_NONE
> elsewhere in the code ?
Agreed.
>
>> @@ -693,10 +718,11 @@ static int pipe_crc_set_source(struct drm_device *dev,
>> enum pipe pipe,
>> spin_unlock_irq(&pipe_crc->lock);
>> }
>>
>> - pipe_crc->source = source;
>> + ret = do_set_crc_source(dev, pipe, source);
>> + if (ret)
>> + goto out;
>>
> We seem to have modified pipe_crc even if the new function fails.
> Haven't check if it matters, but definatelly not ideal.
If we had modified pipe_crc that's because we were trying to start CRC
capture and we initialized the entry storage. As CRC generation is
disabled, those changes have no effects. When CRC capture is attempted
again, they will be initialized again.
To avoid this we would need to split the HW programming in two
functions and I'm not sure it would be worth it.
>> @@ -720,15 +746,6 @@ static int pipe_crc_set_source(struct drm_device *dev,
>> enum pipe pipe,
>> spin_unlock_irq(&pipe_crc->lock);
>>
>> kfree(entries);
>> -
>> - if (IS_G4X(dev))
>> - g4x_undo_pipe_scramble_reset(dev, pipe);
>> - else if (IS_VALLEYVIEW(dev) || IS_CHERRYVIEW(dev))
>> - vlv_undo_pipe_scramble_reset(dev, pipe);
>> - else if (IS_HASWELL(dev) && pipe == PIPE_A)
>> - hsw_trans_edp_pipe_A_crc_wa(dev, false);
>> -
>> - hsw_enable_ips(crtc);
> The above is the piece I have in mind:
> With the introduction of do_set_crc_source() the above are executed
> prior to the intel_wait_for_vblank() call.
>
> Afaics this will not cause any functional change, then again I'm not
> that familiar with the i915 vblank code.
Yeah, not sure either of when do those changes take effect.
>> +int intel_crtc_set_crc_source(struct drm_crtc *crtc, const char
>> *source_name,
>> + size_t *values_cnt)
>> +{
>
>> + ret = do_set_crc_source(crtc->dev, crtc->index, source);
>> +
>> + intel_display_power_put(dev_priv, power_domain);
>> +
>> + *values_cnt = 5;
>> +
> Please don't overwrite values_cnt if the function fails.
Done.
Thanks,
Tomeu
> Regards,
> Emil
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v5 0/4] New debugfs API for capturing CRC of frames
Hi, this series basically takes the facility for continuously capturing CRCs of frames from the i915 driver and into the DRM core. The idea is that test suites such as IGT use this information to check that frames that are exected to be identical, also have identical CRC values. Other drivers for hardware that can provide frame CRCs (including eDP panels that support self-refresh) can easily implement the new callback and provide userspace with the CRC values. Thanks, Tomeu Tomeu Vizoso (4): drm/i915/debugfs: Move out pipe CRC code drm: Add API for capturing frame CRCs drm/i915: Use new CRC debugfs API drm/i915: Put "cooked" vlank counters in frame CRC lines Documentation/gpu/drm-uapi.rst|6 + drivers/gpu/drm/Makefile |3 +- drivers/gpu/drm/drm_crtc.c| 29 +- drivers/gpu/drm/drm_debugfs.c | 34 +- drivers/gpu/drm/drm_debugfs_crc.c | 351 drivers/gpu/drm/drm_drv.c | 15 + drivers/gpu/drm/drm_internal.h| 10 + drivers/gpu/drm/i915/Makefile |2 +- drivers/gpu/drm/i915/i915_debugfs.c | 886 + drivers/gpu/drm/i915/i915_drv.c |2 +- drivers/gpu/drm/i915/i915_drv.h |3 +- drivers/gpu/drm/i915/i915_irq.c | 83 ++- drivers/gpu/drm/i915/intel_display.c |1 + drivers/gpu/drm/i915/intel_drv.h |7 + drivers/gpu/drm/i915/intel_pipe_crc.c | 1005 + include/drm/drm_crtc.h| 41 ++ include/drm/drm_debugfs_crc.h | 78 +++ 17 files changed, 1642 insertions(+), 914 deletions(-) create mode 100644 drivers/gpu/drm/drm_debugfs_crc.c create mode 100644 drivers/gpu/drm/i915/intel_pipe_crc.c create mode 100644 include/drm/drm_debugfs_crc.h -- 2.7.4
[PATCH v5 1/4] drm/i915/debugfs: Move out pipe CRC code
In preparation to using a generic API in the DRM core for continuous CRC
generation, move the related code out of i915_debugfs.c into a new file.
Eventually, only the Intel-specific code will remain in this new file.
v2: Rebased.
Signed-off-by: Tomeu Vizoso
---
drivers/gpu/drm/i915/Makefile | 2 +-
drivers/gpu/drm/i915/i915_debugfs.c | 886 +--
drivers/gpu/drm/i915/i915_drv.c | 2 +-
drivers/gpu/drm/i915/i915_drv.h | 2 +-
drivers/gpu/drm/i915/intel_drv.h | 5 +
drivers/gpu/drm/i915/intel_pipe_crc.c | 951 ++
6 files changed, 963 insertions(+), 885 deletions(-)
create mode 100644 drivers/gpu/drm/i915/intel_pipe_crc.c
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index a7da24640e88..6238f8042426 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -23,7 +23,7 @@ i915-y := i915_drv.o \
intel_runtime_pm.o
i915-$(CONFIG_COMPAT) += i915_ioc32.o
-i915-$(CONFIG_DEBUG_FS) += i915_debugfs.o
+i915-$(CONFIG_DEBUG_FS) += i915_debugfs.o intel_pipe_crc.o
# GEM code
i915-y += i915_cmd_parser.o \
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 7d7b4d9280e9..d8073cddffeb 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -26,19 +26,9 @@
*
*/
-#include
-#include
-#include
#include
-#include
-#include
#include
-#include
-#include
#include "intel_drv.h"
-#include "intel_ringbuffer.h"
-#include
-#include "i915_drv.h"
static inline struct drm_i915_private *node_to_i915(struct drm_info_node *node)
{
@@ -3401,12 +3391,6 @@ static int i915_drrs_status(struct seq_file *m, void
*unused)
return 0;
}
-struct pipe_crc_info {
- const char *name;
- struct drm_i915_private *dev_priv;
- enum pipe pipe;
-};
-
static int i915_dp_mst_info(struct seq_file *m, void *unused)
{
struct drm_i915_private *dev_priv = node_to_i915(m->private);
@@ -3436,848 +3420,6 @@ static int i915_dp_mst_info(struct seq_file *m, void
*unused)
return 0;
}
-static int i915_pipe_crc_open(struct inode *inode, struct file *filep)
-{
- struct pipe_crc_info *info = inode->i_private;
- struct drm_i915_private *dev_priv = info->dev_priv;
- struct intel_pipe_crc *pipe_crc = &dev_priv->pipe_crc[info->pipe];
-
- if (info->pipe >= INTEL_INFO(dev_priv)->num_pipes)
- return -ENODEV;
-
- spin_lock_irq(&pipe_crc->lock);
-
- if (pipe_crc->opened) {
- spin_unlock_irq(&pipe_crc->lock);
- return -EBUSY; /* already open */
- }
-
- pipe_crc->opened = true;
- filep->private_data = inode->i_private;
-
- spin_unlock_irq(&pipe_crc->lock);
-
- return 0;
-}
-
-static int i915_pipe_crc_release(struct inode *inode, struct file *filep)
-{
- struct pipe_crc_info *info = inode->i_private;
- struct drm_i915_private *dev_priv = info->dev_priv;
- struct intel_pipe_crc *pipe_crc = &dev_priv->pipe_crc[info->pipe];
-
- spin_lock_irq(&pipe_crc->lock);
- pipe_crc->opened = false;
- spin_unlock_irq(&pipe_crc->lock);
-
- return 0;
-}
-
-/* (6 fields, 8 chars each, space separated (5) + '\n') */
-#define PIPE_CRC_LINE_LEN (6 * 8 + 5 + 1)
-/* account for \'0' */
-#define PIPE_CRC_BUFFER_LEN(PIPE_CRC_LINE_LEN + 1)
-
-static int pipe_crc_data_count(struct intel_pipe_crc *pipe_crc)
-{
- assert_spin_locked(&pipe_crc->lock);
- return CIRC_CNT(pipe_crc->head, pipe_crc->tail,
- INTEL_PIPE_CRC_ENTRIES_NR);
-}
-
-static ssize_t
-i915_pipe_crc_read(struct file *filep, char __user *user_buf, size_t count,
- loff_t *pos)
-{
- struct pipe_crc_info *info = filep->private_data;
- struct drm_i915_private *dev_priv = info->dev_priv;
- struct intel_pipe_crc *pipe_crc = &dev_priv->pipe_crc[info->pipe];
- char buf[PIPE_CRC_BUFFER_LEN];
- int n_entries;
- ssize_t bytes_read;
-
- /*
-* Don't allow user space to provide buffers not big enough to hold
-* a line of data.
-*/
- if (count < PIPE_CRC_LINE_LEN)
- return -EINVAL;
-
- if (pipe_crc->source == INTEL_PIPE_CRC_SOURCE_NONE)
- return 0;
-
- /* nothing to read */
- spin_lock_irq(&pipe_crc->lock);
- while (pipe_crc_data_count(pipe_crc) == 0) {
- int ret;
-
- if (filep->f_flags & O_NONBLOCK) {
- spin_unlock_irq(&pipe_crc->lock);
- return -EAGAIN;
- }
-
- ret = wait_event_interruptible_lock_irq(pipe_crc->wq,
- pipe_crc_data_count(pipe_crc), pipe_crc->lock);
- if (ret) {
- spin_unlock_irq(&pipe_crc->lock);
- return ret;
- }
-
[PATCH v5 2/4] drm: Add API for capturing frame CRCs
Adds files and directories to debugfs for controlling and reading frame
CRCs, per CRTC:
dri/0/crtc-0/crc
dri/0/crtc-0/crc/control
dri/0/crtc-0/crc/data
Drivers can implement the set_crc_source callback() in drm_crtc_funcs to
start and stop generating frame CRCs and can add entries to the output
by calling drm_crtc_add_crc_entry.
v2:
- Lots of good fixes suggested by Thierry.
- Added documentation.
- Changed the debugfs layout.
- Moved to allocate the entries circular queue once when frame
generation gets enabled for the first time.
v3:
- Use the control file just to select the source, and start and stop
capture when the data file is opened and closed, respectively.
- Make variable the number of CRC values per entry, per source.
- Allocate entries queue each time we start capturing as now there
isn't a fixed number of CRC values per entry.
- Store the frame counter in the data file as a 8-digit hex number.
- For sources that cannot provide useful frame numbers, place
in the frame field.
v4:
- Build only if CONFIG_DEBUG_FS is enabled.
- Use memdup_user_nul.
- Consolidate calculation of the size of an entry in a helper.
- Add 0x prefix to hex numbers in the data file.
- Remove unnecessary snprintf and strlen usage in read callback.
v5:
- Made the crcs array in drm_crtc_crc_entry fixed-size
- Lots of other smaller improvements suggested by Emil Velikov
Signed-off-by: Tomeu Vizoso
---
Documentation/gpu/drm-uapi.rst| 6 +
drivers/gpu/drm/Makefile | 3 +-
drivers/gpu/drm/drm_crtc.c| 29 +++-
drivers/gpu/drm/drm_debugfs.c | 34 +++-
drivers/gpu/drm/drm_debugfs_crc.c | 351 ++
drivers/gpu/drm/drm_drv.c | 15 ++
drivers/gpu/drm/drm_internal.h| 10 ++
include/drm/drm_crtc.h| 41 +
include/drm/drm_debugfs_crc.h | 78 +
9 files changed, 564 insertions(+), 3 deletions(-)
create mode 100644 drivers/gpu/drm/drm_debugfs_crc.c
create mode 100644 include/drm/drm_debugfs_crc.h
diff --git a/Documentation/gpu/drm-uapi.rst b/Documentation/gpu/drm-uapi.rst
index 12b47c30fe2e..4d5f61b6c0f2 100644
--- a/Documentation/gpu/drm-uapi.rst
+++ b/Documentation/gpu/drm-uapi.rst
@@ -179,3 +179,9 @@ interfaces. Especially since all hardware-acceleration
interfaces to
userspace are driver specific for efficiency and other reasons these
interfaces can be rather substantial. Hence every driver has its own
chapter.
+
+Testing and validation
+==
+
+.. kernel-doc:: drivers/gpu/drm/drm_debugfs_crc.c
+ :doc: CRC ABI
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 4054c94a2301..9c99b051ce87 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -9,7 +9,7 @@ drm-y := drm_auth.o drm_bufs.o drm_cache.o \
drm_scatter.o drm_pci.o \
drm_platform.o drm_sysfs.o drm_hashtab.o drm_mm.o \
drm_crtc.o drm_fourcc.o drm_modes.o drm_edid.o \
- drm_info.o drm_debugfs.o drm_encoder_slave.o \
+ drm_info.o drm_encoder_slave.o \
drm_trace_points.o drm_global.o drm_prime.o \
drm_rect.o drm_vma_manager.o drm_flip_work.o \
drm_modeset_lock.o drm_atomic.o drm_bridge.o \
@@ -21,6 +21,7 @@ drm-$(CONFIG_PCI) += ati_pcigart.o
drm-$(CONFIG_DRM_PANEL) += drm_panel.o
drm-$(CONFIG_OF) += drm_of.o
drm-$(CONFIG_AGP) += drm_agpsupport.o
+drm-$(CONFIG_DEBUG_FS) += drm_debugfs.o drm_debugfs_crc.o
drm_kms_helper-y := drm_crtc_helper.o drm_dp_helper.o drm_probe_helper.o \
drm_plane_helper.o drm_dp_mst_topology.o drm_atomic_helper.o \
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 7f2510524f09..17cc6891dfbb 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -40,7 +40,7 @@
#include
#include
#include
-#include
+#include
#include "drm_crtc_internal.h"
#include "drm_internal.h"
@@ -309,6 +309,25 @@ static void drm_crtc_unregister_all(struct drm_device *dev)
}
}
+static int drm_crtc_crc_init(struct drm_crtc *crtc)
+{
+#ifdef CONFIG_DEBUG_FS
+ spin_lock_init(&crtc->crc.lock);
+ init_waitqueue_head(&crtc->crc.wq);
+ crtc->crc.source = kstrdup("auto", GFP_KERNEL);
+ if (!crtc->crc.source)
+ return -ENOMEM;
+#endif
+ return 0;
+}
+
+static void drm_crtc_crc_fini(struct drm_crtc *crtc)
+{
+#ifdef CONFIG_DEBUG_FS
+ kfree(crtc->crc.source);
+#endif
+}
+
/**
* drm_crtc_init_with_planes - Initialise a new CRTC object with
*specified primary and cursor planes.
@@ -374,6 +393,12 @@ int drm_crtc_init_with_planes(struct drm_device *dev,
struct drm_crtc *crtc,
if (cursor)
cursor->possible_crtcs = 1 << drm_crtc_index(crtc);
+ ret = drm_crtc_crc_init(crtc);
+ if (ret) {
+ drm_mode_object_unregister(d
[PATCH v5 3/4] drm/i915: Use new CRC debugfs API
The core provides now an ABI to userspace for generation of frame CRCs,
so implement the ->set_crc_source() callback and reuse as much code as
possible with the previous ABI implementation.
v2:
- Leave the legacy implementation in place as the ABI implementation
in the core is incompatible with it.
v3:
- Use the "cooked" vblank counter so we have a whole 32 bits.
- Make sure we don't mess with the state of the legacy CRC capture
ABI implementation.
v4:
- Keep use of get_vblank_counter as in the legacy code, will be
changed in a followup commit.
v5:
- Skip first frame or two as it's known that they contain wrong
data.
- A few fixes suggested by Emil Velikov.
Signed-off-by: Tomeu Vizoso
---
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/i915_irq.c | 83 +++---
drivers/gpu/drm/i915/intel_display.c | 1 +
drivers/gpu/drm/i915/intel_drv.h | 2 +
drivers/gpu/drm/i915/intel_pipe_crc.c | 130 --
5 files changed, 153 insertions(+), 64 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 403c074a29f4..77d05807adc6 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1672,6 +1672,7 @@ struct intel_pipe_crc {
enum intel_pipe_crc_source source;
int head, tail;
wait_queue_head_t wq;
+ int skipped;
};
struct i915_frontbuffer_tracking {
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 7610eca4f687..413667497ce0 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -1485,41 +1485,72 @@ static void display_pipe_crc_irq_handler(struct
drm_i915_private *dev_priv,
{
struct intel_pipe_crc *pipe_crc = &dev_priv->pipe_crc[pipe];
struct intel_pipe_crc_entry *entry;
- int head, tail;
+ struct drm_crtc *crtc = intel_get_crtc_for_pipe(&dev_priv->drm, pipe);
+ struct drm_driver *driver = dev_priv->drm.driver;
+ uint32_t crcs[5];
+ int head, tail, ret;
+ u32 frame;
spin_lock(&pipe_crc->lock);
+ if (pipe_crc->source) {
+ if (!pipe_crc->entries) {
+ spin_unlock(&pipe_crc->lock);
+ DRM_DEBUG_KMS("spurious interrupt\n");
+ return;
+ }
- if (!pipe_crc->entries) {
- spin_unlock(&pipe_crc->lock);
- DRM_DEBUG_KMS("spurious interrupt\n");
- return;
- }
-
- head = pipe_crc->head;
- tail = pipe_crc->tail;
+ head = pipe_crc->head;
+ tail = pipe_crc->tail;
- if (CIRC_SPACE(head, tail, INTEL_PIPE_CRC_ENTRIES_NR) < 1) {
- spin_unlock(&pipe_crc->lock);
- DRM_ERROR("CRC buffer overflowing\n");
- return;
- }
+ if (CIRC_SPACE(head, tail, INTEL_PIPE_CRC_ENTRIES_NR) < 1) {
+ spin_unlock(&pipe_crc->lock);
+ DRM_ERROR("CRC buffer overflowing\n");
+ return;
+ }
- entry = &pipe_crc->entries[head];
+ entry = &pipe_crc->entries[head];
- entry->frame = dev_priv->drm.driver->get_vblank_counter(&dev_priv->drm,
-pipe);
- entry->crc[0] = crc0;
- entry->crc[1] = crc1;
- entry->crc[2] = crc2;
- entry->crc[3] = crc3;
- entry->crc[4] = crc4;
+ entry->frame = driver->get_vblank_counter(&dev_priv->drm, pipe);
+ entry->crc[0] = crc0;
+ entry->crc[1] = crc1;
+ entry->crc[2] = crc2;
+ entry->crc[3] = crc3;
+ entry->crc[4] = crc4;
- head = (head + 1) & (INTEL_PIPE_CRC_ENTRIES_NR - 1);
- pipe_crc->head = head;
+ head = (head + 1) & (INTEL_PIPE_CRC_ENTRIES_NR - 1);
+ pipe_crc->head = head;
- spin_unlock(&pipe_crc->lock);
+ spin_unlock(&pipe_crc->lock);
- wake_up_interruptible(&pipe_crc->wq);
+ wake_up_interruptible(&pipe_crc->wq);
+ } else {
+ /*
+* For some not yet identified reason, the first CRC is
+* bonkers. So let's just wait for the next vblank and read
+* out the buggy result.
+*
+* On CHV sometimes the second CRC is bonkers as well, so
+* don't trust that one either.
+*/
+ if (pipe_crc->skipped == 0 ||
+ (IS_CHERRYVIEW(dev_priv) && pipe_crc->skipped == 1)) {
+ pipe_crc->skipped++;
+ spin_unlock(&pipe_crc->lock);
+ return;
+ }
+ spin_unlock(&pipe_crc->lock);
+ spin_lock(&crtc->crc.lock);
+ crc
[PATCH v5 4/4] drm/i915: Put "cooked" vlank counters in frame CRC lines
Use drm_accurate_vblank_count so we have the full 32 bit to represent
the frame counter and userspace has a simpler way of knowing when the
counter wraps around.
Signed-off-by: Tomeu Vizoso
---
drivers/gpu/drm/i915/i915_irq.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 413667497ce0..32a5f4634d6d 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -1489,7 +1489,6 @@ static void display_pipe_crc_irq_handler(struct
drm_i915_private *dev_priv,
struct drm_driver *driver = dev_priv->drm.driver;
uint32_t crcs[5];
int head, tail, ret;
- u32 frame;
spin_lock(&pipe_crc->lock);
if (pipe_crc->source) {
@@ -1545,8 +1544,9 @@ static void display_pipe_crc_irq_handler(struct
drm_i915_private *dev_priv,
crcs[2] = crc2;
crcs[3] = crc3;
crcs[4] = crc4;
- frame = driver->get_vblank_counter(&dev_priv->drm, pipe);
- ret = drm_crtc_add_crc_entry(crtc, true, frame, crcs);
+ ret = drm_crtc_add_crc_entry(crtc, true,
+drm_accurate_vblank_count(crtc),
+crcs);
spin_unlock(&crtc->crc.lock);
if (!ret)
wake_up_interruptible(&crtc->crc.wq);
--
2.7.4
[Bug 97166] lockup during gameplay of Batman series of games
https://bugs.freedesktop.org/show_bug.cgi?id=97166 Vedran MiletiÄ changed: What|Removed |Added Attachment #125998|text/x-log |text/plain mime type|| -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160905/ef0b5b82/attachment.html>
[PATCH v5 4/7] video: add generic framebuffer eviction
Hi
On Sat, Sep 3, 2016 at 2:06 PM, Noralf Trønnes wrote:
>
> Den 02.09.2016 10:22, skrev David Herrmann:
>>
>> There are several situations where we want hardware handover from an early
>> boot GFX driver (e.g., vgacon, vesafb, efifb, simplefb) to a full fletched
>> GFX driver (e.g., most DRM drivers). So far, we relied on
>> remove_conflicting_framebuffers() to do this for us, however, this had a
>> bunch of downsides:
>>
>>o It only removes conflicting fbdev drivers. It does not drop vgacon,
>> early boot console drivers, conflicting DRM drivers, etc.
>>
>>o It only unloads the fbdev driver, it does not modify the underlying
>> device or resources. In case of "screen_info" drivers (e.g., efifb)
>> this is fine, since no resources are pinned. However, if the driver
>> binds to a platform-device like "simple-framebuffer", we must make
>> sure to unregister that device as well. Otherwise, pinned resources
>> like IORESOURCE_MEM stay around, triggering WARN_ONs if the following
>> driver requests those resources.
>>
>>o It is only available if CONFIG_FB is selected.
>>
>> This commit adds a new infrastructure that manages system-framebuffers
>> (short: sysfb). The initial commit provides conflict-resolution for
>> system-framebuffers. At its core it provides sysfb_evict_conflicts(),
>> which implements conflict detection and removal for all known types of
>> GFX driver hand-overs. So far, this includes platform-device removal,
>> fbdev-firmware-device removal, vgacon removal and VBE detection. To
>> further simplify the callers, it also provides helpers to figure out what
>> hand-over to do, based on the device the new drivers binds to:
>>
>>o PCI drivers can use sysfb_evict_conflicts_pci(), which will figure
>> out
>> the apertures automatically, and does VGA/VBE detection.
>>
>>o Generic firmware drivers that might be shadowed at any address in
>> memory can use sysfb_evict_conflicts_firmware(), basically removing
>> *all* firmware framebuffers in effect.
>>
>> This only adds the generic sysfb helpers. No users are converted, yet.
>>
>> Signed-off-by: David Herrmann
>> ---
>> drivers/video/Kconfig | 4 +
>> drivers/video/Makefile | 1 +
>> drivers/video/sysfb.c | 327
>> +
>> include/linux/sysfb.h | 34 +
>> 4 files changed, 366 insertions(+)
>> create mode 100644 drivers/video/sysfb.c
>> create mode 100644 include/linux/sysfb.h
>>
>> diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
>> index 3c20af9..56a8294 100644
>> --- a/drivers/video/Kconfig
>> +++ b/drivers/video/Kconfig
>> @@ -36,6 +36,10 @@ config VIDEOMODE_HELPERS
>> config HDMI
>> bool
>> +config SYSFB
>> + bool
>> + select DUMMY_CONSOLE if VT
>> +
>> if VT
>> source "drivers/video/console/Kconfig"
>> endif
>> diff --git a/drivers/video/Makefile b/drivers/video/Makefile
>> index 9ad3c17..df7bd75 100644
>> --- a/drivers/video/Makefile
>> +++ b/drivers/video/Makefile
>> @@ -1,5 +1,6 @@
>> obj-$(CONFIG_VGASTATE)+= vgastate.o
>> obj-$(CONFIG_HDMI)+= hdmi.o
>> +obj-$(CONFIG_SYSFB) += sysfb.o
>> obj-$(CONFIG_VT) += console/
>> obj-$(CONFIG_LOGO) += logo/
>> diff --git a/drivers/video/sysfb.c b/drivers/video/sysfb.c
>> new file mode 100644
>> index 000..00585c9
>> --- /dev/null
>> +++ b/drivers/video/sysfb.c
>> @@ -0,0 +1,327 @@
>> +/*
>> + * Copyright (C) 2013-2016 Red Hat, Inc.
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> it
>> + * under the terms of the GNU Lesser General Public License as published
>> by the
>> + * Free Software Foundation; either version 2.1 of the License, or (at
>> your
>> + * option) any later version.
>> + */
>> +
>> +#define pr_fmt(fmt) "sysfb: " fmt
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +
>> +static bool sysfb_evict_match_resource(struct sysfb_evict_ctx *ctx,
>> + struct resource *mem)
>> +{
>> + struct aperture *g;
>> + unsigned int i;
>> +
>> + for (i = 0; i < ctx->ap->count; ++i) {
>> + g = &ctx->ap->ranges[i];
>> +
>> + if (mem->start == g->base)
>> + return true;
>> + if (mem->start >= g->base && mem->end < g->base + g->size)
>> + return true;
>> + if ((ctx->flags & SYSFB_EVICT_VBE) && mem->start ==
>> 0xA)
>> + return true;
>> + }
>> +
>> + return false;
>> +}
>> +
>> +static int sysfb_evict_platform_device(struct device *dev, void
>> *userdata)
>> +{
>> + struct sysfb_evict_ctx *ctx = userdata;
>> + struct platform_device *pdev = to_platform_device(dev);
[PATCH v5 7/7] drm/simpledrm: add fbdev fallback support
Hi
On Sat, Sep 3, 2016 at 7:15 PM, Noralf Trønnes wrote:
>
> Den 03.09.2016 14:04, skrev Noralf Trønnes:
>>
>>
>> Den 02.09.2016 10:22, skrev David Herrmann:
>>>
>>> Create a simple fbdev device during SimpleDRM setup so legacy user-space
>>> and fbcon can use it.
>>>
>>> Signed-off-by: David Herrmann
>>
>>
>> [...]
>>
>>> diff --git a/drivers/gpu/drm/simpledrm/simpledrm_fbdev.c
>>> b/drivers/gpu/drm/simpledrm/simpledrm_fbdev.c
>>
>>
>> [...]
>>
>>> +void sdrm_fbdev_bind(struct sdrm_device *sdrm)
>>> +{
>>> +struct drm_fb_helper *fbdev;
>>> +int r;
>>> +
>>> +fbdev = kzalloc(sizeof(*fbdev), GFP_KERNEL);
>>> +if (!fbdev)
>>> +return;
>>> +
>>> +drm_fb_helper_prepare(sdrm->ddev, fbdev, &sdrm_fbdev_funcs);
>>> +
>>> +r = drm_fb_helper_init(sdrm->ddev, fbdev, 1, 1);
>>> +if (r < 0)
>>> +goto error;
>>> +
>>> +r = drm_fb_helper_single_add_all_connectors(fbdev);
>>> +if (r < 0)
>>> +goto error;
>>> +
>>> +r = drm_fb_helper_initial_config(fbdev,
>>> +sdrm->ddev->mode_config.preferred_depth);
>>> +if (r < 0)
>>> +goto error;
>>> +
>>> +if (!fbdev->fbdev)
>>> +goto error;
>>> +
>>> +sdrm->fbdev = fbdev;
>>> +return;
>>> +
>>> +error:
>>> +drm_fb_helper_fini(fbdev);
>>> +kfree(fbdev);
>>> +}
>>> +
>>> +void sdrm_fbdev_unbind(struct sdrm_device *sdrm)
>>> +{
>>> +struct drm_fb_helper *fbdev = sdrm->fbdev;
>>> +
>>> +if (!fbdev)
>>> +return;
>>> +
>>> +sdrm->fbdev = NULL;
>>> +drm_fb_helper_unregister_fbi(fbdev);
>>> +cancel_work_sync(&fbdev->dirty_work);
>>> +drm_fb_helper_release_fbi(fbdev);
>>> +drm_framebuffer_unreference(fbdev->fb);
>>
>>
>> I get a warning that there are still fb's left during unbind:
>>
>> [ 48.666003] WARNING: CPU: 0 PID: 716 at drivers/gpu/drm/drm_crtc.c:3855
>> drm_mode_config_cleanup+0x180/0x1f4 [drm]
>>
>> This worked:
>>
>> - drm_framebuffer_unreference(fbdev->fb);
>> + drm_framebuffer_unregister_private(fbdev->fb);
>> + drm_framebuffer_cleanup(fbdev->fb);
>>
>
> Well not quite, this doesn't free the bo, so maybe this:
>
> - drm_framebuffer_unreference(fbdev->fb);
> + drm_framebuffer_unregister_private(fbdev->fb);
> + sdrm_fb_destroy(fbdev->fb);
>
> IIRC the reason ref count doesn't drop to zero, had something to do with
> multiple
> fb_set_par calls taking reference but not being dropped later.
So I don't like this at all. If we leak references, we should fix the
ref-leak or properly document why this is fine to do. Daniel, what is
the exact reason we have unregister_private()? Maybe I should try and
trace the ref-leak.
Thanks
David
[PATCH v4 3/4] drm/i915: Use new CRC debugfs API
On 5 September 2016 at 10:45, Tomeu Vizoso
wrote:
> On 2 September 2016 at 17:18, Emil Velikov
> wrote:
>> Hi Tomeu,
>>
>> IMHO it would be better to split out the refactoring into preparatory
>> patch. It brings a minor change which (not 100% sure on that) should
>> not cause issues but is worth pointing out.
>
> I think at this point it would make sense to change the series
> structure only if there was a strong reason, as a few people have
> already looked at the patches already.
>
>> On 5 August 2016 at 11:45, Tomeu Vizoso
>> wrote:
>>
>>> +static int do_set_crc_source(struct drm_device *dev, enum pipe pipe,
>>> +enum intel_pipe_crc_source source)
>>> +{
>>
>>> + if (source == INTEL_PIPE_CRC_SOURCE_NONE) {
>> Nit: use !source here or sourse != INTEL_PIPE_CRC_SOURCE_NONE
>> elsewhere in the code ?
>
> Agreed.
>
>>
>>> @@ -693,10 +718,11 @@ static int pipe_crc_set_source(struct drm_device
>>> *dev, enum pipe pipe,
>>> spin_unlock_irq(&pipe_crc->lock);
>>> }
>>>
>>> - pipe_crc->source = source;
>>> + ret = do_set_crc_source(dev, pipe, source);
>>> + if (ret)
>>> + goto out;
>>>
>> We seem to have modified pipe_crc even if the new function fails.
>> Haven't check if it matters, but definatelly not ideal.
>
> If we had modified pipe_crc that's because we were trying to start CRC
> capture and we initialized the entry storage. As CRC generation is
> disabled, those changes have no effects. When CRC capture is attempted
> again, they will be initialized again.
>
> To avoid this we would need to split the HW programming in two
> functions and I'm not sure it would be worth it.
>
A simple way out will be to keep the "can fail" hunk at the top
separate from the rest. This way even if things get reinitialised
correctly currently, they won't break if someone applies the
(perfectly reasonable imho) assumption "function does not modify any
data when it fails".
>>> @@ -720,15 +746,6 @@ static int pipe_crc_set_source(struct drm_device *dev,
>>> enum pipe pipe,
>>> spin_unlock_irq(&pipe_crc->lock);
>>>
>>> kfree(entries);
>>> -
>>> - if (IS_G4X(dev))
>>> - g4x_undo_pipe_scramble_reset(dev, pipe);
>>> - else if (IS_VALLEYVIEW(dev) || IS_CHERRYVIEW(dev))
>>> - vlv_undo_pipe_scramble_reset(dev, pipe);
>>> - else if (IS_HASWELL(dev) && pipe == PIPE_A)
>>> - hsw_trans_edp_pipe_A_crc_wa(dev, false);
>>> -
>>> - hsw_enable_ips(crtc);
>> The above is the piece I have in mind:
>> With the introduction of do_set_crc_source() the above are executed
>> prior to the intel_wait_for_vblank() call.
>>
>> Afaics this will not cause any functional change, then again I'm not
>> that familiar with the i915 vblank code.
>
> Yeah, not sure either of when do those changes take effect.
>
With this said, it would be way better to keep it separate (with a big
fat warning in the commit summary).
Speaking of which - why did you fold the separate bugfix/workaround
"skip the first one or two frames" in v5 ? Shouldn't it be separate so
that people can pick it for -fixes/-stable ?
Thanks
Emil
[PATCH 0/4] Backported vlv fixes for 4.7.y
On Mon, Aug 29, 2016 at 05:27:38PM -0400, Lyude Paul wrote: > drm/i915/vlv: Make intel_crt_reset() per-encoder: > 4570d833390b10043d082fe535375d4a0e071d9c > drm/i915/vlv: Reset the ADPA in vlv_display_power_well_init(): > 4c732e6ee9e71903934d75b12a021eb3520b6197 > drm/i915/vlv: Disable HPD in valleyview_crt_detect_hotplug(): > 21842ea84f161ae37ba25f0250c377fd19c5b307 > drm/i915: Enable polling when we don't have hpd: > 84c8e0963da434d37355079b568465cd121af295 Thanks for these, all now applied. greg k-h
[Intel-gfx] [PATCH v4 3/4] drm/i915: Use new CRC debugfs API
On 5 September 2016 at 14:44, Emil Velikov wrote:
> On 5 September 2016 at 10:45, Tomeu Vizoso
> wrote:
>> On 2 September 2016 at 17:18, Emil Velikov
>> wrote:
>>> Hi Tomeu,
>>>
>>> IMHO it would be better to split out the refactoring into preparatory
>>> patch. It brings a minor change which (not 100% sure on that) should
>>> not cause issues but is worth pointing out.
>>
>> I think at this point it would make sense to change the series
>> structure only if there was a strong reason, as a few people have
>> already looked at the patches already.
>>
>>> On 5 August 2016 at 11:45, Tomeu Vizoso
>>> wrote:
>>>
+static int do_set_crc_source(struct drm_device *dev, enum pipe pipe,
+enum intel_pipe_crc_source source)
+{
>>>
+ if (source == INTEL_PIPE_CRC_SOURCE_NONE) {
>>> Nit: use !source here or sourse != INTEL_PIPE_CRC_SOURCE_NONE
>>> elsewhere in the code ?
>>
>> Agreed.
>>
>>>
@@ -693,10 +718,11 @@ static int pipe_crc_set_source(struct drm_device
*dev, enum pipe pipe,
spin_unlock_irq(&pipe_crc->lock);
}
- pipe_crc->source = source;
+ ret = do_set_crc_source(dev, pipe, source);
+ if (ret)
+ goto out;
>>> We seem to have modified pipe_crc even if the new function fails.
>>> Haven't check if it matters, but definatelly not ideal.
>>
>> If we had modified pipe_crc that's because we were trying to start CRC
>> capture and we initialized the entry storage. As CRC generation is
>> disabled, those changes have no effects. When CRC capture is attempted
>> again, they will be initialized again.
>>
>> To avoid this we would need to split the HW programming in two
>> functions and I'm not sure it would be worth it.
>>
> A simple way out will be to keep the "can fail" hunk at the top
> separate from the rest. This way even if things get reinitialised
> correctly currently, they won't break if someone applies the
> (perfectly reasonable imho) assumption "function does not modify any
> data when it fails".
>
>
@@ -720,15 +746,6 @@ static int pipe_crc_set_source(struct drm_device
*dev, enum pipe pipe,
spin_unlock_irq(&pipe_crc->lock);
kfree(entries);
-
- if (IS_G4X(dev))
- g4x_undo_pipe_scramble_reset(dev, pipe);
- else if (IS_VALLEYVIEW(dev) || IS_CHERRYVIEW(dev))
- vlv_undo_pipe_scramble_reset(dev, pipe);
- else if (IS_HASWELL(dev) && pipe == PIPE_A)
- hsw_trans_edp_pipe_A_crc_wa(dev, false);
-
- hsw_enable_ips(crtc);
>>> The above is the piece I have in mind:
>>> With the introduction of do_set_crc_source() the above are executed
>>> prior to the intel_wait_for_vblank() call.
>>>
>>> Afaics this will not cause any functional change, then again I'm not
>>> that familiar with the i915 vblank code.
>>
>> Yeah, not sure either of when do those changes take effect.
>>
> With this said, it would be way better to keep it separate (with a big
> fat warning in the commit summary).
>
> Speaking of which - why did you fold the separate bugfix/workaround
> "skip the first one or two frames" in v5 ? Shouldn't it be separate so
> that people can pick it for -fixes/-stable ?
Oh, that's only in the new code paths. For the old i915 ABI, the
frames are skipped in userspace, but as it's something highly
HW-dependent, implementors of the new API need to do it within their
drivers.
Regards,
Tomeu
[PATCH 0/6] drm/i915: Enable preliminary support for nonblocking modeset.:
From: Maarten Lankhorst This is still broken on SKL. IGT detects that nonblocking modesetting is supported by a check that does a nonblocking modeset followed by a synchronous commit. The nonblocking modeset works, but the synchronous commit immediately after to serialize the state fails on invalid watermark values. kms_atomic_transition nonblocking modeset tests pass on my BDW NUC. Maarten Lankhorst (6): drm/i915: Convert intel_hdmi to use atomic state drm/i915: Pass atomic state to intel_audio_codec_enable drm/edid: Remove drm_select_eld drm/i915: Update atomic modeset state synchronously drm/i915: Pass atomic state to verify_connector_state drm/i915: Enable support for nonblocking modeset drivers/gpu/drm/drm_edid.c | 26 --- drivers/gpu/drm/i915/intel_audio.c | 15 ++- drivers/gpu/drm/i915/intel_ddi.c | 2 +- drivers/gpu/drm/i915/intel_display.c | 47 - drivers/gpu/drm/i915/intel_dp.c | 11 drivers/gpu/drm/i915/intel_drv.h | 4 ++- drivers/gpu/drm/i915/intel_hdmi.c| 50 include/drm/drm_edid.h | 1 - 8 files changed, 63 insertions(+), 93 deletions(-) -- 2.7.4
drm timing problems in sama5d3 Xplained.
Hi Alex, On Mon, 5 Sep 2016 11:04:51 +0200 Alex Vazquez wrote: > Hi All. > I am using DRM in a sama5d3 Xplained with display TM43 and I've found with > the following problem: > I deleted the network interfaces in the device tree for my system to boot > faster. My problem is that now the startup script run before the driver has > loaded correctly. > I explain better: > The startup script begin to appear before the creation of the framebuffer > message appears. (See LogKernel.txt) > > atmel-hlcdc-display-controller atmel-hlcdc-dc: fb0: frame buffer device > > > 1 - I can't use the framebuffer until the message is not displayed. (This > did not matter. I want to use drm.) > 2 - DRM don't work fine. If I try to paint on the screen (using planes) > before the message it is created framebuffer appears, nothing appears on > the display. > > This problem I can replicate with the demo atmel if I remove network > interfaces in the device tree and adding a startup script that uses drm. > > I add the demo with the modified device tree so you can prove that occurs. > > https://drive.google.com/file/d/0B3EMwEbIHhkAbDhGMU1BcEVoYkU/view?usp=sharing > > You only need to add the startup script in /etc/rcS.d/ > > #!/bin/sh > > modetest -M atmel-hlcdc -P 26:480x272+0+0 at AR15 > > > I also tested with the latest version of kernel 4.8 RC3 and the problem is > still happening. It seems that the atmel-hlcdc DRM device probe is deferred because some elements in the display pipeline are missing (the display itself, the backlight attached to the display, or even the PWM attached to the backlight). Can you check if the /dev/dri/xxx files are present when you reach your init script? If that's not the case, can you make sure you compiled the different drivers needed for the display pipeline to work correctly statically? Thanks, Boris
[PATCH libdrm] configure.ac: Allow explicit enabling of cunit tests
Add --with-cunit to make it easier to do reproducible builds. Default is still to probe cunit and build opportunistically. Signed-off-by: Jussi Kukkonen --- configure.ac | 14 -- 1 file changed, 12 insertions(+), 2 deletions(-) diff --git a/configure.ac b/configure.ac index e3048c7..918d21d 100644 --- a/configure.ac +++ b/configure.ac @@ -137,6 +137,12 @@ AC_ARG_ENABLE(install-test-programs, [Install test programs (default: no)]), [INSTALL_TESTS=$enableval], [INSTALL_TESTS=no]) +AC_ARG_WITH([cunit], +[AS_HELP_STRING([--with-cunit], +[Build tests that use cunit (default: auto)])], +[], +[with_cunit=auto]) + dnl === dnl check compiler flags AC_DEFUN([LIBDRM_CC_TRY_FLAG], [ @@ -372,7 +378,7 @@ if test "x$RADEON" = xyes; then AC_DEFINE(HAVE_RADEON, 1, [Have radeon support]) fi -if test "x$AMDGPU" != xno; then +if test "x$with_cunit" != xno -a "x$AMDGPU" != xno; then # Detect cunit library PKG_CHECK_MODULES([CUNIT], [cunit >= 2.1], [have_cunit=yes], [have_cunit=no]) # If pkg-config does not find cunit, check it using AC_CHECK_LIB. We @@ -399,7 +406,11 @@ if test "x$AMDGPU" = xyes; then AC_DEFINE(HAVE_CUNIT, [test "x$have_cunit" != "xno"], [Enable CUNIT Have amdgpu support]) if test "x$have_cunit" = "xno"; then - AC_MSG_WARN([Could not find cunit library. Disabling amdgpu tests]) + if test "x$with_cunit" = "xyes"; then + AC_MSG_ERROR([Could not find cunit library but --with-cunit was given]) + elif test "x$with_cunit" = "xauto"; then + AC_MSG_WARN([Could not find cunit library. Disabling amdgpu tests]) + fi fi fi -- 2.1.4
[PATCH 5/6] ARM: dts: Add NextThing GR8 dtsi
On Wed, Aug 31, 2016 at 4:18 PM, Maxime Ripard
wrote:
> From: Mylène Josserand
>
> The GR8 is an SoC made by Nextthing loosely based on the sun5i family.
>
> Since it's not clear yet what we can factor out and merge with the A10s and
> A13 support, let's keep it out of the sun5i.dtsi include tree. We will
> figure out what can be shared when things settle down.
>
> Signed-off-by: Mylène Josserand
> Signed-off-by: Maxime Ripard
> ---
> arch/arm/boot/dts/gr8.dtsi | 1080
>
> 1 file changed, 1080 insertions(+)
> create mode 100644 arch/arm/boot/dts/gr8.dtsi
>
> diff --git a/arch/arm/boot/dts/gr8.dtsi b/arch/arm/boot/dts/gr8.dtsi
> new file mode 100644
> index ..d21cfa3f3c14
> --- /dev/null
> +++ b/arch/arm/boot/dts/gr8.dtsi
> @@ -0,0 +1,1080 @@
> +/*
> + * Copyright 2016 Mylène Josserand
> + *
> + * Mylène Josserand
> + *
> + * This file is dual-licensed: you can use it either under the terms
> + * of the GPL or the X11 license, at your option. Note that this dual
> + * licensing only applies to this file, and not this project as a
> + * whole.
> + *
> + * a) This library is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License as
> + * published by the Free Software Foundation; either version 2 of the
> + * License, or (at your option) any later version.
> + *
> + * This library is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + * Or, alternatively,
> + *
> + * b) Permission is hereby granted, free of charge, to any person
> + * obtaining a copy of this software and associated documentation
> + * files (the "Software"), to deal in the Software without
> + * restriction, including without limitation the rights to use,
> + * copy, modify, merge, publish, distribute, sublicense, and/or
> + * sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following
> + * conditions:
> + *
> + * The above copyright notice and this permission notice shall be
> + * included in all copies or substantial portions of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
> + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
> + * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
> + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
> + * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
> + * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> + * OTHER DEALINGS IN THE SOFTWARE.
> + */
> +
> +#include "skeleton.dtsi"
> +
> +#include
> +#include
> +#include
> +
> +/ {
> + interrupt-parent = <&intc>;
> +
> + cpus {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + cpu0: cpu at 0 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a8";
> + reg = <0x0>;
> + clocks = <&cpu>;
> + };
> + };
> +
> + clocks {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges;
> +
> + /*
> +* This is a dummy clock, to be used as placeholder on
> +* other mux clocks when a specific parent clock is not
> +* yet implemented. It should be dropped when the driver
> +* is complete.
> +*/
> + dummy: dummy {
> + #clock-cells = <0>;
> + compatible = "fixed-clock";
> + clock-frequency = <0>;
> + };
> +
> + osc24M: clk at 01c20050 {
> + #clock-cells = <0>;
> + compatible = "allwinner,sun4i-a10-osc-clk";
> + reg = <0x01c20050 0x4>;
> + clock-frequency = <2400>;
> + clock-output-names = "osc24M";
> + };
> +
> + osc3M: osc3M_clk {
> + compatible = "fixed-factor-clock";
> + #clock-cells = <0>;
> + clock-div = <8>;
> + clock-mult = <1>;
> + clocks = <&osc24M>;
> + clock-output-names = "osc3M";
> + };
> +
> + osc32k: clk at 0 {
> + #clock-cells = <0>;
> + compatible = "fixed-clock";
> + clock-frequency = <32768>;
> + clock-outpu
[PATCH v9 02/19] MAINTAINERS: Add st slim core rproc driver to STi section.
This patch adds the slim core rproc driver to the STi section of the MAINTAINERS file. Signed-off-by: Peter Griffin Acked-by: Lee Jones --- MAINTAINERS | 2 ++ 1 file changed, 2 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 0bbe4b1..5dd3b24 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -1749,6 +1749,7 @@ F:drivers/phy/phy-stih407-usb.c F: drivers/phy/phy-stih41x-usb.c F: drivers/pinctrl/pinctrl-st.c F: drivers/remoteproc/st_remoteproc.c +F: drivers/remoteproc/st_slim_rproc.c F: drivers/reset/sti/ F: drivers/rtc/rtc-st-lpc.c F: drivers/tty/serial/st-asc.c @@ -1757,6 +1758,7 @@ F:drivers/usb/host/ehci-st.c F: drivers/usb/host/ohci-st.c F: drivers/watchdog/st_lpc_wdt.c F: drivers/ata/ahci_st.c +F: include/linux/remoteproc/st_slim_rproc.h ARM/STM32 ARCHITECTURE M: Maxime Coquelin -- 1.9.1
[PATCH v9 05/19] dmaengine: st_fdma: Add STMicroelectronics FDMA engine driver support
This patch adds support for the Flexible Direct Memory Access (FDMA) core
driver. The FDMA is a slim core CPU with a dedicated firmware.
It is a general purpose DMA controller capable of supporting 16
independent DMA channels. Data moves maybe from memory to memory
or between memory and paced latency critical real time targets and it
is found on al STi based chipsets.
Signed-off-by: Ludovic Barre
Signed-off-by: Peter Griffin
---
drivers/dma/Kconfig | 15 +-
drivers/dma/Makefile | 1 +
drivers/dma/st_fdma.c | 899 ++
3 files changed, 914 insertions(+), 1 deletion(-)
create mode 100644 drivers/dma/st_fdma.c
diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
index 739f797..7c5d946 100644
--- a/drivers/dma/Kconfig
+++ b/drivers/dma/Kconfig
@@ -437,6 +437,19 @@ config STE_DMA40
help
Support for ST-Ericsson DMA40 controller
+config ST_FDMA
+ tristate "ST FDMA dmaengine support"
+ depends on ARCH_STI
+ select ST_SLIM_REMOTEPROC
+ select DMA_ENGINE
+ select DMA_VIRTUAL_CHANNELS
+ help
+ Enable support for ST FDMA controller.
+ It supports 16 independent DMA channels, accepts up to 32 DMA requests
+
+ Say Y here if you have such a chipset.
+ If unsure, say N.
+
config STM32_DMA
bool "STMicroelectronics STM32 DMA support"
depends on ARCH_STM32
@@ -449,6 +462,7 @@ config STM32_DMA
If you have a board based on such a MCU and wish to use DMA say Y or M
here.
+
config S3C24XX_DMAC
bool "Samsung S3C24XX DMA support"
depends on ARCH_S3C24XX
@@ -567,7 +581,6 @@ config ZX_DMA
help
Support the DMA engine for ZTE ZX296702 platform devices.
-
# driver files
source "drivers/dma/bestcomm/Kconfig"
diff --git a/drivers/dma/Makefile b/drivers/dma/Makefile
index e4dc9ca..a4fa336 100644
--- a/drivers/dma/Makefile
+++ b/drivers/dma/Makefile
@@ -67,6 +67,7 @@ obj-$(CONFIG_TI_DMA_CROSSBAR) += ti-dma-crossbar.o
obj-$(CONFIG_TI_EDMA) += edma.o
obj-$(CONFIG_XGENE_DMA) += xgene-dma.o
obj-$(CONFIG_ZX_DMA) += zx296702_dma.o
+obj-$(CONFIG_ST_FDMA) += st_fdma.o
obj-y += qcom/
obj-y += xilinx/
diff --git a/drivers/dma/st_fdma.c b/drivers/dma/st_fdma.c
new file mode 100644
index 000..515e1d4
--- /dev/null
+++ b/drivers/dma/st_fdma.c
@@ -0,0 +1,899 @@
+/*
+ * DMA driver for STMicroelectronics STi FDMA controller
+ *
+ * Copyright (C) 2014 STMicroelectronics
+ *
+ * Author: Ludovic Barre
+ *Peter Griffin
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "st_fdma.h"
+
+static inline struct st_fdma_chan *to_st_fdma_chan(struct dma_chan *c)
+{
+ return container_of(c, struct st_fdma_chan, vchan.chan);
+}
+
+static struct st_fdma_desc *to_st_fdma_desc(struct virt_dma_desc *vd)
+{
+ return container_of(vd, struct st_fdma_desc, vdesc);
+}
+
+static int st_fdma_dreq_get(struct st_fdma_chan *fchan)
+{
+ struct st_fdma_dev *fdev = fchan->fdev;
+ u32 req_line_cfg = fchan->cfg.req_line;
+ u32 dreq_line;
+ int try = 0;
+
+ /*
+* dreq_mask is shared for n channels of fdma, so all accesses must be
+* atomic. if the dreq_mask is changed between ffz and set_bit,
+* we retry
+*/
+ do {
+ if (fdev->dreq_mask == ~0L) {
+ dev_err(fdev->dev, "No req lines available\n");
+ return -EINVAL;
+ }
+
+ if (try || req_line_cfg >= ST_FDMA_NR_DREQS) {
+ dev_err(fdev->dev, "Invalid or used req line\n");
+ return -EINVAL;
+ } else {
+ dreq_line = req_line_cfg;
+ }
+
+ try++;
+ } while (test_and_set_bit(dreq_line, &fdev->dreq_mask));
+
+ dev_dbg(fdev->dev, "get dreq_line:%d mask:%#lx\n",
+ dreq_line, fdev->dreq_mask);
+
+ return dreq_line;
+}
+
+static void st_fdma_dreq_put(struct st_fdma_chan *fchan)
+{
+ struct st_fdma_dev *fdev = fchan->fdev;
+
+ dev_dbg(fdev->dev, "put dreq_line:%#x\n", fchan->dreq_line);
+ clear_bit(fchan->dreq_line, &fdev->dreq_mask);
+}
+
+static void st_fdma_xfer_desc(struct st_fdma_chan *fchan)
+{
+ struct virt_dma_desc *vdesc;
+ unsigned long nbytes, ch_cmd, cmd;
+
+ vdesc = vchan_next_desc(&fchan->vchan);
+ if (!vdesc)
+ return;
+
+ fchan->fdesc = to_st_fdma_desc(vdesc);
+ nbytes = fchan->fdesc->node[0].desc->nbytes;
+ cmd = FDMA_CMD_START(fchan->vchan.chan.chan_id);
+ ch_cmd = fchan->fdesc->node[0].pdesc | FDMA_CH_CMD_STA_START;
+
[PATCH v9 06/19] ARM: STi: DT: STiH407: Add FDMA driver dt nodes.
These nodes are required to get the fdma driver working
on STiH407 based silicon.
Signed-off-by: Peter Griffin
Acked-by: Lee Jones
---
arch/arm/boot/dts/stih407-family.dtsi | 52 +++
1 file changed, 52 insertions(+)
diff --git a/arch/arm/boot/dts/stih407-family.dtsi
b/arch/arm/boot/dts/stih407-family.dtsi
index d294e82..45cab30 100644
--- a/arch/arm/boot/dts/stih407-family.dtsi
+++ b/arch/arm/boot/dts/stih407-family.dtsi
@@ -821,5 +821,57 @@
clock-frequency = <6>;
st,syscfg = <&syscfg_core 0x224>;
};
+
+ /* fdma audio */
+ fdma0: dma-controller at 8e2 {
+ compatible = "st,stih407-fdma-mpe31-11",
"st,slim-rproc";
+ reg = <0x8e2 0x8000>,
+ <0x8e3 0x3000>,
+ <0x8e37000 0x1000>,
+ <0x8e38000 0x8000>;
+ reg-names = "slimcore", "dmem", "peripherals", "imem";
+ clocks = <&clk_s_c0_flexgen CLK_FDMA>,
+<&clk_s_c0_flexgen CLK_EXT2F_A9>,
+<&clk_s_c0_flexgen CLK_EXT2F_A9>,
+<&clk_s_c0_flexgen CLK_EXT2F_A9>;
+ interrupts = ;
+ dma-channels = <16>;
+ #dma-cells = <3>;
+ };
+
+ /* fdma app */
+ fdma1: dma-controller at 8e4 {
+ compatible = "st,stih407-fdma-mpe31-12",
"st,slim-rproc";
+ reg = <0x8e4 0x8000>,
+ <0x8e5 0x3000>,
+ <0x8e57000 0x1000>,
+ <0x8e58000 0x8000>;
+ reg-names = "slimcore", "dmem", "peripherals", "imem";
+ clocks = <&clk_s_c0_flexgen CLK_FDMA>,
+ <&clk_s_c0_flexgen CLK_TX_ICN_DMU>,
+ <&clk_s_c0_flexgen CLK_TX_ICN_DMU>,
+ <&clk_s_c0_flexgen CLK_EXT2F_A9>;
+
+ interrupts = ;
+ dma-channels = <16>;
+ #dma-cells = <3>;
+ };
+
+ /* fdma free running */
+ fdma2: dma-controller at 8e6 {
+ compatible = "st,stih407-fdma-mpe31-13",
"st,slim-rproc";
+ reg = <0x8e6 0x8000>,
+ <0x8e7 0x3000>,
+ <0x8e77000 0x1000>,
+ <0x8e78000 0x8000>;
+ reg-names = "slimcore", "dmem", "peripherals", "imem";
+ interrupts = ;
+ dma-channels = <16>;
+ #dma-cells = <3>;
+ clocks = <&clk_s_c0_flexgen CLK_FDMA>,
+ <&clk_s_c0_flexgen CLK_EXT2F_A9>,
+ <&clk_s_c0_flexgen CLK_TX_ICN_DISP_0>,
+ <&clk_s_c0_flexgen CLK_EXT2F_A9>;
+ };
};
};
--
1.9.1
[PATCH v9 08/19] ARM: multi_v7_defconfig: Enable STi FDMA driver
This DMA controller is found on all STi chipsets. Signed-off-by: Peter Griffin Acked-by: Lee Jones --- arch/arm/configs/multi_v7_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig index ea23250..998578a 100644 --- a/arch/arm/configs/multi_v7_defconfig +++ b/arch/arm/configs/multi_v7_defconfig @@ -784,6 +784,7 @@ CONFIG_DMA_OMAP=y CONFIG_QCOM_BAM_DMA=y CONFIG_XILINX_VDMA=y CONFIG_DMA_SUN6I=y +CONFIG_ST_FDMA=m CONFIG_STAGING=y CONFIG_SENSORS_ISL29018=y CONFIG_SENSORS_ISL29028=y -- 1.9.1
[PATCH v9 11/19] ARM: DT: STiH407: Add i2s_in pinctrl configuration
This patch adds the pinctrl config for the i2s_in pins
used by the uniperif reader IP.
Signed-off-by: Arnaud Pouliquen
Signed-off-by: Peter Griffin
Acked-by: Lee Jones
---
arch/arm/boot/dts/stih407-pinctrl.dtsi | 24
1 file changed, 24 insertions(+)
diff --git a/arch/arm/boot/dts/stih407-pinctrl.dtsi
b/arch/arm/boot/dts/stih407-pinctrl.dtsi
index 0fb5c8a..537db7e 100644
--- a/arch/arm/boot/dts/stih407-pinctrl.dtsi
+++ b/arch/arm/boot/dts/stih407-pinctrl.dtsi
@@ -1090,6 +1090,30 @@
};
};
+ i2s_in {
+ pinctrl_i2s_8ch_in: i2s_8ch_in{
+ st,pins {
+ mclk = <&pio32 5 ALT1 IN>;
+ lrclk = <&pio32 7 ALT1 IN>;
+ sclk = <&pio32 6 ALT1 IN>;
+ data0 = <&pio32 4 ALT1 IN>;
+ data1 = <&pio33 0 ALT1 IN>;
+ data2 = <&pio33 1 ALT1 IN>;
+ data3 = <&pio33 2 ALT1 IN>;
+ data4 = <&pio33 3 ALT1 IN>;
+ };
+ };
+
+ pinctrl_i2s_2ch_in: i2s_2ch_in{
+ st,pins {
+ mclk = <&pio32 5 ALT1 IN>;
+ lrclk = <&pio32 7 ALT1 IN>;
+ sclk = <&pio32 6 ALT1 IN>;
+ data0 = <&pio32 4 ALT1 IN>;
+ };
+ };
+ };
+
serial3 {
pinctrl_serial3: serial3-0 {
st,pins {
--
1.9.1
[PATCH v9 16/19] ARM: DT: STi: stihxxx-b2120: Add DT nodes for STi audio card
This patch enables the uniperif players 2 & 3 for b2120 boards
and also adds the "simple-audio-card" device node to interconnect
the SoC sound device and the codec.
Signed-off-by: Arnaud Pouliquen
Signed-off-by: Peter Griffin
---
arch/arm/boot/dts/stihxxx-b2120.dtsi | 45
1 file changed, 45 insertions(+)
diff --git a/arch/arm/boot/dts/stihxxx-b2120.dtsi
b/arch/arm/boot/dts/stihxxx-b2120.dtsi
index 722c63f..4939501 100644
--- a/arch/arm/boot/dts/stihxxx-b2120.dtsi
+++ b/arch/arm/boot/dts/stihxxx-b2120.dtsi
@@ -131,5 +131,50 @@
dvb-card= ;
};
};
+
+ sti_uni_player2: sti-uni-player at 8d82000 {
+ status = "okay";
+ };
+
+ sti_uni_player3: sti-uni-player at 8d85000 {
+ status = "okay";
+ };
+
+ sti_sasg_codec: sti-sasg-codec {
+ status = "okay";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_spdif_out>;
+ };
+
+ sound {
+ compatible = "simple-audio-card";
+ simple-audio-card,name = "sti audio card";
+ status = "okay";
+
+ simple-audio-card,dai-link at 0 {
+ /* DAC */
+ format = "i2s";
+ mclk-fs = <256>;
+ cpu {
+ sound-dai = <&sti_uni_player2>;
+ };
+
+ codec {
+ sound-dai = <&sti_sasg_codec 1>;
+ };
+ };
+ simple-audio-card,dai-link at 1 {
+ /* SPDIF */
+ format = "left_j";
+ mclk-fs = <128>;
+ cpu {
+ sound-dai = <&sti_uni_player3>;
+ };
+
+ codec {
+ sound-dai = <&sti_sasg_codec 0>;
+ };
+ };
+ };
};
};
--
1.9.1
drm: NULL pointer dereference in drm_mode_object_find()
On Fri, Aug 19, 2016 at 7:10 PM, Alexander Potapenko
wrote:
> Hello,
>
> the program below triggers a NULL deref in DRM code when ran on QEMU:
>
> ===
> BUG: unable to handle kernel NULL pointer dereference at (null)
> IP: [< inline >] __list_add ./include/linux/list.h:44
> IP: [< inline >] list_add_tail ./include/linux/list.h:77
> IP: [< inline >] __mutex_lock_common kernel/locking/mutex.c:543
> IP: [] __mutex_lock_slowpath+0x6f/0x100
> kernel/locking/mutex.c:824
> PGD 1c555067 PUD 1c554067 PMD 0
> Oops: 0002 [#1] SMP
> Modules linked in:
> CPU: 0 PID: 2517 Comm: crash_drm_mode_ Not tainted 4.8.0-rc2+ #1157
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
> task: 88001c40a700 task.stack: 88001c984000
> RIP: 0010:[] []
> __mutex_lock_slowpath+0x6f/0x100
> RSP: 0018:88001c987cb0 EFLAGS: 00010282
> RAX: RBX: 88001d5212a0 RCX: c100
> RDX: 0001 RSI: 88001c40a700 RDI: 88001d5212a4
> RBP: 88001c987cf8 R08: 88001c984000 R09:
> R10: R11: R12: 88001c40a700
> R13: 88001d5212a4 R14: R15: 88001d5212a8
> FS: 00dc9880() GS:88001f00() knlGS:
> CS: 0010 DS: ES: CR0: 80050033
> CR2: CR3: 1c8a9000 CR4: 000406f0
> Stack:
> 88001d5212a8 811a398f
> 88001d5212a0 88001d5212a0
> 81a6eb20 88001c987d10 818e85ba 88001d521000
> Call Trace:
> [< inline >] __mutex_fastpath_lock
> ./arch/x86/include/asm/mutex_64.h:28
> [] mutex_lock+0x1a/0x30 kernel/locking/mutex.c:102
> [] _object_find+0x23/0xc0 drivers/gpu/drm/drm_crtc.c:329
> [< inline >] drm_mode_object_find drivers/gpu/drm/drm_crtc.c:360
> [< inline >] drm_crtc_find ./include/drm/drm_crtc.h:2999
> [] drm_mode_page_flip_ioctl+0x4e/0x300
> drivers/gpu/drm/drm_crtc.c:5414
> [] drm_ioctl+0x2a2/0x460 drivers/gpu/drm/drm_ioctl.c:721
> [< inline >] vfs_ioctl fs/ioctl.c:43
> [] do_vfs_ioctl+0x8d/0x580 fs/ioctl.c:675
> [< inline >] SYSC_ioctl fs/ioctl.c:690
> [] SyS_ioctl+0x74/0x80 fs/ioctl.c:681
> [] entry_SYSCALL_64_fastpath+0x13/0x8f
> arch/x86/entry/entry_64.S:207
> Code: e8 37 23 00 00 8b 03 83 f8 01 0f 84 95 00 00 00 48 8b 43 10 4c
> 8d 7b 08 48 89 63 10 41 be ff ff ff ff 4c 89 3c 24 48 89 44 24 08 <48>
> 89 20 4c 89 64 24 10 eb 19 49 c7 04 24 02 00 00 00 c6 43 04
> RIP [< inline >] __list_add ./include/linux/list.h:44
> RIP [< inline >] list_add_tail ./include/linux/list.h:77
> RIP [< inline >] __mutex_lock_common kernel/locking/mutex.c:543
> RIP [] __mutex_lock_slowpath+0x6f/0x100
> kernel/locking/mutex.c:824
> RSP
> CR2:
> ---[ end trace 3cef4eb618ac6bb6 ]---
> ===
>
> // autogenerated by syzkaller (http://github.com/google/syzkaller)
> #include
> #include
> #include
>
> int main()
> {
> int fd = open("/dev/dri/card0", 0);
> mmap(0x20036000ul, 0x1000ul, 0x3ul, 0x32ul, 0xul, 0x0ul);
> memcpy((void*)0x20036ad7,
> "\x1e\xa4\x45\xdc\xca\x11\xff\x25\x72\x65\x7e\x4a\x56\x54\x35"
> "\x67\xe3\x8b\x41\x5c\x6d\x69\xa5\xf9\x88\x29\xb8\xc9\x6a\x45"
> "\x76\xa9\xe7\x14\xd1\xf6\xa3\x59\x07\x4d\xe5\xc8\x39\xbf\x33"
> "\xb9\x3d\x21\xd1\xaf\x16\x4d\xbc\xbf\xb1\x0a\x92\x97\xd9\x91"
> "\x4d\xd8\xf8\xa1\xa6\xa3\x20\x02\x2c\x5e\x8f\x87\x05\x8b\xeb"
> "\x9a\xb9\xbc\xa6\x60\x45\x8d\x19\x01\x7d\xb7\xef\x64\x62\x2e"
> "\x5e\x3d\xfe\x65\xbf\xe2\x80\x89\x36\x48\x73\xc6\xa2\x6e\xe2"
> "\x1a\x8f\x1b\x11\x6f\x49\x20\xeb\x74\x2d\x41\xb9\x8b\xb4\x8e"
> "\x8b\xf5\x6d\xb7\xb1\xa3\xcb\xc4\xc2\x7f\x6d\xef\x32\xef\xa7"
> "\x1c\x17\x03\x60\x7b\x31\x1f\x66",
> 143);
> ioctl(fd, 0xbb0ul, 0x20036ad7ul, 0, 0, 0);
> return 0;
> }
>
> I build the ToT kernel (commit
> 952b159f2919a8d514f13999f9f463bddcc1dae7, Aug 18) with defconfig and
> CONFIG_DRM_VGEM=y.
+dri-devel
I am also hitting this on 0f98f121e1670eaa2a2fbb675e07d6ba7f0e146f of
linux-next.
[PATCH 2/6] drm/i915: Pass atomic state to intel_audio_codec_enable
From: Maarten Lankhorst
drm_select_eld requires mode_config.mutex and connection_mutex
because it looks at the connector list and at the legacy encoders.
This is not required, because when we call audio_codec_enable we know
which connector it was called for, so pass the state.
This also removes having to look at crtc->config.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/intel_audio.c | 15 +--
drivers/gpu/drm/i915/intel_ddi.c | 2 +-
drivers/gpu/drm/i915/intel_dp.c| 11 ++-
drivers/gpu/drm/i915/intel_drv.h | 4 +++-
drivers/gpu/drm/i915/intel_hdmi.c | 2 +-
5 files changed, 20 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_audio.c
b/drivers/gpu/drm/i915/intel_audio.c
index 6c70a5bfd7d8..fd49c32c514c 100644
--- a/drivers/gpu/drm/i915/intel_audio.c
+++ b/drivers/gpu/drm/i915/intel_audio.c
@@ -480,15 +480,18 @@ static void ilk_audio_codec_enable(struct drm_connector
*connector,
/**
* intel_audio_codec_enable - Enable the audio codec for HD audio
* @intel_encoder: encoder on which to enable audio
+ * @crtc_state: pointer to the current crtc state.
+ * @conn_state: pointer to the current connector state.
*
* The enable sequences may only be performed after enabling the transcoder and
* port, and after completed link training.
*/
-void intel_audio_codec_enable(struct intel_encoder *intel_encoder)
+void intel_audio_codec_enable(struct intel_encoder *intel_encoder,
+ const struct intel_crtc_state *crtc_state,
+ const struct drm_connector_state *conn_state)
{
struct drm_encoder *encoder = &intel_encoder->base;
- struct intel_crtc *crtc = to_intel_crtc(encoder->crtc);
- const struct drm_display_mode *adjusted_mode =
&crtc->config->base.adjusted_mode;
+ const struct drm_display_mode *adjusted_mode =
&crtc_state->base.adjusted_mode;
struct drm_connector *connector;
struct drm_device *dev = encoder->dev;
struct drm_i915_private *dev_priv = to_i915(dev);
@@ -496,8 +499,8 @@ void intel_audio_codec_enable(struct intel_encoder
*intel_encoder)
struct intel_digital_port *intel_dig_port = enc_to_dig_port(encoder);
enum port port = intel_dig_port->port;
- connector = drm_select_eld(encoder);
- if (!connector)
+ connector = conn_state->connector;
+ if (!connector || !connector->eld[0])
return;
DRM_DEBUG_DRIVER("ELD on [CONNECTOR:%d:%s], [ENCODER:%d:%s]\n",
@@ -508,7 +511,7 @@ void intel_audio_codec_enable(struct intel_encoder
*intel_encoder)
/* ELD Conn_Type */
connector->eld[5] &= ~(3 << 2);
- if (intel_crtc_has_dp_encoder(crtc->config))
+ if (intel_crtc_has_dp_encoder(crtc_state))
connector->eld[5] |= (1 << 2);
connector->eld[6] = drm_av_sync_delay(connector, adjusted_mode) / 2;
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index ce369c2e96a0..e3aed539d932 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -1783,7 +1783,7 @@ static void intel_enable_ddi(struct intel_encoder
*intel_encoder,
if (intel_crtc->config->has_audio) {
intel_display_power_get(dev_priv, POWER_DOMAIN_AUDIO);
- intel_audio_codec_enable(intel_encoder);
+ intel_audio_codec_enable(intel_encoder, pipe_config,
conn_state);
}
}
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index e4a25668ccf6..1402387a47a3 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -2654,7 +2654,8 @@ static void intel_dp_enable_port(struct intel_dp
*intel_dp,
}
static void intel_enable_dp(struct intel_encoder *encoder,
- struct intel_crtc_state *pipe_config)
+ struct intel_crtc_state *pipe_config,
+ struct drm_connector_state *conn_state)
{
struct intel_dp *intel_dp = enc_to_intel_dp(&encoder->base);
struct drm_device *dev = encoder->base.dev;
@@ -2696,7 +2697,7 @@ static void intel_enable_dp(struct intel_encoder *encoder,
if (pipe_config->has_audio) {
DRM_DEBUG_DRIVER("Enabling DP audio on pipe %c\n",
pipe_name(pipe));
- intel_audio_codec_enable(encoder);
+ intel_audio_codec_enable(encoder, pipe_config, conn_state);
}
}
@@ -2706,7 +2707,7 @@ static void g4x_enable_dp(struct intel_encoder *encoder,
{
struct intel_dp *intel_dp = enc_to_intel_dp(&encoder->base);
- intel_enable_dp(encoder, pipe_config);
+ intel_enable_dp(encoder, pipe_config, conn_state);
intel_edp_backlight_on(intel_dp);
}
@@ -2843,7 +2844,7 @@ static void vlv_pre_enable_dp(struct intel_encoder
*encoder,
{
vlv_phy_pre_encoder_enable(encoder);
- intel_enable_dp(encode
[PATCH 1/6] drm/i915: Convert intel_hdmi to use atomic state
From: Maarten Lankhorst
This is the last connector still looking at crtc->config. Fix this.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/intel_hdmi.c | 48 +--
1 file changed, 21 insertions(+), 27 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
b/drivers/gpu/drm/i915/intel_hdmi.c
index 1a116a6a1817..40f6e1b47eb3 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -975,7 +975,9 @@ static void intel_hdmi_get_config(struct intel_encoder
*encoder,
pipe_config->lane_count = 4;
}
-static void intel_enable_hdmi_audio(struct intel_encoder *encoder)
+static void intel_enable_hdmi_audio(struct intel_encoder *encoder,
+ struct intel_crtc_state *pipe_config,
+ struct drm_connector_state *conn_state)
{
struct intel_crtc *crtc = to_intel_crtc(encoder->base.crtc);
@@ -991,21 +993,20 @@ static void g4x_enable_hdmi(struct intel_encoder *encoder,
{
struct drm_device *dev = encoder->base.dev;
struct drm_i915_private *dev_priv = to_i915(dev);
- struct intel_crtc *crtc = to_intel_crtc(encoder->base.crtc);
struct intel_hdmi *intel_hdmi = enc_to_intel_hdmi(&encoder->base);
u32 temp;
temp = I915_READ(intel_hdmi->hdmi_reg);
temp |= SDVO_ENABLE;
- if (crtc->config->has_audio)
+ if (pipe_config->has_audio)
temp |= SDVO_AUDIO_ENABLE;
I915_WRITE(intel_hdmi->hdmi_reg, temp);
POSTING_READ(intel_hdmi->hdmi_reg);
- if (crtc->config->has_audio)
- intel_enable_hdmi_audio(encoder);
+ if (pipe_config->has_audio)
+ intel_enable_hdmi_audio(encoder, pipe_config, conn_state);
}
static void ibx_enable_hdmi(struct intel_encoder *encoder,
@@ -1040,8 +1041,8 @@ static void ibx_enable_hdmi(struct intel_encoder *encoder,
* FIXME: BSpec says this should be done at the end of
* of the modeset sequence, so not sure if this isn't too soon.
*/
- if (crtc->config->pipe_bpp > 24 &&
- crtc->config->pixel_multiplier > 1) {
+ if (pipe_config->pipe_bpp > 24 &&
+ pipe_config->pixel_multiplier > 1) {
I915_WRITE(intel_hdmi->hdmi_reg, temp & ~SDVO_ENABLE);
POSTING_READ(intel_hdmi->hdmi_reg);
@@ -1055,8 +1056,8 @@ static void ibx_enable_hdmi(struct intel_encoder *encoder,
POSTING_READ(intel_hdmi->hdmi_reg);
}
- if (crtc->config->has_audio)
- intel_enable_hdmi_audio(encoder);
+ if (pipe_config->has_audio)
+ intel_enable_hdmi_audio(encoder, pipe_config, conn_state);
}
static void cpt_enable_hdmi(struct intel_encoder *encoder,
@@ -1073,7 +1074,7 @@ static void cpt_enable_hdmi(struct intel_encoder *encoder,
temp = I915_READ(intel_hdmi->hdmi_reg);
temp |= SDVO_ENABLE;
- if (crtc->config->has_audio)
+ if (pipe_config->has_audio)
temp |= SDVO_AUDIO_ENABLE;
/*
@@ -1086,7 +1087,7 @@ static void cpt_enable_hdmi(struct intel_encoder *encoder,
* 4. enable HDMI clock gating
*/
- if (crtc->config->pipe_bpp > 24) {
+ if (pipe_config->pipe_bpp > 24) {
I915_WRITE(TRANS_CHICKEN1(pipe),
I915_READ(TRANS_CHICKEN1(pipe)) |
TRANS_CHICKEN1_HDMIUNIT_GC_DISABLE);
@@ -1098,7 +1099,7 @@ static void cpt_enable_hdmi(struct intel_encoder *encoder,
I915_WRITE(intel_hdmi->hdmi_reg, temp);
POSTING_READ(intel_hdmi->hdmi_reg);
- if (crtc->config->pipe_bpp > 24) {
+ if (pipe_config->pipe_bpp > 24) {
temp &= ~SDVO_COLOR_FORMAT_MASK;
temp |= HDMI_COLOR_FORMAT_12bpc;
@@ -1110,8 +,8 @@ static void cpt_enable_hdmi(struct intel_encoder *encoder,
~TRANS_CHICKEN1_HDMIUNIT_GC_DISABLE);
}
- if (crtc->config->has_audio)
- intel_enable_hdmi_audio(encoder);
+ if (pipe_config->has_audio)
+ intel_enable_hdmi_audio(encoder, pipe_config, conn_state);
}
static void vlv_enable_hdmi(struct intel_encoder *encoder,
@@ -1178,9 +1179,7 @@ static void g4x_disable_hdmi(struct intel_encoder
*encoder,
struct intel_crtc_state *old_crtc_state,
struct drm_connector_state *old_conn_state)
{
- struct intel_crtc *crtc = to_intel_crtc(encoder->base.crtc);
-
- if (crtc->config->has_audio)
+ if (old_crtc_state->has_audio)
intel_audio_codec_disable(encoder);
intel_disable_hdmi(encoder, old_crtc_state, old_conn_state);
@@ -1190,9 +1189,7 @@ static void pch_disable_hdmi(struct intel_encoder
*encoder,
struct intel_crtc_state *old_crtc_state,
struct drm_connector_state *old_conn_state)
{
- stru
[PATCH 6/6] drm/i915: Enable support for nonblocking modeset
From: Maarten Lankhorst
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/intel_display.c | 9 -
1 file changed, 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 8eda324024c9..98b4bfd6ff9c 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -14493,10 +14493,6 @@ static void intel_atomic_track_fbs(struct
drm_atomic_state *state)
* This function commits a top-level state object that has been validated
* with drm_atomic_helper_check().
*
- * FIXME: Atomic modeset support for i915 is not yet complete. At the moment
- * nonblocking commits are only safe for pure plane updates. Everything else
- * should work though.
- *
* RETURNS
* Zero for success or -errno.
*/
@@ -14508,11 +14504,6 @@ static int intel_atomic_commit(struct drm_device *dev,
struct drm_i915_private *dev_priv = to_i915(dev);
int ret = 0;
- if (intel_state->modeset && nonblock) {
- DRM_DEBUG_KMS("nonblocking commit for modeset not yet
implemented.\n");
- return -EINVAL;
- }
-
ret = drm_atomic_helper_setup_commit(state, nonblock);
if (ret)
return ret;
--
2.7.4
[PATCH 6/6] ARM: dts: gr8: Add support for the GR8 evaluation board
Hi,
On Wed, Aug 31, 2016 at 4:18 PM, Maxime Ripard
wrote:
> From: Mylène Josserand
>
> The GR8-EVB is a small board with an NextThing GR8, an Hynix MLC NAND,
> an AXP209 PMIC, USB host and OTG, an SPDIF output and a connectors for CSI,
> I2S and LCD.
>
> Signed-off-by: Mylène Josserand
> Signed-off-by: Maxime Ripard
> ---
> arch/arm/boot/dts/Makefile| 3 +-
> arch/arm/boot/dts/gr8-evb.dts | 378
> ++
> 2 files changed, 380 insertions(+), 1 deletion(-)
> create mode 100644 arch/arm/boot/dts/gr8-evb.dts
>
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index 7dd4a07c4784..8226b0a2e178 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -734,7 +734,8 @@ dtb-$(CONFIG_MACH_SUN5I) += \
> sun5i-a13-olinuxino-micro.dtb \
> sun5i-a13-q8-tablet.dtb \
> sun5i-a13-utoo-p66.dtb \
> - sun5i-r8-chip.dtb
> + sun5i-r8-chip.dtb \
> + gr8-evb.dtb
> dtb-$(CONFIG_MACH_SUN6I) += \
> sun6i-a31-app4-evb1.dtb \
> sun6i-a31-colombus.dtb \
> diff --git a/arch/arm/boot/dts/gr8-evb.dts b/arch/arm/boot/dts/gr8-evb.dts
> new file mode 100644
> index ..e334d18d7bf0
> --- /dev/null
> +++ b/arch/arm/boot/dts/gr8-evb.dts
> @@ -0,0 +1,378 @@
> +/*
> + * Copyright 2016 Free Electrons
> + * Copyright 2016 NextThing Co
> + *
> + * Mylène Josserand
> + *
> + * This file is dual-licensed: you can use it either under the terms
> + * of the GPL or the X11 license, at your option. Note that this dual
> + * licensing only applies to this file, and not this project as a
> + * whole.
> + *
> + * a) This file is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License as
> + * published by the Free Software Foundation; either version 2 of the
> + * License, or (at your option) any later version.
> + *
> + * This file is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + * Or, alternatively,
> + *
> + * b) Permission is hereby granted, free of charge, to any person
> + * obtaining a copy of this software and associated documentation
> + * files (the "Software"), to deal in the Software without
> + * restriction, including without limitation the rights to use,
> + * copy, modify, merge, publish, distribute, sublicense, and/or
> + * sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following
> + * conditions:
> + *
> + * The above copyright notice and this permission notice shall be
> + * included in all copies or substantial portions of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
> + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
> + * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
> + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
> + * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
> + * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> + * OTHER DEALINGS IN THE SOFTWARE.
> + */
> +
> +/dts-v1/;
> +#include "gr8.dtsi"
> +#include "sunxi-common-regulators.dtsi"
> +
> +#include
> +#include
> +#include
> +
> +/ {
> + model = "NextThing GR8-EVB";
> + compatible = "nextthing,gr8-evb", "nextthing,gr8";
> +
> + aliases {
> + i2c0 = &i2c0;
> + i2c1 = &i2c1;
> + i2c2 = &i2c2;
> + serial0 = &uart1;
> + serial1 = &uart2;
> + };
> +
> + chosen {
> + stdout-path = "serial0:115200n8";
> + };
> +
> + backlight: backlight {
> + compatible = "pwm-backlight";
> + pwms = <&pwm 0 1 0>;
> + enable-gpios = <&axp_gpio 1 GPIO_ACTIVE_HIGH>;
> +
> + brightness-levels = <0 10 20 30 40 50 60 70 80 90 100>;
> + default-brightness-level = <8>;
> + };
> +
> + panel {
> + compatible = "allwinner,sun4i-a10-sub-evb-5-lcd";
> + enable-gpios = <&axp_gpio 0 GPIO_ACTIVE_HIGH>;
> + backlight = <&backlight>;
> + power-supply = <®_vcc3v0>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port at 0 {
> + reg = <0>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + panel_input: endpoint at 0 {
> + reg = <0>;
> + remote-endpoint = <&tcon0_out_panel>;
> +
[PATCH v9 03/19] dmaengine: st_fdma: Add STMicroelectronics FDMA DT binding documentation
This patch adds the DT binding documentation for the FDMA constroller
found on STi based chipsets from STMicroelectronics.
Signed-off-by: Ludovic Barre
Signed-off-by: Peter Griffin
Acked-by: Rob Herring
---
Documentation/devicetree/bindings/dma/st_fdma.txt | 87 +++
1 file changed, 87 insertions(+)
create mode 100644 Documentation/devicetree/bindings/dma/st_fdma.txt
diff --git a/Documentation/devicetree/bindings/dma/st_fdma.txt
b/Documentation/devicetree/bindings/dma/st_fdma.txt
new file mode 100644
index 000..495d853
--- /dev/null
+++ b/Documentation/devicetree/bindings/dma/st_fdma.txt
@@ -0,0 +1,87 @@
+* STMicroelectronics Flexible Direct Memory Access Device Tree bindings
+
+The FDMA is a general-purpose direct memory access controller capable of
+supporting 16 independent DMA channels. It accepts up to 32 DMA requests.
+The FDMA is based on a Slim processor which requires a firmware.
+
+* FDMA Controller
+
+Required properties:
+- compatible : Should be one of
+- st,stih407-fdma-mpe31-11, "st,slim-rproc";
+- st,stih407-fdma-mpe31-12, "st,slim-rproc";
+- st,stih407-fdma-mpe31-13, "st,slim-rproc";
+- reg : Should contain an entry for each name in reg-names
+- reg-names: Must contain "slimcore", "dmem", "peripherals", "imem" entries
+- interrupts : Should contain one interrupt shared by all channels
+- dma-channels : Number of channels supported by the controller
+- #dma-cells : Must be <3>. See DMA client section below
+- clocks : Must contain an entry for each clock
+See: Documentation/devicetree/bindings/clock/clock-bindings.txt
+
+
+Example:
+
+ fdma0: dma-controller at 8e2 {
+ compatible = "st,stih407-fdma-mpe31-11", "st,slim-rproc";
+ reg = <0x8e2 0x8000>,
+ <0x8e3 0x3000>,
+ <0x8e37000 0x1000>,
+ <0x8e38000 0x8000>;
+ reg-names = "slimcore", "dmem", "peripherals", "imem";
+ clocks = <&clk_s_c0_flexgen CLK_FDMA>,
+<&clk_s_c0_flexgen CLK_EXT2F_A9>,
+<&clk_s_c0_flexgen CLK_EXT2F_A9>,
+<&clk_s_c0_flexgen CLK_EXT2F_A9>;
+ interrupts = ;
+ dma-channels = <16>;
+ #dma-cells = <3>;
+ };
+
+* DMA client
+
+Required properties:
+- dmas: Comma separated list of dma channel requests
+- dma-names: Names of the aforementioned requested channels
+
+Each dmas request consists of 4 cells:
+1. A phandle pointing to the FDMA controller
+2. The request line number
+3. A 32bit mask specifying (see include/linux/platform_data/dma-st-fdma.h)
+ -bit 2-0: Holdoff value, dreq will be masked for
+ 0x0: 0-0.5us
+ 0x1: 0.5-1us
+ 0x2: 1-1.5us
+ -bit 17: data swap
+ 0x0: disabled
+ 0x1: enabled
+ -bit 21: Increment Address
+ 0x0: no address increment between transfers
+ 0x1: increment address between transfers
+ -bit 22: 2 STBus Initiator Coprocessor interface
+ 0x0: high priority port
+ 0x1: low priority port
+4. transfers type
+ 0 free running
+ 1 paced
+
+Example:
+
+ sti_uni_player2: sti-uni-player at 2 {
+ compatible = "st,sti-uni-player";
+ status = "disabled";
+ #sound-dai-cells = <0>;
+ st,syscfg = <&syscfg_core>;
+ clocks = <&clk_s_d0_flexgen CLK_PCM_2>;
+ assigned-clocks = <&clk_s_d0_flexgen CLK_PCM_2>;
+ assigned-clock-parents = <&clk_s_d0_quadfs 2>;
+ assigned-clock-rates = <5000>;
+ reg = <0x8D82000 0x158>;
+ interrupts = ;
+ dmas = <&fdma0 4 0 1>;
+ dai-name = "Uni Player #1 (DAC)";
+ dma-names = "tx";
+ st,uniperiph-id = <2>;
+ st,version = <5>;
+ st,mode = "PCM";
+ };
--
1.9.1
[PATCH v9 09/19] ARM: multi_v7_defconfig: Enable STi and simple-card drivers.
This patch enables the STi ALSA drivers found on STi platforms as well as the simple-card driver which is a dependency to have working sound. Signed-off-by: Peter Griffin Acked-by: Lee Jones Cc: arnaud.pouliquen at st.com Cc: broonie at kernel.org --- arch/arm/configs/multi_v7_defconfig | 3 +++ 1 file changed, 3 insertions(+) diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig index 998578a..51a38b1 100644 --- a/arch/arm/configs/multi_v7_defconfig +++ b/arch/arm/configs/multi_v7_defconfig @@ -644,6 +644,9 @@ CONFIG_SND_SOC_AK4642=m CONFIG_SND_SOC_SGTL5000=m CONFIG_SND_SOC_SPDIF=m CONFIG_SND_SOC_WM8978=m +CONFIG_SND_SOC_STI=m +CONFIG_SND_SOC_STI_SAS=m +CONFIG_SND_SIMPLE_CARD=m CONFIG_USB=y CONFIG_USB_XHCI_HCD=y CONFIG_USB_XHCI_MVEBU=y -- 1.9.1
[PATCH v9 14/19] ARM: STi: DT: STiH407: Add uniperif player dt nodes
This patch adds the DT nodes for the uniperif player
IP blocks found on STiH407 family silicon.
Signed-off-by: Arnaud Pouliquen
Signed-off-by: Peter Griffin
---
arch/arm/boot/dts/stih407-family.dtsi | 80 +++
1 file changed, 80 insertions(+)
diff --git a/arch/arm/boot/dts/stih407-family.dtsi
b/arch/arm/boot/dts/stih407-family.dtsi
index d1258d5..1edc36c 100644
--- a/arch/arm/boot/dts/stih407-family.dtsi
+++ b/arch/arm/boot/dts/stih407-family.dtsi
@@ -880,5 +880,85 @@
status = "disabled";
st,syscfg = <&syscfg_core>;
};
+
+ sti_uni_player0: sti-uni-player at 8d8 {
+ compatible = "st,sti-uni-player";
+ #sound-dai-cells = <0>;
+ st,syscfg = <&syscfg_core>;
+ clocks = <&clk_s_d0_flexgen CLK_PCM_0>;
+ assigned-clocks = <&clk_s_d0_quadfs 0>,
<&clk_s_d0_flexgen CLK_PCM_0>;
+ assigned-clock-parents = <0>, <&clk_s_d0_quadfs 0>;
+ assigned-clock-rates = <5000>;
+ reg = <0x8d8 0x158>;
+ interrupts = ;
+ dmas = <&fdma0 2 0 1>;
+ dai-name = "Uni Player #0 (HDMI)";
+ dma-names = "tx";
+ st,uniperiph-id = <0>;
+ st,version = <5>;
+ st,mode = "HDMI";
+
+ status = "disabled";
+ };
+
+ sti_uni_player1: sti-uni-player at 8d81000 {
+ compatible = "st,sti-uni-player";
+ #sound-dai-cells = <0>;
+ st,syscfg = <&syscfg_core>;
+ clocks = <&clk_s_d0_flexgen CLK_PCM_1>;
+ assigned-clocks = <&clk_s_d0_quadfs 1>,
<&clk_s_d0_flexgen CLK_PCM_1>;
+ assigned-clock-parents = <0>, <&clk_s_d0_quadfs 1>;
+ assigned-clock-rates = <5000>;
+ reg = <0x8d81000 0x158>;
+ interrupts = ;
+ dmas = <&fdma0 3 0 1>;
+ dai-name = "Uni Player #1 (PIO)";
+ dma-names = "tx";
+ st,uniperiph-id = <1>;
+ st,version = <5>;
+ st,mode = "PCM";
+
+ status = "disabled";
+ };
+
+ sti_uni_player2: sti-uni-player at 8d82000 {
+ compatible = "st,sti-uni-player";
+ #sound-dai-cells = <0>;
+ st,syscfg = <&syscfg_core>;
+ clocks = <&clk_s_d0_flexgen CLK_PCM_2>;
+ assigned-clocks = <&clk_s_d0_quadfs 2>,
<&clk_s_d0_flexgen CLK_PCM_2>;
+ assigned-clock-parents = <0>, <&clk_s_d0_quadfs 2>;
+ assigned-clock-rates = <5000>;
+ reg = <0x8d82000 0x158>;
+ interrupts = ;
+ dmas = <&fdma0 4 0 1>;
+ dai-name = "Uni Player #1 (DAC)";
+ dma-names = "tx";
+ st,uniperiph-id = <2>;
+ st,version = <5>;
+ st,mode = "PCM";
+
+ status = "disabled";
+ };
+
+ sti_uni_player3: sti-uni-player at 8d85000 {
+ compatible = "st,sti-uni-player";
+ #sound-dai-cells = <0>;
+ st,syscfg = <&syscfg_core>;
+ clocks = <&clk_s_d0_flexgen CLK_SPDIFF>;
+ assigned-clocks = <&clk_s_d0_quadfs 3>,
<&clk_s_d0_flexgen CLK_SPDIFF>;
+ assigned-clock-parents = <0>, <&clk_s_d0_quadfs 3>;
+ assigned-clock-rates = <5000>;
+ reg = <0x8d85000 0x158>;
+ interrupts = ;
+ dmas = <&fdma0 7 0 1>;
+ dma-names = "tx";
+ dai-name = "Uni Player #1 (PIO)";
+ st,uniperiph-id = <3>;
+ st,version = <5>;
+ st,mode = "SPDIF";
+
+ status = "disabled";
+ };
};
};
--
1.9.1
[PATCH v9 17/19] drm/virtio: kconfig: Fix recursive dependency issue.
ST_SLIM_REMOTEPROC must select REMOTEPROC, which exposes the following recursive dependency. [..] drivers/video/fbdev/Kconfig:5:error: recursive dependency detected! For a resolution refer to Documentation/kbuild/kconfig-language.txt subsection "Kconfig recursive dependency limitations" drivers/video/fbdev/Kconfig:5: symbol FB is selected by DRM_KMS_FB_HELPER For a resolution refer to Documentation/kbuild/kconfig-language.txt subsection "Kconfig recursive dependency limitations" drivers/gpu/drm/Kconfig:42: symbol DRM_KMS_FB_HELPER depends on DRM_KMS_HELPER For a resolution refer to Documentation/kbuild/kconfig-language.txt subsection "Kconfig recursive dependency limitations" drivers/gpu/drm/Kconfig:36: symbol DRM_KMS_HELPER is selected by DRM_VIRTIO_GPU For a resolution refer to Documentation/kbuild/kconfig-language.txt subsection "Kconfig recursive dependency limitations" drivers/gpu/drm/virtio/Kconfig:1: symbol DRM_VIRTIO_GPU depends on VIRTIO For a resolution refer to Documentation/kbuild/kconfig-language.txt subsection "Kconfig recursive dependency limitations" drivers/virtio/Kconfig:1: symbol VIRTIO is selected by REMOTEPROC For a resolution refer to Documentation/kbuild/kconfig-language.txt subsection "Kconfig recursive dependency limitations" drivers/remoteproc/Kconfig:4: symbol REMOTEPROC is selected by ST_SLIM_REMOTEPROC For a resolution refer to Documentation/kbuild/kconfig-language.txt subsection "Kconfig recursive dependency limitations" drivers/remoteproc/Kconfig:103: symbol ST_SLIM_REMOTEPROC is selected by ST_FDMA For a resolution refer to Documentation/kbuild/kconfig-language.txt subsection "Kconfig recursive dependency limitations" drivers/dma/Kconfig:440:symbol ST_FDMA depends on DMADEVICES For a resolution refer to Documentation/kbuild/kconfig-language.txt subsection "Kconfig recursive dependency limitations" drivers/dma/Kconfig:5: symbol DMADEVICES is selected by SND_SOC_SH4_SIU For a resolution refer to Documentation/kbuild/kconfig-language.txt subsection "Kconfig recursive dependency limitations" sound/soc/sh/Kconfig:29:symbol SND_SOC_SH4_SIU is selected by SND_SIU_MIGOR For a resolution refer to Documentation/kbuild/kconfig-language.txt subsection "Kconfig recursive dependency limitations" sound/soc/sh/Kconfig:64:symbol SND_SIU_MIGOR depends on I2C For a resolution refer to Documentation/kbuild/kconfig-language.txt subsection "Kconfig recursive dependency limitations" drivers/i2c/Kconfig:7: symbol I2C is selected by FB_DDC For a resolution refer to Documentation/kbuild/kconfig-language.txt subsection "Kconfig recursive dependency limitations" drivers/video/fbdev/Kconfig:63: symbol FB_DDC is selected by FB_CYBER2000_DDC For a resolution refer to Documentation/kbuild/kconfig-language.txt subsection "Kconfig recursive dependency limitations" drivers/video/fbdev/Kconfig:378:symbol FB_CYBER2000_DDC depends on FB_CYBER2000 For a resolution refer to Documentation/kbuild/kconfig-language.txt subsection "Kconfig recursive dependency limitations" drivers/video/fbdev/Kconfig:366:symbol FB_CYBER2000 depends on FB which is due to drivers/gpu/drm/virtio/Kconfig depending on VIRTIO. Fix by dropping depend and switching to select VIRTIO. Signed-off-by: Peter Griffin --- drivers/gpu/drm/virtio/Kconfig | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/virtio/Kconfig b/drivers/gpu/drm/virtio/Kconfig index e1afc3d..90357d9 100644 --- a/drivers/gpu/drm/virtio/Kconfig +++ b/drivers/gpu/drm/virtio/Kconfig @@ -1,6 +1,7 @@ config DRM_VIRTIO_GPU tristate "Virtio GPU driver" - depends on DRM && VIRTIO + depends on DRM + select VIRTIO select DRM_KMS_HELPER select DRM_TTM help -- 1.9.1
[PATCH 5/6] drm/i915: Pass atomic state to verify_connector_state
From: Maarten Lankhorst
This gets rid of a warning that the connectors are used without locking
when doing a nonblocking modeset.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/intel_display.c | 23 ++-
1 file changed, 14 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index cd1f3fec5547..8eda324024c9 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -13479,11 +13479,14 @@ static void verify_wm_state(struct drm_crtc *crtc,
}
static void
-verify_connector_state(struct drm_device *dev, struct drm_crtc *crtc)
+verify_connector_state(struct drm_device *dev,
+ struct drm_atomic_state *state,
+ struct drm_crtc *crtc)
{
struct drm_connector *connector;
+ struct drm_connector_state *old_conn_state;
- drm_for_each_connector(connector, dev) {
+ for_each_connector_in_state(state, connector, old_conn_state, i) {
struct drm_encoder *encoder = connector->encoder;
struct drm_connector_state *state = connector->state;
@@ -13691,15 +13694,16 @@ verify_shared_dpll_state(struct drm_device *dev,
struct drm_crtc *crtc,
static void
intel_modeset_verify_crtc(struct drm_crtc *crtc,
-struct drm_crtc_state *old_state,
-struct drm_crtc_state *new_state)
+ struct drm_atomic_state *state,
+ struct drm_crtc_state *old_state,
+ struct drm_crtc_state *new_state)
{
if (!needs_modeset(new_state) &&
!to_intel_crtc_state(new_state)->update_pipe)
return;
verify_wm_state(crtc, new_state);
- verify_connector_state(crtc->dev, crtc);
+ verify_connector_state(crtc->dev, state, crtc);
verify_crtc_state(crtc, old_state, new_state);
verify_shared_dpll_state(crtc->dev, crtc, old_state, new_state);
}
@@ -13715,10 +13719,11 @@ verify_disabled_dpll_state(struct drm_device *dev)
}
static void
-intel_modeset_verify_disabled(struct drm_device *dev)
+intel_modeset_verify_disabled(struct drm_device *dev,
+ struct drm_atomic_state *state)
{
verify_encoder_state(dev);
- verify_connector_state(dev, NULL);
+ verify_connector_state(dev, state, NULL);
verify_disabled_dpll_state(dev);
}
@@ -14373,7 +14378,7 @@ static void intel_atomic_commit_tail(struct
drm_atomic_state *state)
if (IS_SKYLAKE(dev_priv) && !skl_can_enable_sagv(state))
skl_disable_sagv(dev_priv);
- intel_modeset_verify_disabled(dev);
+ intel_modeset_verify_disabled(dev, state);
}
/* Complete the events for pipes that have now been disabled */
@@ -14425,7 +14430,7 @@ static void intel_atomic_commit_tail(struct
drm_atomic_state *state)
if (put_domains[i])
modeset_put_power_domains(dev_priv, put_domains[i]);
- intel_modeset_verify_crtc(crtc, old_crtc_state, crtc->state);
+ intel_modeset_verify_crtc(crtc, state, old_crtc_state,
crtc->state);
}
if (IS_SKYLAKE(dev_priv) && intel_state->modeset &&
--
2.7.4
[PATCH 4/6] drm/i915: Update atomic modeset state synchronously
From: Maarten Lankhorst
All of this state should be updated as soon as possible. It shouldn't be
done later because then future updates may not depend on it.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/intel_display.c | 15 ---
1 file changed, 8 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index b79a20ff2dbe..cd1f3fec5547 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -14315,14 +14315,8 @@ static void intel_atomic_commit_tail(struct
drm_atomic_state *state)
drm_atomic_helper_wait_for_dependencies(state);
- if (intel_state->modeset) {
- memcpy(dev_priv->min_pixclk, intel_state->min_pixclk,
- sizeof(intel_state->min_pixclk));
- dev_priv->active_crtcs = intel_state->active_crtcs;
- dev_priv->atomic_cdclk_freq = intel_state->cdclk;
-
+ if (intel_state->modeset)
intel_display_power_get(dev_priv, POWER_DOMAIN_MODESET);
- }
for_each_crtc_in_state(state, crtc, old_crtc_state, i) {
struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
@@ -14532,6 +14526,13 @@ static int intel_atomic_commit(struct drm_device *dev,
intel_shared_dpll_commit(state);
intel_atomic_track_fbs(state);
+ if (intel_state->modeset) {
+ memcpy(dev_priv->min_pixclk, intel_state->min_pixclk,
+ sizeof(intel_state->min_pixclk));
+ dev_priv->active_crtcs = intel_state->active_crtcs;
+ dev_priv->atomic_cdclk_freq = intel_state->cdclk;
+ }
+
if (nonblock)
queue_work(system_unbound_wq, &state->commit_work);
else
--
2.7.4
[PATCH 3/6] drm/edid: Remove drm_select_eld
From: Maarten Lankhorst
The only user was i915, which is now gone.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/drm_edid.c | 26 --
include/drm/drm_edid.h | 1 -
2 files changed, 27 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 50541324a4ab..ce0caccfe384 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -3581,32 +3581,6 @@ int drm_av_sync_delay(struct drm_connector *connector,
EXPORT_SYMBOL(drm_av_sync_delay);
/**
- * drm_select_eld - select one ELD from multiple HDMI/DP sinks
- * @encoder: the encoder just changed display mode
- *
- * It's possible for one encoder to be associated with multiple HDMI/DP sinks.
- * The policy is now hard coded to simply use the first HDMI/DP sink's ELD.
- *
- * Return: The connector associated with the first HDMI/DP sink that has ELD
- * attached to it.
- */
-struct drm_connector *drm_select_eld(struct drm_encoder *encoder)
-{
- struct drm_connector *connector;
- struct drm_device *dev = encoder->dev;
-
- WARN_ON(!mutex_is_locked(&dev->mode_config.mutex));
- WARN_ON(!drm_modeset_is_locked(&dev->mode_config.connection_mutex));
-
- drm_for_each_connector(connector, dev)
- if (connector->encoder == encoder && connector->eld[0])
- return connector;
-
- return NULL;
-}
-EXPORT_SYMBOL(drm_select_eld);
-
-/**
* drm_detect_hdmi_monitor - detect whether monitor is HDMI
* @edid: monitor EDID information
*
diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h
index 919933d1beb4..f5278f813b61 100644
--- a/include/drm/drm_edid.h
+++ b/include/drm/drm_edid.h
@@ -327,7 +327,6 @@ int drm_edid_to_sad(struct edid *edid, struct cea_sad
**sads);
int drm_edid_to_speaker_allocation(struct edid *edid, u8 **sadb);
int drm_av_sync_delay(struct drm_connector *connector,
const struct drm_display_mode *mode);
-struct drm_connector *drm_select_eld(struct drm_encoder *encoder);
#ifdef CONFIG_DRM_LOAD_EDID_FIRMWARE
int drm_load_edid_firmware(struct drm_connector *connector);
--
2.7.4
[PATCH 2/6] pinctrl: sunxi: Add GR8 controller support
On Wed, Aug 31, 2016 at 4:18 PM, Maxime Ripard
wrote:
> From: Mylène Josserand
>
> Just like the other member of the sunxi family, let's add a pinctrl table
> for the muxing options.
>
> Signed-off-by: Mylène Josserand
> Signed-off-by: Maxime Ripard
> ---
> .../bindings/pinctrl/allwinner,sunxi-pinctrl.txt | 1 +
> drivers/pinctrl/sunxi/Kconfig | 4 +
> drivers/pinctrl/sunxi/Makefile | 1 +
> drivers/pinctrl/sunxi/pinctrl-gr8.c| 541
> +
> 4 files changed, 547 insertions(+)
> create mode 100644 drivers/pinctrl/sunxi/pinctrl-gr8.c
>
> diff --git
> a/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt
> b/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt
> index 69617220c5d6..1685821eea41 100644
> --- a/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt
> +++ b/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt
> @@ -23,6 +23,7 @@ Required properties:
>"allwinner,sun8i-h3-pinctrl"
>"allwinner,sun8i-h3-r-pinctrl"
>"allwinner,sun50i-a64-pinctrl"
> + "nextthing,gr8-pinctrl"
>
> - reg: Should contain the register physical address and length for the
>pin controller.
> diff --git a/drivers/pinctrl/sunxi/Kconfig b/drivers/pinctrl/sunxi/Kconfig
> index aaf075b972f5..bff1ffc6f01e 100644
> --- a/drivers/pinctrl/sunxi/Kconfig
> +++ b/drivers/pinctrl/sunxi/Kconfig
> @@ -17,6 +17,10 @@ config PINCTRL_SUN5I_A13
> def_bool MACH_SUN5I
> select PINCTRL_SUNXI
>
> +config PINCTRL_GR8
> + def_bool MACH_SUN5I
> + select PINCTRL_SUNXI_COMMON
> +
> config PINCTRL_SUN6I_A31
> def_bool MACH_SUN6I
> select PINCTRL_SUNXI
> diff --git a/drivers/pinctrl/sunxi/Makefile b/drivers/pinctrl/sunxi/Makefile
> index 2d8b64e222e0..95f93d0561fc 100644
> --- a/drivers/pinctrl/sunxi/Makefile
> +++ b/drivers/pinctrl/sunxi/Makefile
> @@ -5,6 +5,7 @@ obj-y += pinctrl-sunxi.o
> obj-$(CONFIG_PINCTRL_SUN4I_A10)+= pinctrl-sun4i-a10.o
> obj-$(CONFIG_PINCTRL_SUN5I_A10S) += pinctrl-sun5i-a10s.o
> obj-$(CONFIG_PINCTRL_SUN5I_A13)+= pinctrl-sun5i-a13.o
> +obj-$(CONFIG_PINCTRL_GR8) += pinctrl-gr8.o
> obj-$(CONFIG_PINCTRL_SUN6I_A31)+= pinctrl-sun6i-a31.o
> obj-$(CONFIG_PINCTRL_SUN6I_A31S) += pinctrl-sun6i-a31s.o
> obj-$(CONFIG_PINCTRL_SUN6I_A31_R) += pinctrl-sun6i-a31-r.o
> diff --git a/drivers/pinctrl/sunxi/pinctrl-gr8.c
> b/drivers/pinctrl/sunxi/pinctrl-gr8.c
> new file mode 100644
> index ..2904d2b7378b
> --- /dev/null
> +++ b/drivers/pinctrl/sunxi/pinctrl-gr8.c
> @@ -0,0 +1,541 @@
> +/*
> + * NextThing GR8 SoCs pinctrl driver.
> + *
> + * Copyright (C) 2016 Mylene Josserand
> + *
> + * Based on pinctrl-sun5i-a13.c
> + *
> + * Mylene Josserand
> + *
> + * This file is licensed under the terms of the GNU General Public
> + * License version 2. This program is licensed "as is" without any
> + * warranty of any kind, whether express or implied.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include "pinctrl-sunxi.h"
> +
> +static const struct sunxi_desc_pin sun5i_gr8_pins[] = {
> + /* Hole */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(B, 0),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "i2c0")), /* SCK */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(B, 1),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "i2c0")), /* SDA */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(B, 2),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "pwm0"),
> + SUNXI_FUNCTION(0x3, "spdif"), /* DO */
> + SUNXI_FUNCTION_IRQ(0x6, 16)), /* EINT16 */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(B, 3),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "ir0"), /* TX */
> + SUNXI_FUNCTION_IRQ(0x6, 17)), /* EINT17 */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(B, 4),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "ir0"), /* RX */
> + SUNXI_FUNCTION_IRQ(0x6, 18)), /* EINT18 */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(B, 5),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "i2s0"), /* MCLK */
> + SUNXI_FUNCTION_IRQ(0x6, 19)), /* EINT19 */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(B, 6),
> +
[PATCH v8 15/18] ARM: STi: DT: STiH407: Add uniperif reader dt nodes
Hello ptere, Lee,
Thanks for your remarks,
Regards
Arnaud
On 08/31/2016 01:28 PM, Lee Jones wrote:
> On Tue, 30 Aug 2016, Peter Griffin wrote:
>> Thanks for reviewing and your very valuable feedback.
>> On Tue, 30 Aug 2016, Lee Jones wrote:
>>> On Fri, 26 Aug 2016, Peter Griffin wrote:
>>>
This patch adds the DT node for the uniperif reader
IP block found on STiH407 family silicon.
Signed-off-by: Arnaud Pouliquen
Signed-off-by: Peter Griffin
---
arch/arm/boot/dts/stih407-family.dtsi | 26 ++
1 file changed, 26 insertions(+)
diff --git a/arch/arm/boot/dts/stih407-family.dtsi
b/arch/arm/boot/dts/stih407-family.dtsi
index d263c96..bdddf2c 100644
--- a/arch/arm/boot/dts/stih407-family.dtsi
+++ b/arch/arm/boot/dts/stih407-family.dtsi
@@ -956,5 +956,31 @@
st,version = <5>;
st,mode = "SPDIF";
};
+
+ sti_uni_reader0: sti-uni-reader at 0 {
+ compatible = "st,sti-uni-reader";
+ status = "disabled";
>>>
>>> I find it's normally nicer to place the status of the node at the
>>> bottom, separated by a '\n'.
>>
>> Ok I'll add a superflous '\n' in the next version.
>
> Everyone loves a smart arse!
>
> In this case I believe the '\n' to be a functional separator and not
> superfluous at all.
>
+ dai-name = "Uni Reader #0 (PCM IN)";
>>>
>>> Oooo, not seen something like this before.
>>>
>>> If it does not already have one, it would require a DT Ack.
>>
>> No idea, the driver got merged 1 year ago.
This field could be suppressed and handled in source code, using
st,uniperiph-id to retreive it.
>>
>> Arnaud did you get a DT ack when you merged this driver & binding? i if i
>> remember well, i had sent to Alsa mailing list only, I missed
this obvious...
>>>
+ st,version = <3>;
>>>
>>> This will likely need a DT Ack too. We usually encode this sort of
>>> information in the compatible string.
yes, better to use compatibility
>>
>> See 05c1b4480e86a871b18030d6f3d532dc0ecdf38c
>
> Well Rob's the boss. We certainly never used to take 'device ID' or
> 'version' attributes. I guess something must have changed.
I will try to provide patches for code and bindings rework this week.
[PATCH v9 00/19] Add support for FDMA DMA controller and slim core rproc found on STi chipsets
Hi Vinod, Bjorn, Patrice, This patchset adds support for the Flexible Direct Memory Access (FDMA) core found on STi chipsets from STMicroelectronics. The FDMA is a slim core CPU with a dedicated firmware. It is a general purpose DMA controller supporting 16 independent channels and data can be moved from memory to memory or between memory and paced latency critical real time targets. After quite a few review rounds, I'm hoping this series can get taken for v4.9. After some discussion with the DT maintainers I've removed the firmware name from DT, and now generate the name based on the compatible string. I've also dropped the dma xbar support for the moment, as I believe it should be re-worked based on some of the xbar API's that TI recently added. V3 also included some updates to the ASoC st,sti-asoc-card.txt DT documentation to make the doc align with the driver code. These patches have already been applied and are now dropped from this series. Other changes included enabling the ASoC drivers in multi_v7 defconfig and adding DT patches for Patrices STi DT tree to enable ASoC on STiH407/10 based platforms using the fdma driver. v4 includes a new slim core rproc driver for loading the slim elf firmware. This enables us to use the generic rproc elf loading code. This has deliberately not been implemented as a platform_driver, to avoid having to have double mappings of I/O memory from two device drivers, and also to ensure that the DT node reflects the actual hardware rather than Linux subsystems. The slim core is the basis for various pieces of IP in STi chipsets and the intention is that other drivers (e.g. demux) can also be migrated over to using the slim rproc for their elf firmware loading and start/stop control. v5 includes various updates from Bjorn related to the slim rproc implementation. It also includes a patch to make rsc_table optional in remoteproc_core and various other cleanups and review feedback from Vinod to do with the actual fdma implementation. It also fixes a regression introduced in v4 when all drivers are built-in spotted by Aranud. v6 goes back to having a dummy rsc_table and fixes some kbuild warnings. However a change is still required in rproc core when all drivers are built-in as the initial async firmware resource table parsing can fail when built-in, which causes subsequent calls to rproc_boot() to also fail. V6 changes this behaviour to retry rproc_fw_config_virtio() from rproc_boot(), in cases where it previously failed, as at this point we know the irmwaref has been successfully obtained. v7 removes all remoteproc core changes required to get -EPROBE_DEFER working properly when firmware resides on a rootfs and compiling as built-in. The fdma driver now relies on the firmware being available in the initramfs when building fdma as built-in. This has been tested and works well. If remoteproc subsystem implements a new mechanism for firmware on late mounted root filesystems, we can migrate this driver over to use it at that point. v8 actions some review feedback from Bjorn to the slim rproc driver, and also includes a patch which fixes a recursive Kconfig error which is triggered when st_fdma selects slim_rproc driver. The series has also been rebased on v4.8-rc3. v9 actions some review feedback from Bjorn, Lee and Vinod. See below. Importantly a bug was found during testing now that the platform boots without clk_ignore_unused parameter whereby the clocks would not be enabled properly before firmware loading was attempted. regards, Peter. Changes since v8: - Add MODULE_ALIAS (Vinod) - devm_kzalloc to devm_kcalloc (Vinod) - quisce tasklet initialised by vchan_init() (Vinod) - Don't make SLIM rproc user selectable (Bjorn) - slim_rproc: Ensure clocks enabled before firmware load (Peter) - Various code style nits / commit message change (Lee) - Separate patch for '\n' kconfig removal (Vinod) Changes since v7: - Rebase on v4.8-rc3 (Peter) - Double check that len is <= mem[i].size (Bjorn) - Remove if (!fw) checks (Bjorn) - Omit reference from fw_ops struct (Bjorn) - Call rproc_del() before rproc_put() (Bjorn) - Fix some odd line breaks (Bjorn) - Rename SLIM_* and slim_* with st prefix (Bjorn) Changes since v6: - Fix recursive Kconfig warning (Patrice) - Fix various Intel zero day compiler warnings - Remove all changes related to late firmware load (now relies on initramfs) (Peter) Changes since v5: - Remove optional rsc table and go back to dummy resource table (Bjorn) - Retry rproc_fw_config_virtio() from rproc_boot() if previously failed (Peter) - Fixup some kbuild warnings - rebase on v4.7-rc5 - Remove some patches which were merged via ASoC tree Changes since v4: - Make rsc table optional in remoteproc (Peter) - Various fixups to STi audio DT nodes (Arnaud) - Bulk rename of xp70 to slim (Peter) - Update my email to @linaro.org (Lee) - rebase on v4.7-rc2 (Peter) - Don't make ST_SLIM_REMOTEPROC user selectable (Bjor
[PATCH v9 01/19] remoteproc: st_slim_rproc: add a slimcore rproc driver
slim core is used as a basis for many IPs in the STi
chipsets such as fdma and demux. To avoid duplicating
the elf loading code in each device driver a slim
rproc driver has been created.
This driver is designed to be used by other device drivers
such as fdma, or demux whose IP is based around a slim core.
The device driver can call slim_rproc_alloc() to allocate
a slim rproc and slim_rproc_put() when finished.
This driver takes care of ioremapping the slim
registers (dmem, imem, slimcore, peripherals), whose offsets
and sizes can change between IP's. It also obtains and enables
any clocks used by the device. This approach avoids having
a double mapping of the registers as slim_rproc does not register
its own platform device. It also maps well to device tree
abstraction as it allows us to have one dt node for the whole
device.
All of the generic rproc elf loading code can be reused, and
we provide start() stop() hooks to start and stop the slim
core once the firmware has been loaded. This has been tested
successfully with fdma driver.
Signed-off-by: Peter Griffin
---
drivers/remoteproc/Kconfig | 4 +
drivers/remoteproc/Makefile | 1 +
drivers/remoteproc/st_slim_rproc.c | 364 +++
include/linux/remoteproc/st_slim_rproc.h | 58 +
4 files changed, 427 insertions(+)
create mode 100644 drivers/remoteproc/st_slim_rproc.c
create mode 100644 include/linux/remoteproc/st_slim_rproc.h
diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
index 1a8bf76a..a7bedc6 100644
--- a/drivers/remoteproc/Kconfig
+++ b/drivers/remoteproc/Kconfig
@@ -100,4 +100,8 @@ config ST_REMOTEPROC
processor framework.
This can be either built-in or a loadable module.
+config ST_SLIM_REMOTEPROC
+ tristate
+ select REMOTEPROC
+
endmenu
diff --git a/drivers/remoteproc/Makefile b/drivers/remoteproc/Makefile
index 92d3758..db1dae7 100644
--- a/drivers/remoteproc/Makefile
+++ b/drivers/remoteproc/Makefile
@@ -14,3 +14,4 @@ obj-$(CONFIG_DA8XX_REMOTEPROC)+=
da8xx_remoteproc.o
obj-$(CONFIG_QCOM_MDT_LOADER) += qcom_mdt_loader.o
obj-$(CONFIG_QCOM_Q6V5_PIL)+= qcom_q6v5_pil.o
obj-$(CONFIG_ST_REMOTEPROC)+= st_remoteproc.o
+obj-$(CONFIG_ST_SLIM_REMOTEPROC) += st_slim_rproc.o
diff --git a/drivers/remoteproc/st_slim_rproc.c
b/drivers/remoteproc/st_slim_rproc.c
new file mode 100644
index 000..1484e97
--- /dev/null
+++ b/drivers/remoteproc/st_slim_rproc.c
@@ -0,0 +1,364 @@
+/*
+ * SLIM core rproc driver
+ *
+ * Copyright (C) 2016 STMicroelectronics
+ *
+ * Author: Peter Griffin
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include "remoteproc_internal.h"
+
+/* SLIM core registers */
+#define SLIM_ID_OFST 0x0
+#define SLIM_VER_OFST 0x4
+
+#define SLIM_EN_OFST 0x8
+#define SLIM_EN_RUNBIT(0)
+
+#define SLIM_CLK_GATE_OFST 0xC
+#define SLIM_CLK_GATE_DIS BIT(0)
+#define SLIM_CLK_GATE_RESETBIT(2)
+
+#define SLIM_SLIM_PC_OFST 0x20
+
+/* DMEM registers */
+#define SLIM_REV_ID_OFST 0x0
+#define SLIM_REV_ID_MIN_MASK GENMASK(15, 8)
+#define SLIM_REV_ID_MIN(id)((id & SLIM_REV_ID_MIN_MASK) >> 8)
+#define SLIM_REV_ID_MAJ_MASK GENMASK(23, 16)
+#define SLIM_REV_ID_MAJ(id)((id & SLIM_REV_ID_MAJ_MASK) >> 16)
+
+
+/* peripherals registers */
+#define SLIM_STBUS_SYNC_OFST 0xF88
+#define SLIM_STBUS_SYNC_DISBIT(0)
+
+#define SLIM_INT_SET_OFST 0xFD4
+#define SLIM_INT_CLR_OFST 0xFD8
+#define SLIM_INT_MASK_OFST 0xFDC
+
+#define SLIM_CMD_CLR_OFST 0xFC8
+#define SLIM_CMD_MASK_OFST 0xFCC
+
+static const char *mem_names[ST_SLIM_MEM_MAX] = {
+ [ST_SLIM_DMEM] = "dmem",
+ [ST_SLIM_IMEM] = "imem",
+};
+
+static int slim_clk_get(struct st_slim_rproc *slim_rproc, struct device *dev)
+{
+ int clk, err;
+
+ for (clk = 0; clk < ST_SLIM_MAX_CLK; clk++) {
+ slim_rproc->clks[clk] = of_clk_get(dev->of_node, clk);
+ if (IS_ERR(slim_rproc->clks[clk])) {
+ err = PTR_ERR(slim_rproc->clks[clk]);
+ if (err == -EPROBE_DEFER)
+ goto err_put_clks;
+ slim_rproc->clks[clk] = NULL;
+ break;
+ }
+ }
+
+ return 0;
+
+err_put_clks:
+ while (--clk >= 0)
+ clk_put(slim_rproc->clks[clk]);
+
+ return err;
+}
+
+static void slim_clk_disable(struct st_slim_rproc *slim_rproc)
+{
+ int clk;
+
+ for (clk = 0; clk < ST_SLIM
[PATCH v9 12/19] ARM: DT: STiH407: Add spdif_out pinctrl config
This patch adds the pinctrl config for the spidf out
pins used by the sasg codec IP.
Signed-off-by: Arnaud Pouliquen
Signed-off-by: Peter Griffin
Acked-by: Lee Jones
---
arch/arm/boot/dts/stih407-pinctrl.dtsi | 8
1 file changed, 8 insertions(+)
diff --git a/arch/arm/boot/dts/stih407-pinctrl.dtsi
b/arch/arm/boot/dts/stih407-pinctrl.dtsi
index 537db7e..598dbab 100644
--- a/arch/arm/boot/dts/stih407-pinctrl.dtsi
+++ b/arch/arm/boot/dts/stih407-pinctrl.dtsi
@@ -1114,6 +1114,14 @@
};
};
+ spdif_out {
+ pinctrl_spdif_out: spdif_out{
+ st,pins {
+ spdif_out = <&pio34 7 ALT1 OUT>;
+ };
+ };
+ };
+
serial3 {
pinctrl_serial3: serial3-0 {
st,pins {
--
1.9.1
[PATCH v9 13/19] ARM: STi: DT: STiH407: Add sti-sasg-codec dt node
This patch adds the dt node for the internal audio
codec IP.
Signed-off-by: Arnaud Pouliquen
Signed-off-by: Peter Griffin
---
arch/arm/boot/dts/stih407-family.dtsi | 7 +++
1 file changed, 7 insertions(+)
diff --git a/arch/arm/boot/dts/stih407-family.dtsi
b/arch/arm/boot/dts/stih407-family.dtsi
index 45cab30..d1258d5 100644
--- a/arch/arm/boot/dts/stih407-family.dtsi
+++ b/arch/arm/boot/dts/stih407-family.dtsi
@@ -873,5 +873,12 @@
<&clk_s_c0_flexgen CLK_TX_ICN_DISP_0>,
<&clk_s_c0_flexgen CLK_EXT2F_A9>;
};
+
+ sti_sasg_codec: sti-sasg-codec {
+ compatible = "st,stih407-sas-codec";
+ #sound-dai-cells = <1>;
+ status = "disabled";
+ st,syscfg = <&syscfg_core>;
+ };
};
};
--
1.9.1
[PATCH v9 15/19] ARM: STi: DT: STiH407: Add uniperif reader dt nodes
This patch adds the DT node for the uniperif reader
IP block found on STiH407 family silicon.
Signed-off-by: Arnaud Pouliquen
Signed-off-by: Peter Griffin
---
arch/arm/boot/dts/stih407-family.dtsi | 28
1 file changed, 28 insertions(+)
diff --git a/arch/arm/boot/dts/stih407-family.dtsi
b/arch/arm/boot/dts/stih407-family.dtsi
index 1edc36c..883019a 100644
--- a/arch/arm/boot/dts/stih407-family.dtsi
+++ b/arch/arm/boot/dts/stih407-family.dtsi
@@ -960,5 +960,33 @@
status = "disabled";
};
+
+ sti_uni_reader0: sti-uni-reader at 8d83000 {
+ compatible = "st,sti-uni-reader";
+ #sound-dai-cells = <0>;
+ st,syscfg = <&syscfg_core>;
+ reg = <0x8d83000 0x158>;
+ interrupts = ;
+ dmas = <&fdma0 5 0 1>;
+ dma-names = "rx";
+ dai-name = "Uni Reader #0 (PCM IN)";
+ st,version = <3>;
+
+ status = "disabled";
+ };
+
+ sti_uni_reader1: sti-uni-reader at 8d84000 {
+ compatible = "st,sti-uni-reader";
+ #sound-dai-cells = <0>;
+ st,syscfg = <&syscfg_core>;
+ reg = <0x8d84000 0x158>;
+ interrupts = ;
+ dmas = <&fdma0 6 0 1>;
+ dma-names = "rx";
+ dai-name = "Uni Reader #1 (HDMI RX)";
+ st,version = <3>;
+
+ status = "disabled";
+ };
};
};
--
1.9.1
[PATCH v9 18/19] drm/virtio: kconfig: Fixup white space.
Use tabs instead of spaces. Signed-off-by: Peter Griffin Acked-by: Lee Jones --- drivers/gpu/drm/virtio/Kconfig | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/virtio/Kconfig b/drivers/gpu/drm/virtio/Kconfig index 90357d9..2d83932 100644 --- a/drivers/gpu/drm/virtio/Kconfig +++ b/drivers/gpu/drm/virtio/Kconfig @@ -2,10 +2,10 @@ config DRM_VIRTIO_GPU tristate "Virtio GPU driver" depends on DRM select VIRTIO -select DRM_KMS_HELPER -select DRM_TTM + select DRM_KMS_HELPER + select DRM_TTM help This is the virtual GPU driver for virtio. It can be used with - QEMU based VMMs (like KVM or Xen). + QEMU based VMMs (like KVM or Xen). If unsure say M. -- 1.9.1
[PATCH v9 10/19] ARM: DT: STiH407: Add i2s_out pinctrl configuration
This patch adds the pinctrl config for the i2s_out pins
used by the uniperif player IP.
Signed-off-by: Arnaud Pouliquen
Signed-off-by: Peter Griffin
Acked-by: Lee Jones
---
arch/arm/boot/dts/stih407-pinctrl.dtsi | 23 +++
1 file changed, 23 insertions(+)
diff --git a/arch/arm/boot/dts/stih407-pinctrl.dtsi
b/arch/arm/boot/dts/stih407-pinctrl.dtsi
index a538ae5..0fb5c8a 100644
--- a/arch/arm/boot/dts/stih407-pinctrl.dtsi
+++ b/arch/arm/boot/dts/stih407-pinctrl.dtsi
@@ -1067,6 +1067,29 @@
};
};
+ i2s_out {
+ pinctrl_i2s_8ch_out: i2s_8ch_out{
+ st,pins {
+ mclk = <&pio33 5 ALT1 OUT>;
+ lrclk = <&pio33 7 ALT1 OUT>;
+ sclk = <&pio33 6 ALT1 OUT>;
+ data0 = <&pio33 4 ALT1 OUT>;
+ data1 = <&pio34 0 ALT1 OUT>;
+ data2 = <&pio34 1 ALT1 OUT>;
+ data3 = <&pio34 2 ALT1 OUT>;
+ };
+ };
+
+ pinctrl_i2s_2ch_out: i2s_2ch_out{
+ st,pins {
+ mclk = <&pio33 5 ALT1 OUT>;
+ lrclk = <&pio33 7 ALT1 OUT>;
+ sclk = <&pio33 6 ALT1 OUT>;
+ data0 = <&pio33 4 ALT1 OUT>;
+ };
+ };
+ };
+
serial3 {
pinctrl_serial3: serial3-0 {
st,pins {
--
1.9.1
[PATCH v9 19/19] dmaengine: kconfig: Remove superfluous '\n'
Remove the extra '\n' between kconfig entries. Signed-off-by: Peter Griffin --- drivers/dma/Kconfig | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig index 7c5d946..5b5a341 100644 --- a/drivers/dma/Kconfig +++ b/drivers/dma/Kconfig @@ -462,7 +462,6 @@ config STM32_DMA If you have a board based on such a MCU and wish to use DMA say Y or M here. - config S3C24XX_DMAC bool "Samsung S3C24XX DMA support" depends on ARCH_S3C24XX -- 1.9.1
[PATCH v9 04/19] dmaengine: st_fdma: Add STMicroelectronics FDMA driver header file
This header file will also be used by the dma xbar driver in the
future.
Signed-off-by: Ludovic Barre
Signed-off-by: Peter Griffin
---
drivers/dma/st_fdma.h | 249 ++
1 file changed, 249 insertions(+)
create mode 100644 drivers/dma/st_fdma.h
diff --git a/drivers/dma/st_fdma.h b/drivers/dma/st_fdma.h
new file mode 100644
index 000..c58e00d
--- /dev/null
+++ b/drivers/dma/st_fdma.h
@@ -0,0 +1,249 @@
+/*
+ * DMA driver header for STMicroelectronics STi FDMA controller
+ *
+ * Copyright (C) 2014 STMicroelectronics
+ *
+ * Author: Ludovic Barre
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+#ifndef __DMA_ST_FDMA_H
+#define __DMA_ST_FDMA_H
+
+#include
+#include
+#include
+#include
+#include "virt-dma.h"
+
+#define ST_FDMA_NR_DREQS 32
+#define FW_NAME_SIZE 30
+#define DRIVER_NAME "st-fdma"
+
+/**
+ * struct st_fdma_generic_node - Free running/paced generic node
+ *
+ * @length: Length in bytes of a line in a 2D mem to mem
+ * @sstride: Stride, in bytes, between source lines in a 2D data move
+ * @dstride: Stride, in bytes, between destination lines in a 2D data move
+ */
+struct st_fdma_generic_node {
+ u32 length;
+ u32 sstride;
+ u32 dstride;
+};
+
+/**
+ * struct st_fdma_hw_node - Node structure used by fdma hw
+ *
+ * @next: Pointer to next node
+ * @control: Transfer Control Parameters
+ * @nbytes: Number of Bytes to read
+ * @saddr: Source address
+ * @daddr: Destination address
+ *
+ * @generic: generic node for free running/paced transfert type
+ * 2 others transfert type are possible, but not yet implemented
+ *
+ * The NODE structures must be aligned to a 32 byte boundary
+ */
+struct st_fdma_hw_node {
+ u32 next;
+ u32 control;
+ u32 nbytes;
+ u32 saddr;
+ u32 daddr;
+ union {
+ struct st_fdma_generic_node generic;
+ };
+} __aligned(32);
+
+/*
+ * node control parameters
+ */
+#define FDMA_NODE_CTRL_REQ_MAP_MASKGENMASK(4, 0)
+#define FDMA_NODE_CTRL_REQ_MAP_FREE_RUN0x0
+#define FDMA_NODE_CTRL_REQ_MAP_DREQ(n) ((n)&FDMA_NODE_CTRL_REQ_MAP_MASK)
+#define FDMA_NODE_CTRL_REQ_MAP_EXT FDMA_NODE_CTRL_REQ_MAP_MASK
+#define FDMA_NODE_CTRL_SRC_MASKGENMASK(6, 5)
+#define FDMA_NODE_CTRL_SRC_STATIC BIT(5)
+#define FDMA_NODE_CTRL_SRC_INCRBIT(6)
+#define FDMA_NODE_CTRL_DST_MASKGENMASK(8, 7)
+#define FDMA_NODE_CTRL_DST_STATIC BIT(7)
+#define FDMA_NODE_CTRL_DST_INCRBIT(8)
+#define FDMA_NODE_CTRL_SECURE BIT(15)
+#define FDMA_NODE_CTRL_PAUSE_EON BIT(30)
+#define FDMA_NODE_CTRL_INT_EON BIT(31)
+
+/**
+ * struct st_fdma_sw_node - descriptor structure for link list
+ *
+ * @pdesc: Physical address of desc
+ * @node: link used for putting this into a channel queue
+ */
+struct st_fdma_sw_node {
+ dma_addr_t pdesc;
+ struct st_fdma_hw_node *desc;
+};
+
+#define NAME_SZ 10
+
+struct st_fdma_driverdata {
+ u32 id;
+ char name[NAME_SZ];
+};
+
+struct st_fdma_desc {
+ struct virt_dma_desc vdesc;
+ struct st_fdma_chan *fchan;
+ bool iscyclic;
+ unsigned int n_nodes;
+ struct st_fdma_sw_node node[];
+};
+
+enum st_fdma_type {
+ ST_FDMA_TYPE_FREE_RUN,
+ ST_FDMA_TYPE_PACED,
+};
+
+struct st_fdma_cfg {
+ struct device_node *of_node;
+ enum st_fdma_type type;
+ dma_addr_t dev_addr;
+ enum dma_transfer_direction dir;
+ int req_line; /* request line */
+ long req_ctrl; /* Request control */
+};
+
+struct st_fdma_chan {
+ struct st_fdma_dev *fdev;
+ struct dma_pool *node_pool;
+ struct dma_slave_config scfg;
+ struct st_fdma_cfg cfg;
+
+ int dreq_line;
+
+ struct virt_dma_chan vchan;
+ struct st_fdma_desc *fdesc;
+ enum dma_status status;
+};
+
+struct st_fdma_dev {
+ struct device *dev;
+ const struct st_fdma_driverdata *drvdata;
+ struct dma_device dma_device;
+
+ struct st_slim_rproc *slim_rproc;
+
+ int irq;
+
+ struct st_fdma_chan *chans;
+
+ spinlock_t dreq_lock;
+ unsigned long dreq_mask;
+
+ u32 nr_channels;
+ char fw_name[FW_NAME_SIZE];
+};
+
+/* Peripheral Registers*/
+
+#define FDMA_CMD_STA_OFST 0xFC0
+#define FDMA_CMD_SET_OFST 0xFC4
+#define FDMA_CMD_CLR_OFST 0xFC8
+#define FDMA_CMD_MASK_OFST 0xFCC
+#define FDMA_CMD_START(ch) (0x1 << (ch << 1))
+#define FDMA_CMD_PAUSE(ch) (0x2 << (ch << 1))
+#define FDMA_CMD_FLUSH(ch) (0x3 << (ch << 1))
+
+#define FDMA_INT_STA_OFST 0xFD0
+#define FDMA_INT_STA_CH0x1
+#define FDMA_INT_STA_ERR 0x2
+
+#define FDMA_INT_SET_OFST
[PATCH v9 07/19] MAINTAINERS: Add FDMA driver files to STi section.
This patch adds the FDMA driver files to the STi section of the maintainers file. Signed-off-by: Peter Griffin Acked-by: Lee Jones --- MAINTAINERS | 1 + 1 file changed, 1 insertion(+) diff --git a/MAINTAINERS b/MAINTAINERS index 5dd3b24..d21a7b5 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -1739,6 +1739,7 @@ F:drivers/char/hw_random/st-rng.c F: drivers/clocksource/arm_global_timer.c F: drivers/clocksource/clksrc_st_lpc.c F: drivers/cpufreq/sti-cpufreq.c +F: drivers/dma/st_fdma* F: drivers/i2c/busses/i2c-st.c F: drivers/media/rc/st_rc.c F: drivers/media/platform/sti/c8sectpfe/ -- 1.9.1
[PATCH] drm: modify drm_global_item_ref to avoid two times of writing ref->object
In previous drm_global_item_ref, there are two times of writing
ref->object if item->refcount is 0. So this patch does a minor update
to put alloc and init ref firstly, and then to modify the item of glob
array. Use "else" to avoid two times of writing ref->object. It can
make the code logic more clearly.
Signed-off-by: Huang Rui
---
drivers/gpu/drm/drm_global.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/drm_global.c b/drivers/gpu/drm/drm_global.c
index 3d2e91c..3abe738 100644
--- a/drivers/gpu/drm/drm_global.c
+++ b/drivers/gpu/drm/drm_global.c
@@ -70,25 +70,25 @@ int drm_global_item_ref(struct drm_global_reference *ref)
mutex_lock(&item->mutex);
if (item->refcount == 0) {
- item->object = kzalloc(ref->size, GFP_KERNEL);
- if (unlikely(item->object == NULL)) {
+ ref->object = kzalloc(ref->size, GFP_KERNEL);
+ if (unlikely(ref->object == NULL)) {
ret = -ENOMEM;
goto out_err;
}
-
- ref->object = item->object;
ret = ref->init(ref);
if (unlikely(ret != 0))
goto out_err;
- }
+ item->object = ref->object;
+ } else
+ ref->object = item->object;
+
++item->refcount;
- ref->object = item->object;
mutex_unlock(&item->mutex);
return 0;
out_err:
mutex_unlock(&item->mutex);
- item->object = NULL;
+ ref->object = NULL;
return ret;
}
EXPORT_SYMBOL(drm_global_item_ref);
--
2.7.4
[PATCH] drm/fsl-dcu: Add gamma set for crtc
Hi Stefan, > > > > This is a errta for DCU, Gamma registers are supposed to be big > > endian, but actually it is little endian, do we > > Really need to create a second regmap? > > Do you have the exact wording of the errata? Below is the description from hardware team. Affects: 2D-ACE Description: Gamma_R, Gamma_G and Gamma_B registers are little-endian registers while the rest of the address-space in 2D-ACE is big-endian. 2D-ACE Gamma_R, Gamma_G and Gamma_B registers are 32 bit registers, where the first 24 bits are reserved and last 8 bits denote the gamma value. Because of a connection issue in the device, the first 8-bit [31:24] is connected and the rest of the 24-bits[23:0] are reserved. Impact: Gamma registers are not configurable. Workaround: Perform the byte_swapping for Gamma_[R/G/B]_registers. For example: While writing _00ABh to any of the gamma registers, byte swap the data so it results in AB00_h. Write this value to the gamma register. > > There are two problems to the current approach: First, the two byte > swaps (yours and then the byte swap due to the big-endian configuration > of regmap) seems ugly to me. Second, the gamma value is the lowest byte > in Vybrid, and on Vybrid the regmap is configured little-endian. Hence > your code won't work on Vybrid... Therefor I still think that using a > second regmap would be nicer. > Oh sorry, I ignored there are two platforms. Using regmap according to DTS is nicer. Best Regards, Meng
[PATCH v4 0/4] IPUv3 prep for i.MX5/6 v4l2 staging drivers, v4
Hi Philipp, On Thu, Aug 25, 2016 at 11:17 AM, Tim Harvey wrote: > Philipp, > > Have you had a chance to review this last series of Steve's submitted > last week? We are down to 4 patches in gpu/ipu-v3 needed in order to > get his IMX5/6 capture driver into staging and the sooner we do that > the sooner we can get more testing and additional support/features for > it. Do these patches look good to you? It would be nice to get them into 4.9 if possible. Thanks
[Bug 97119] screen flickerin under KDE when compositor was dis- and reenabled
https://bugs.freedesktop.org/show_bug.cgi?id=97119 --- Comment #16 from Christoph Haag --- I've seen similar flickering with kwin 5.7.4 from archlinux: https://www.youtube.com/watch?v=EnzI7dmjihI With latest kwin git it does not happen anymore. So if anyone wants to try it an confirm whether kwin git fixes it: you only need kwayland git, the rest of kde plasma can stay on the latest release version. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160905/5245a565/attachment.html>
[PATCH v8 15/18] ARM: STi: DT: STiH407: Add uniperif reader dt nodes
On Mon, 05 Sep 2016, Arnaud Pouliquen wrote: > +dai-name = "Uni Reader #0 (PCM IN)"; > >>> > >>> Oooo, not seen something like this before. > >>> > >>> If it does not already have one, it would require a DT Ack. > >> > >> No idea, the driver got merged 1 year ago. > This field could be suppressed and handled in source code, using > st,uniperiph-id to retreive it. That would be better. > >> Arnaud did you get a DT ack when you merged this driver & binding? i if i > >> remember well, i had sent to Alsa mailing list only, I missed > this obvious... I'm surprised Mark didn't notice this. He's usually pretty good at picking stuff like that up. > +st,version = <3>; > >>> > >>> This will likely need a DT Ack too. We usually encode this sort of > >>> information in the compatible string. > yes, better to use compatibility > >> > >> See 05c1b4480e86a871b18030d6f3d532dc0ecdf38c > > > > Well Rob's the boss. We certainly never used to take 'device ID' or > > 'version' attributes. I guess something must have changed. > > I will try to provide patches for code and bindings rework this week. Wonderful.. Thanks Arnaud. -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org â Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog
[PATCH v5 4/7] video: add generic framebuffer eviction
Den 05.09.2016 13:19, skrev David Herrmann:
> Hi
>
> On Sat, Sep 3, 2016 at 2:06 PM, Noralf Trønnes wrote:
>> Den 02.09.2016 10:22, skrev David Herrmann:
>>> There are several situations where we want hardware handover from an early
>>> boot GFX driver (e.g., vgacon, vesafb, efifb, simplefb) to a full fletched
>>> GFX driver (e.g., most DRM drivers). So far, we relied on
>>> remove_conflicting_framebuffers() to do this for us, however, this had a
>>> bunch of downsides:
>>>
>>> o It only removes conflicting fbdev drivers. It does not drop vgacon,
>>> early boot console drivers, conflicting DRM drivers, etc.
>>>
>>> o It only unloads the fbdev driver, it does not modify the underlying
>>> device or resources. In case of "screen_info" drivers (e.g., efifb)
>>> this is fine, since no resources are pinned. However, if the driver
>>> binds to a platform-device like "simple-framebuffer", we must make
>>> sure to unregister that device as well. Otherwise, pinned resources
>>> like IORESOURCE_MEM stay around, triggering WARN_ONs if the following
>>> driver requests those resources.
>>>
>>> o It is only available if CONFIG_FB is selected.
>>>
>>> This commit adds a new infrastructure that manages system-framebuffers
>>> (short: sysfb). The initial commit provides conflict-resolution for
>>> system-framebuffers. At its core it provides sysfb_evict_conflicts(),
>>> which implements conflict detection and removal for all known types of
>>> GFX driver hand-overs. So far, this includes platform-device removal,
>>> fbdev-firmware-device removal, vgacon removal and VBE detection. To
>>> further simplify the callers, it also provides helpers to figure out what
>>> hand-over to do, based on the device the new drivers binds to:
>>>
>>> o PCI drivers can use sysfb_evict_conflicts_pci(), which will figure
>>> out
>>> the apertures automatically, and does VGA/VBE detection.
>>>
>>> o Generic firmware drivers that might be shadowed at any address in
>>> memory can use sysfb_evict_conflicts_firmware(), basically removing
>>> *all* firmware framebuffers in effect.
>>>
>>> This only adds the generic sysfb helpers. No users are converted, yet.
>>>
>>> Signed-off-by: David Herrmann
>>> ---
>>>drivers/video/Kconfig | 4 +
>>>drivers/video/Makefile | 1 +
>>>drivers/video/sysfb.c | 327
>>> +
>>>include/linux/sysfb.h | 34 +
>>>4 files changed, 366 insertions(+)
>>>create mode 100644 drivers/video/sysfb.c
>>>create mode 100644 include/linux/sysfb.h
>>>
>>> diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
>>> index 3c20af9..56a8294 100644
>>> --- a/drivers/video/Kconfig
>>> +++ b/drivers/video/Kconfig
>>> @@ -36,6 +36,10 @@ config VIDEOMODE_HELPERS
>>>config HDMI
>>> bool
>>>+config SYSFB
>>> + bool
>>> + select DUMMY_CONSOLE if VT
>>> +
>>>if VT
>>> source "drivers/video/console/Kconfig"
>>>endif
>>> diff --git a/drivers/video/Makefile b/drivers/video/Makefile
>>> index 9ad3c17..df7bd75 100644
>>> --- a/drivers/video/Makefile
>>> +++ b/drivers/video/Makefile
>>> @@ -1,5 +1,6 @@
>>>obj-$(CONFIG_VGASTATE)+= vgastate.o
>>>obj-$(CONFIG_HDMI)+= hdmi.o
>>> +obj-$(CONFIG_SYSFB) += sysfb.o
>>> obj-$(CONFIG_VT) += console/
>>>obj-$(CONFIG_LOGO) += logo/
>>> diff --git a/drivers/video/sysfb.c b/drivers/video/sysfb.c
>>> new file mode 100644
>>> index 000..00585c9
>>> --- /dev/null
>>> +++ b/drivers/video/sysfb.c
>>> @@ -0,0 +1,327 @@
>>> +/*
>>> + * Copyright (C) 2013-2016 Red Hat, Inc.
>>> + *
>>> + * This program is free software; you can redistribute it and/or modify
>>> it
>>> + * under the terms of the GNU Lesser General Public License as published
>>> by the
>>> + * Free Software Foundation; either version 2.1 of the License, or (at
>>> your
>>> + * option) any later version.
>>> + */
>>> +
>>> +#define pr_fmt(fmt) "sysfb: " fmt
>>> +#include
>>> +#include
>>> +#include
>>> +#include
>>> +#include
>>> +#include
>>> +#include
>>> +#include
>>> +#include
>>> +#include
>>> +#include
>>> +#include
>>> +#include
>>> +#include
>>> +
>>> +static bool sysfb_evict_match_resource(struct sysfb_evict_ctx *ctx,
>>> + struct resource *mem)
>>> +{
>>> + struct aperture *g;
>>> + unsigned int i;
>>> +
>>> + for (i = 0; i < ctx->ap->count; ++i) {
>>> + g = &ctx->ap->ranges[i];
>>> +
>>> + if (mem->start == g->base)
>>> + return true;
>>> + if (mem->start >= g->base && mem->end < g->base + g->size)
>>> + return true;
>>> + if ((ctx->flags & SYSFB_EVICT_VBE) && mem->start ==
>>> 0xA)
>>> + return true;
>>> + }
>>> +
>>> + return false;
>>> +}
>>> +
[PATCH v5 6/7] drm: add SimpleDRM driver
Den 02.09.2016 10:22, skrev David Herrmann:
> The SimpleDRM driver binds to simple-framebuffer devices and provides a
> DRM/KMS API. It provides only a single CRTC+encoder+connector combination
> plus one initial mode.
>
> Userspace can create dumb-buffers which can be blit into the real
> framebuffer similar to UDL. No access to the real framebuffer is allowed
> (compared to earlier version of this driver) to avoid security issues.
> Furthermore, this way we can support arbitrary modes as long as we have a
> conversion-helper.
>
> Signed-off-by: David Herrmann
> ---
[...]
> diff --git a/drivers/gpu/drm/simpledrm/simpledrm_drv.c
> b/drivers/gpu/drm/simpledrm/simpledrm_drv.c
> new file mode 100644
> index 000..d569120
> --- /dev/null
> +++ b/drivers/gpu/drm/simpledrm/simpledrm_drv.c
> @@ -0,0 +1,464 @@
> +/*
> + * Copyright (C) 2012-2016 Red Hat, Inc.
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms of the GNU Lesser General Public License as published by
> the
> + * Free Software Foundation; either version 2.1 of the License, or (at your
> + * option) any later version.
> + */
> +
> +#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include "simpledrm.h"
> +
> +static struct drm_driver sdrm_drm_driver;
> +static DEFINE_MUTEX(sdrm_lock);
> +
> +static int sdrm_hw_identify(struct platform_device *pdev,
> + struct simplefb_platform_data *modep,
> + struct simplefb_format *formatp,
> + struct resource **memp,
> + u32 *bppp)
> +{
> + static const struct simplefb_format valid_formats[] = SIMPLEFB_FORMATS;
> + struct simplefb_platform_data pm = {}, *mode = pdev->dev.platform_data;
> + struct device_node *np = pdev->dev.of_node;
> + const struct simplefb_format *format = NULL;
> + struct resource *mem;
> + unsigned int depth;
> + int r, bpp;
> + size_t i;
> +
> + if (!mode) {
> + if (!np)
> + return -ENODEV;
> +
> + mode = ±
> +
> + r = of_property_read_u32(np, "width", &mode->width);
> + if (r >= 0)
> + r = of_property_read_u32(np, "height", &mode->height);
> + if (r >= 0)
> + r = of_property_read_u32(np, "stride", &mode->stride);
> + if (r >= 0)
> + r = of_property_read_string(np, "format",
> + &mode->format);
> + if (r < 0)
> + return r;
> + }
> +
> + mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> + if (!mem)
> + return -ENODEV;
> +
> + for (i = 0; i < ARRAY_SIZE(valid_formats); ++i) {
> + if (!strcmp(mode->format, valid_formats[i].name)) {
> + format = &valid_formats[i];
> + break;
> + }
> + }
> +
> + if (!format)
> + return -ENODEV;
> +
> + switch (format->fourcc) {
> + case DRM_FORMAT_RGB565:
> + case DRM_FORMAT_XRGB1555:
> + case DRM_FORMAT_ARGB1555:
> + case DRM_FORMAT_RGB888:
> + case DRM_FORMAT_XRGB:
> + case DRM_FORMAT_ARGB:
> + case DRM_FORMAT_ABGR:
> + case DRM_FORMAT_XRGB2101010:
> + case DRM_FORMAT_ARGB2101010:
> + /*
> + * You must adjust sdrm_put() whenever you add a new format
> + * here, otherwise, blitting operations will not work.
> + * Furthermore, include/linux/platform_data/simplefb.h needs
> + * to be adjusted so the platform-device actually allows this
> + * format.
> + */
> + break;
> + default:
> + return -ENODEV;
> + }
> +
> + drm_fb_get_bpp_depth(format->fourcc, &depth, &bpp);
> + if (!bpp)
> + return -ENODEV;
> + if (resource_size(mem) < mode->stride * mode->height)
> + return -ENODEV;
> + if ((bpp + 7) / 8 * mode->width > mode->stride)
> + return -ENODEV;
> +
> + *modep = *mode;
> + *formatp = *format;
> + *memp = mem;
> + *bppp = bpp;
> + return 0;
> +}
> +
> +static struct sdrm_hw *sdrm_hw_new(const struct simplefb_platform_data *mode,
> +const struct simplefb_format *format,
> +const struct resource *mem,
> +u32 bpp)
> +{
> + struct sdrm_hw *hw;
> +
> + hw = kzalloc(sizeof(*hw), GFP_KERNEL);
> + if (!hw)
> + return ERR_PTR(-ENOMEM);
> +
> + mutex_init(&hw->lock);
> + hw->width = mode->width;
> + hw->height = mode->height;
> + hw->stride = mode->stride;
> + hw->bpp = bpp;
> + hw->format = format->fourcc;
> + hw->ba
[PATCH] drm/fsl-dcu: fix endian issue when using clk_register_divider
On 2016-09-05 01:46, Meng Yi wrote:
>> Subject: [PATCH] drm/fsl-dcu: fix endian issue when using
>> clk_register_divider
>>
>> Since using clk_register_divider to setup the pixel clock, regmap is no
>> longer
>> used. Regmap did take care of DCU using different endianness. Check
>> endianness using the device-tree property "big-endian" to determine the
>> location of DIV_RATIO.
>>
>> Cc: stable at vger.kernel.org
>> Fixes: 2d701449bce1 ("drm/fsl-dcu: use common clock framework for pixel
>> clock divider")
>> Reported-by: Meng Yi
>> Signed-off-by: Stefan Agner
>
> Tested-by: Meng Yi
> On LS1021A-TWR board.
Thanks, applied!
--
Stefan
[PATCH -next] drm/fsl-dcu: use PTR_ERR_OR_ZERO() to simplify the code
On 2016-07-25 00:08, Wei Yongjun wrote: > Use PTR_ERR_OR_ZERO rather than if(IS_ERR(...)) + PTR_ERR. > > Generated by: scripts/coccinelle/api/ptr_ret.cocci > > Signed-off-by: Wei Yongjun Applied! -- Stefan
[PATCH RESEND] drm/fsl-dcu: disable clock on error path
From: Fabio Estevam
In fsl_dcu_drm_pm_resume() we should disable the previously enabled
clock (fsl_dev->clk) when enabling fsl_dev->pix_clk fails.
Signed-off-by: Fabio Estevam
---
drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
index 7882387..76ae558 100644
--- a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
+++ b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
@@ -270,7 +270,7 @@ static int fsl_dcu_drm_pm_resume(struct device *dev)
ret = clk_prepare_enable(fsl_dev->pix_clk);
if (ret < 0) {
dev_err(dev, "failed to enable pix clk\n");
- return ret;
+ goto disable_dcu_clk;
}
fsl_dcu_drm_init_planes(fsl_dev->drm);
@@ -284,6 +284,10 @@ static int fsl_dcu_drm_pm_resume(struct device *dev)
enable_irq(fsl_dev->irq);
return 0;
+
+disable_dcu_clk:
+ clk_disable_unprepare(fsl_dev->clk);
+ return ret;
}
#endif
--
1.9.1
[PATCH] drm/fsl-dcu: disable clock on error path
On 2016-08-21 19:22, Fabio Estevam wrote: > From: Fabio Estevam > > In fsl_dcu_drm_pm_resume() we should disable the previously enabled > clock (fsl_dev->clk) when enabling fsl_dev->pix_clk fails. > > Signed-off-by: Fabio Estevam Applied, thanks! -- Stefan
[Bug 97119] screen flickerin under KDE when compositor was dis- and reenabled
https://bugs.freedesktop.org/show_bug.cgi?id=97119 --- Comment #17 from Johannes Hirte --- Flickering seems to be gone for me too, but I didn't update kwin or related. The parts I've updated last weekend: llvm drm mesa xf86-video-amdgpu I have some distortions in the top frame of the window (screenshot of chromium appended). I will test an update of kwin, if it will fix this. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160905/4af8a0ec/attachment.html>
[Bug 97119] screen flickerin under KDE when compositor was dis- and reenabled
https://bugs.freedesktop.org/show_bug.cgi?id=97119 --- Comment #18 from Johannes Hirte --- Created attachment 126230 --> https://bugs.freedesktop.org/attachment.cgi?id=126230&action=edit distortion in window after leaving fullscreen in mpv -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160905/b6fe8a53/attachment.html>
[PATCH 4/7] drm/panel: Add Sinlinx SinA33 7" panel
Hi, On Mon, Sep 05, 2016 at 01:03:03AM +0800, Icenowy Zheng wrote: > Hi Everyone, > > 01.09.2016, 23:40, "Maxime Ripard" : > > Â The SinA33 has an unidentified panel. Add the timings for it under a new > > Â compatible. > > > > Excuse me... > I will ask a question which is not fully related to the patch here... > If I want to add a generic panel for Q8 tablets, what should it be called? > "allwinner,q8-lcd-panel-800x480"? I guess it's more of a question for Thierry, but it seems like the trend is to put the diagonal rather than the resolution in the compatibles. Maxime -- Maxime Ripard, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160905/29fbffe6/attachment.sig>
[PATCH 5/7] ARM: sun8i: a33: Add display pipeline
Hi,
On Fri, Sep 02, 2016 at 02:28:54PM +0800, Chen-Yu Tsai wrote:
> > + be0: display-backend at 01e6 {
> > + compatible = "allwinner,sun8i-a33-display-backend";
> > + reg = <0x01e6 0x1>;
>
> Please also list the interrupt, even though we don't use it yet.
> The manual says it's 127 - 32 = 95.
Yep, you're right.
> > + sat0: sat at 01e8 {
> > + compatible = "allwinner,sun8i-a33-sat";
> > + reg = <0x01e8 0x1000>;
> > + clocks = <&ccu CLK_BUS_SAT>;
> > + resets = <&ccu RST_BUS_SAT>;
> > +
> > + ports {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + sat0_in: port at 0 {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + reg = <0>;
> > +
> > + sat0_in_fe0: endpoint at 0 {
> > + reg = <0>;
> > + remote-endpoint =
> > <&fe0_out_sat0>;
> > + };
> > + };
> > +
> > + sat0_out: port at 1 {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + reg = <1>;
> > +
> > + sat0_out_be0: endpoint at 0 {
> > + reg = <0>;
> > + remote-endpoint =
> > <&be0_in_sat0>;
> > + };
> > + };
>
> I'm worried about the representation here.
>
> In the user manuals, the SAT is shown as part of the BE. Look at it
> this way: if it did come before the BE and is independent, we
> shouldn't have to bring the SAT out of reset for simplefb to work.
Indeed.
> For comparison, a similar function unit called "CMU" found on the
> other post-sun6i SoCs has the same function description as SAT on
> the A33. It uses the reserved registers at the beginning of the BE
> address space.
Hmm, ok, so you would essentially, merge the backend and sat nodes?
That wouldn't be very hard to do, i'll do it.
Thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160905/edb8a22f/attachment-0001.sig>
[PATCH 2/7] drm/sun4i: support A33 tcon
On Fri, Sep 02, 2016 at 02:02:30PM +0800, Chen-Yu Tsai wrote: > Hi, > > On Thu, Sep 1, 2016 at 11:31 PM, Maxime Ripard > wrote: > > The A33 has a significantly different pipeline, with components that differ > > too. > > > > Make sure we had compatible for them. > > > > Signed-off-by: Maxime Ripard > > --- > > Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt | 7 ++- > > drivers/gpu/drm/sun4i/sun4i_backend.c | 1 + > > drivers/gpu/drm/sun4i/sun4i_drv.c | 8 +--- > > drivers/gpu/drm/sun4i/sun4i_tcon.c| 8 +++- > > 4 files changed, 19 insertions(+), 5 deletions(-) > > > > diff --git a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt > > b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt > > index df8f4aeefe4c..d467ea93ac08 100644 > > --- a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt > > +++ b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt > > @@ -26,7 +26,9 @@ TCON > > The TCON acts as a timing controller for RGB, LVDS and TV interfaces. > > > > Required properties: > > - - compatible: value should be "allwinner,sun5i-a13-tcon". > > + - compatible: value must be either: > > + * allwinner,sun5i-a13-tcon > > + * allwinner,sun8i-a23-tcon > > From what I can tell from the manuals, the A23 TCON and A33 TCON are > slightly different. The A23 TCON has channel 1, and it also has DMA > input. A33 has neither. (Though the DMA chart still lists the TCON DRQ.) > > I think we should have separate compatibles for them. If you think > otherwise you should mention it in the commit message. Ack, i will change it in the v2. Thanks! Maxime -- Maxime Ripard, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160905/954bf4e8/attachment.sig>
[PATCH 3/7] drm/sun4i: Add SAT and DRC drivers
Hi,
On Fri, Sep 02, 2016 at 02:45:06PM +0800, Chen-Yu Tsai wrote:
> > +
> > +DRC
> > +---
> > +
> > +The DRC, found in the latest Allwinner SoCs (A31, A23, A33), allows to
> > +do some backlight control to enhance the power consumption.
> > +
> > +Required properties:
> > + - compatible: value must be one of:
> > +* allwinner,sun8i-a33-drc
>
> Since this was first introduced in the A31, maybe using that
> for the compatible is better?
>
> Or do you want one for each SoC, given these are unknown black
> boxes?
Yeah, I'd prefer to be on the safe side here :/
> > + drc->mod_clk = devm_clk_get(dev, "mod");
> > + if (IS_ERR(drc->mod_clk)) {
> > + dev_err(dev, "Couldn't get our mod clock\n");
> > + ret = PTR_ERR(drc->mod_clk);
> > + goto err_disable_bus_clk;
> > + }
> > +
> > + return clk_prepare_enable(drc->mod_clk);
>
> What happens if this fails? No cleanup happens.
Indeed, will fix.
Thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160905/d96df651/attachment.sig>
[PATCH 0/7] drm/sun4i: Introduce A33 display driver
On Sat, Sep 03, 2016 at 09:43:59AM +0800, Chen-Yu Tsai wrote:
> On Sat, Sep 3, 2016 at 3:06 AM, Maxime Ripard
> wrote:
> > Hi Icenowy,
> >
> > On Fri, Sep 02, 2016 at 09:30:05AM +0800, Icenowy Zheng wrote:
> >>
> >>
> >> 01.09.2016, 23:40, "Maxime Ripard" :
> >> > Hi everyone,
> >> >
> >> > This serie introduces the support in the sun4i-drm driver for the A33.
> >> >
> >> > Beside the new IPs and special cases for the A33 new IPs, there's
> >> > nothing really outstanding, and is now at feature parity with the A13.
> >>
> >> How can the driver be modified to support LVDS screen?
> >>
> >> I have an A33 tablet with a 1024x768 LVDS panel. (iNet D978 Rev2 board,
> >> which I pushed a dt a few days ago)
> >
> > Awesome, I don't have such a screen myself, so feel free to work on
> > it.
> >
> > I haven't looked into the details of LVDS, but it should be something
> > along the lines of commit 29e57fab97fc ("drm: sun4i: Add RGB output").
>
> The implementation might be along the lines of
>
> 1. having multiple output ports, each for a different interface type.
> (Some platforms go this route)
>
> Or
>
> 2. having a DT property describe what the output interface is.
>
> The RGB/TCON driver would then setup the registers accordingly.
Hmmm, yeah, we would need to adjust the bindings too...
I guess I'd prefer 1), but that would also be the most invasive
solution. I'm not sure how the DT maintainers feel about that.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160905/72938a83/attachment.sig>
[Bug 51381] [drm:atom_op_jump] *ERROR* atombios stuck in loop for more than 5secs aborting, when disabled via vgaswitcheroo
https://bugzilla.kernel.org/show_bug.cgi?id=51381 Boris Carvajal changed: What|Removed |Added CC||boris2.9 at gmail.com --- Comment #45 from Boris Carvajal --- Hello, I was hoping the new changes would fix this, but it's not the case. The system freeze (and gets "atombios stuck" msg) like 15secs when starting X and resuming from suspend. Also running DRI_PRIME=1 glxgears just gets a blank window with a print loop of this message: "radeon: The kernel rejected CS, see dmesg for more information." and of course there is the "*ERROR* atombios stuck" stuff. I'm using an Asus K53TA laptop (6520G + 6650M) and a git kernel just recompiled yesterday. -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 97593] [amdgpu SI] low performace, low (about 1/4) VRAM usage
https://bugs.freedesktop.org/show_bug.cgi?id=97593 --- Comment #3 from Arek RuÅniak --- Created attachment 126231 --> https://bugs.freedesktop.org/attachment.cgi?id=126231&action=edit dmesg log dmesg for: shadow of mordor (empty) metro 2033 redux bioshock infinite alien: isolation deadfall adventures tomb raider xcom (empty) xonotic i've played a few second each game -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160905/51ba540c/attachment.html>
[Bug 97593] [amdgpu SI] low performace, low (about 1/4) VRAM usage
https://bugs.freedesktop.org/show_bug.cgi?id=97593 --- Comment #4 from Arek RuÅniak --- Created attachment 126232 --> https://bugs.freedesktop.org/attachment.cgi?id=126232&action=edit xorg log looks good to me -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160905/d29987f7/attachment.html>
[Bug 97605] AMDGPU Black Screen when Booting
https://bugs.freedesktop.org/show_bug.cgi?id=97605 Bug ID: 97605 Summary: AMDGPU Black Screen when Booting Product: DRI Version: unspecified Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: DRM/AMDgpu Assignee: dri-devel at lists.freedesktop.org Reporter: jamoflaw at gmail.com My laptop (HP Pavilion 15-ab141na) is simply booting to a black screen on 16.04, the backlight is on but there is no display. Sound is working so I can hear the ubuntu logon noise and can SSH from another machine. During boot the screen on the laptop looks as if it is flashing off and on before settling and remaining black with the backlight on. Below is the debug info from the Ubuntu system, I think it lists the Carrizo chip but I believe there is a Topaz chip in there too not listed below. --- ApportVersion: 2.20.1-0ubuntu2.1 Architecture: amd64 CompizPlugins: No value set for `/apps/compiz-1/general/screen0/options/active_plugins' DistUpgraded: Fresh install DistroCodename: xenial DistroRelease: Ubuntu 16.04 DistroVariant: ubuntu DkmsStatus: bcmwl, 6.30.223.248+bdcom, 4.4.0-28-generic, x86_64: installed GraphicsCard: Advanced Micro Devices, Inc. [AMD/ATI] Carrizo [1002:9874] (rev c4) (prog-if 00 [VGA controller]) Subsystem: Hewlett-Packard Company Carrizo [103c:80b5] InstallationDate: Installed on 2016-06-28 (11 days ago) InstallationMedia: Ubuntu 16.04 LTS "Xenial Xerus" - Release amd64 (20160420.1) MachineType: HP HP Pavilion Notebook NonfreeKernelModules: wl Package: xserver-xorg-video-amdgpu 1.1.0-1 PackageArchitecture: amd64 ProcEnviron: LANGUAGE=en_GB:en TERM=xterm PATH=(custom, no user) LANG=en_GB.UTF-8 SHELL=/bin/bash ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.4.0-28-generic.efi.signed root=UUID=0a039e19-a176-41df-b477-a009498d708b ro quiet splash vt.handoff=7 ProcVersionSignature: Ubuntu 4.4.0-28.47-generic 4.4.13 Tags: third-party-packages xenial ubuntu Uname: Linux 4.4.0-28-generic x86_64 UpgradeStatus: No upgrade log present (probably fresh install) UserGroups: _MarkForUpload: True dmi.bios.date: 05/27/2016 dmi.bios.vendor: American Megatrends Inc. dmi.bios.version: F.19 dmi.board.asset.tag: Base Board Asset Tag dmi.board.name: 80B5 dmi.board.vendor: HP dmi.board.version: 81.29 dmi.chassis.type: 10 dmi.chassis.vendor: HP dmi.chassis.version: Chassis Version dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvrF.19:bd05/27/2016:svnHP:pnHPPavilionNotebook:pvr:rvnHP:rn80B5:rvr81.29:cvnHP:ct10:cvrChassisVersion: dmi.product.name: HP Pavilion Notebook dmi.sys.vendor: HP version.compiz: compiz 1:0.9.12.2+16.04.20160526-0ubuntu1 version.ia32-libs: ia32-libs N/A version.libdrm2: libdrm2 2.4.68+git1607081632.8c8d5dd~x~padoka0 version.libgl1-mesa-dri: libgl1-mesa-dri 12.1~git1600708182300.64ac4ae~x~padoka0 version.libgl1-mesa-dri-experimental: libgl1-mesa-dri-experimental N/A version.libgl1-mesa-glx: libgl1-mesa-glx 12.1~git1600708182300.64ac4ae~x~padoka0 version.xserver-xorg-core: xserver-xorg-core 2:1.18.3-1ubuntu2.2 version.xserver-xorg-input-evdev: xserver-xorg-input-evdev 1:2.10.1-1ubuntu2 version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:7.7.0+git1606291706.3be841d~x~padoka0 version.xserver-xorg-video-intel: xserver-xorg-video-intel 2:2.99.917+git1607081624.26f8ab5~x~padoka0 version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 1:1.0.12+git1607031832.12f7734~x~padoka0 -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160905/c2dda936/attachment-0001.html>
[PATCH v2] drm/bridge: adv7511: add support for the 2nd chip
The Renesas Wheat board has 2 ADV7513 chips on the same I2C bus, however
the ADV751x driver only supports 1 chip as it tries to assign the packet/
EDID/CEC memory I2C devices to the fixed I2C addresses. Assign these I2C
addresses at the fixed offsets (derived from the programming guide) from
the main register map address instead...
Signed-off-by: Sergei Shtylyov
---
The patch is against David Airlie's 'linux.git' repo's 'drm-next' branch.
Changes in version 2:
- added support for ADV7533 CEC alternate address.
drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 12 ++--
drivers/gpu/drm/bridge/adv7511/adv7533.c |5 ++---
2 files changed, 8 insertions(+), 9 deletions(-)
Index: linux/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
===
--- linux.orig/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
+++ linux/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
@@ -922,15 +922,13 @@ static int adv7511_parse_dt(struct devic
return 0;
}
-static const int edid_i2c_addr = 0x7e;
-static const int packet_i2c_addr = 0x70;
-static const int cec_i2c_addr = 0x78;
-
static int adv7511_probe(struct i2c_client *i2c, const struct i2c_device_id
*id)
{
struct adv7511_link_config link_config;
struct adv7511 *adv7511;
struct device *dev = &i2c->dev;
+ unsigned int main_i2c_addr = i2c->addr << 1;
+ unsigned int edid_i2c_addr = main_i2c_addr + 4;
unsigned int val;
int ret;
@@ -991,8 +989,10 @@ static int adv7511_probe(struct i2c_clie
regmap_write(adv7511->regmap, ADV7511_REG_EDID_I2C_ADDR, edid_i2c_addr);
regmap_write(adv7511->regmap, ADV7511_REG_PACKET_I2C_ADDR,
-packet_i2c_addr);
- regmap_write(adv7511->regmap, ADV7511_REG_CEC_I2C_ADDR, cec_i2c_addr);
+main_i2c_addr - 0xa);
+ regmap_write(adv7511->regmap, ADV7511_REG_CEC_I2C_ADDR,
+main_i2c_addr - 2);
+
adv7511_packet_disable(adv7511, 0x);
adv7511->i2c_main = i2c;
Index: linux/drivers/gpu/drm/bridge/adv7511/adv7533.c
===
--- linux.orig/drivers/gpu/drm/bridge/adv7511/adv7533.c
+++ linux/drivers/gpu/drm/bridge/adv7511/adv7533.c
@@ -149,13 +149,12 @@ void adv7533_uninit_cec(struct adv7511 *
i2c_unregister_device(adv->i2c_cec);
}
-static const int cec_i2c_addr = 0x78;
-
int adv7533_init_cec(struct adv7511 *adv)
{
int ret;
- adv->i2c_cec = i2c_new_dummy(adv->i2c_main->adapter, cec_i2c_addr >> 1);
+ adv->i2c_cec = i2c_new_dummy(adv->i2c_main->adapter,
+adv->i2c_main->addr - 1);
if (!adv->i2c_cec)
return -ENOMEM;
[PATCH 3/6] drm/panel: simple: Add A10 EVB 5 inch panel support
On Wed, Aug 31, 2016 at 4:18 PM, Maxime Ripard
wrote:
> The A10-EVB from Allwinner comes with an unidentified panel, with the only
> mark on the PCB being A10-SUB-EVB-5LCD.
>
> Add timings to simple panel to handle it.
>
> Signed-off-by: Maxime Ripard
> ---
> drivers/gpu/drm/panel/panel-simple.c | 26 ++
> 1 file changed, 26 insertions(+)
>
> diff --git a/drivers/gpu/drm/panel/panel-simple.c
> b/drivers/gpu/drm/panel/panel-simple.c
> index 85143d1b9b31..be371b053aab 100644
> --- a/drivers/gpu/drm/panel/panel-simple.c
> +++ b/drivers/gpu/drm/panel/panel-simple.c
> @@ -386,6 +386,29 @@ static void panel_simple_shutdown(struct device *dev)
> panel_simple_disable(&panel->base);
> }
>
> +static const struct drm_display_mode allwinner_a10_sub_evb_5lcd_mode = {
> + .clock = 33000,
> + .hdisplay = 800,
> + .hsync_start = 800 + 209,
> + .hsync_end = 800 + 209 + 1,
> + .htotal = 800 + 209 + 1 + 45,
> + .vdisplay = 480,
> + .vsync_start = 480 + 22,
> + .vsync_end = 480 + 22 + 1,
> + .vtotal = 480 + 22 + 1 + 22,
> + .vrefresh = 60,
I assume the numbers came from the fex file? Allwinner LCD timing numbers
aren't very precise. This seems to yield a refresh rate of 58.x Hz.
The dot clock can go below MHz resolution, so it should be possible
to set it to a more proper clock rate here.
ChenYu
> +};
> +
> +static const struct panel_desc allwinner_a10_sub_evb_5lcd = {
> + .modes = &allwinner_a10_sub_evb_5lcd_mode,
> + .num_modes = 1,
> + .size = {
> + .width = 110,
> + .height = 67,
> + },
> + .bus_format = MEDIA_BUS_FMT_RGB666_1X18,
> +};
> +
> static const struct drm_display_mode ampire_am800480r3tmqwa1h_mode = {
> .clock = 3,
> .hdisplay = 800,
> @@ -1515,6 +1538,9 @@ static const struct panel_desc urt_umsh_8596md_parallel
> = {
>
> static const struct of_device_id platform_of_match[] = {
> {
> + .compatible = "allwinner,sun4i-a10-sub-evb-5-lcd",
> + .data = &allwinner_a10_sub_evb_5lcd,
> + }, {
> .compatible = "ampire,am800480r3tmqwa1h",
> .data = &ire_am800480r3tmqwa1h,
> }, {
> --
> 2.9.2
>
[8086:0416] i915 Inability to drive internal (eDP) panel since 4.7 final
On 25/08/16 12:19, Jani Nikula wrote: > Please attach drm.debug=14 module parameter, > and attach dmesg all the way from boot. Added to bug 97060, which is the same problem. One good run, one bad run. Thank you. Regards, -- Tony Vroon Systems Infrastructure Manager London Internet Exchange Ltd, Trinity Court, Trinity Street, Peterborough, PE1 1DA Registered in England number 3137929 E-Mail: tony at linx.net -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 248 bytes Desc: OpenPGP digital signature URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160905/fd0b38ce/attachment.sig>
Hibernation broken since commit 274ad65c9d02 ("drm/radeon: hard reset r600 and newer GPU when hibernating.")
> Recently I got myself a new laptop with the following integrated GPU:
>
> 00:01.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI]
> Mullins [Radeon R3 Graphics] (rev 40)
>
> I found that hibernation is broken in Linux 4.7+ (it works in Linux 4.6)
> and bisected it to commit 274ad65c9d02 ("drm/radeon: hard reset r600 and
> newer GPU when hibernating.").
>
> This has already been reported three months ago, but for a much older
> GPU, see the thread starting at
> https://lists.freedesktop.org/archives/dri-devel/2016-June/110050.html.
> The symptoms are exactly the same as described by Boris Petkov in that
> thread: after "systemctl hibernate" the screen goes blank, but the
> machine remains powered on and needs to be power-cycled.
>
> Any suggestions would be welcome.
>
> Cheers,
>Sven
I guess we can invert the logic and only do it for the GPU for which it fix
hibernation.
Cheers,
Jérôme
[PATCH 0/4] drm/fsl-dcu: add overlay and cursor plane support
This patchset adds overlay and cursor plane support. It also fixes some issues uncovered during implementation of this. However, the plane updates currently causes the display to flicker for unknown reasons. As far as I can tell, the CRTC atomic_flush should trigger the update correctly via READREG, which according to documentation: The READREG bit causes a single transfer to begin at the next frame blanking period. This bit is cleared when the transfer is complete. I made a video how that looks: https://cloud.agner.ch/index.php/s/Yfqa2u7UBEWUT8N Any ideas? Stefan Agner (4): drm/fsl-dcu: support overlay and cursor planes drm/fsl-dcu: respect pos/size register sizes drm/fsl-dcu: update all registers on flush drm/fsl-dcu: do not update when modifying irq registers drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_crtc.c | 50 - drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c | 4 --- drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.h | 8 ++--- drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_plane.c | 42 +++- drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_plane.h | 3 +- 5 files changed, 67 insertions(+), 40 deletions(-) -- 2.9.3
[PATCH 1/4] drm/fsl-dcu: support overlay and cursor planes
Add support for overlay plane and a cursor plane. The driver uses
the topmost plane as cursor plane. The DCU IP would have dedicated
cursor support, but that lacks proper color support and hence is
not practical to use for Linux systems.
Signed-off-by: Stefan Agner
---
drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_crtc.c | 47 -
drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_plane.c | 37 ---
drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_plane.h | 3 +-
3 files changed, 60 insertions(+), 27 deletions(-)
diff --git a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_crtc.c
b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_crtc.c
index 3371635..d30b61e 100644
--- a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_crtc.c
+++ b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_crtc.c
@@ -139,20 +139,51 @@ static const struct drm_crtc_funcs fsl_dcu_drm_crtc_funcs
= {
int fsl_dcu_drm_crtc_create(struct fsl_dcu_drm_device *fsl_dev)
{
- struct drm_plane *primary;
+ struct drm_device *drm = fsl_dev->drm;
+ struct drm_plane *primary, *cursor;
struct drm_crtc *crtc = &fsl_dev->crtc;
- int ret;
+ int total_layer = fsl_dev->soc->total_layer;
+ int ret, i;
- fsl_dcu_drm_init_planes(fsl_dev->drm);
+ fsl_dcu_drm_init_planes(drm);
- primary = fsl_dcu_drm_primary_create_plane(fsl_dev->drm);
- if (!primary)
- return -ENOMEM;
+ primary = fsl_dcu_drm_create_plane(drm, DRM_PLANE_TYPE_PRIMARY);
+ if (IS_ERR(primary)) {
+ dev_err(fsl_dev->dev, "failed to construct primary plane\n");
+ ret = PTR_ERR(primary);
+ return ret;
+ }
+
+ /*
+* Initialize overlay layers. The hardware does not have specific
+* layer types, we just happen to use one layer as primary layer
+* and one layer as cursor layer, hence total_layer - 2 = overlays.
+*/
+ for (i = 0; i < total_layer - 2; i++) {
+ struct drm_plane *plane =
+ fsl_dcu_drm_create_plane(drm, DRM_PLANE_TYPE_OVERLAY);
+
+ if (IS_ERR(plane))
+ continue;
+ }
- ret = drm_crtc_init_with_planes(fsl_dev->drm, crtc, primary, NULL,
+ cursor = fsl_dcu_drm_create_plane(drm, DRM_PLANE_TYPE_CURSOR);
+ if (IS_ERR(cursor)) {
+ dev_warn(fsl_dev->dev, "failed to construct cursor plane\n");
+ cursor = NULL;
+ }
+
+ /*
+* Initialize cursor plane after overlay planes since the initialization
+* order is crucial to the layer id (and hence layer stacking order).
+*/
+ ret = drm_crtc_init_with_planes(drm, crtc, primary, cursor,
&fsl_dcu_drm_crtc_funcs, NULL);
if (ret) {
- primary->funcs->destroy(primary);
+ struct drm_plane *plane;
+
+ list_for_each_entry(plane, &drm->mode_config.plane_list, head)
+ drm_plane_cleanup(plane);
return ret;
}
diff --git a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_plane.c
b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_plane.c
index a7e5486..a6af3d9 100644
--- a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_plane.c
+++ b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_plane.c
@@ -178,7 +178,6 @@ static const struct drm_plane_helper_funcs
fsl_dcu_drm_plane_helper_funcs = {
static void fsl_dcu_drm_plane_destroy(struct drm_plane *plane)
{
drm_plane_cleanup(plane);
- kfree(plane);
}
static const struct drm_plane_funcs fsl_dcu_drm_plane_funcs = {
@@ -218,28 +217,30 @@ void fsl_dcu_drm_init_planes(struct drm_device *dev)
DCU_UPDATE_MODE_READREG);
}
-struct drm_plane *fsl_dcu_drm_primary_create_plane(struct drm_device *dev)
+struct drm_plane *fsl_dcu_drm_create_plane(struct drm_device *dev,
+ enum drm_plane_type type)
{
- struct drm_plane *primary;
+ struct drm_plane *plane;
int ret;
- primary = kzalloc(sizeof(*primary), GFP_KERNEL);
- if (!primary) {
- DRM_DEBUG_KMS("Failed to allocate primary plane\n");
- return NULL;
- }
+ plane = devm_kzalloc(dev->dev, sizeof(struct drm_plane),
+ GFP_KERNEL);
+ if (!plane)
+ return ERR_PTR(-ENOMEM);
- /* possible_crtc's will be filled in later by crtc_init */
- ret = drm_universal_plane_init(dev, primary, 0,
- &fsl_dcu_drm_plane_funcs,
+ ret = drm_universal_plane_init(dev, plane, 1, &fsl_dcu_drm_plane_funcs,
fsl_dcu_drm_plane_formats,
ARRAY_SIZE(fsl_dcu_drm_plane_formats),
- DRM_PLANE_TYPE_PRIMARY, NULL);
- if (ret) {
- kfree(primary);
- primary = NULL;
- }
- drm_plane_helper_add(primary, &fsl_dcu_drm_plane_helper_fun
[PATCH 2/4] drm/fsl-dcu: respect pos/size register sizes
Mask the size and position values to avoid mutual overwriting. Especially, a negative X position caused the Y position to be overwritten with 0xfff too. This has been observed when using a layer as cursor layer. Signed-off-by: Stefan Agner --- drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.h | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.h b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.h index 3b371fe7..060f881 100644 --- a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.h +++ b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.h @@ -118,11 +118,11 @@ #define DCU_CTRLDESCLN(layer, reg) (0x200 + (reg - 1) * 4 + (layer) * 0x40) -#define DCU_LAYER_HEIGHT(x)((x) << 16) -#define DCU_LAYER_WIDTH(x) (x) +#define DCU_LAYER_HEIGHT(x)(((x) & 0x7ff) << 16) +#define DCU_LAYER_WIDTH(x) ((x) & 0x7ff) -#define DCU_LAYER_POSY(x) ((x) << 16) -#define DCU_LAYER_POSX(x) (x) +#define DCU_LAYER_POSY(x) (((x) & 0xfff) << 16) +#define DCU_LAYER_POSX(x) ((x) & 0xfff) #define DCU_LAYER_EN BIT(31) #define DCU_LAYER_TILE_EN BIT(30) -- 2.9.3
[PATCH 3/4] drm/fsl-dcu: update all registers on flush
Use the UPDATE_MODE READREG bit to initiate a register transfer
on flush. This makes sure that we flush all registers only once
for all planes.
Signed-off-by: Stefan Agner
---
drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_crtc.c | 3 +++
drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_plane.c | 5 -
2 files changed, 3 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_crtc.c
b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_crtc.c
index d30b61e..62eb284 100644
--- a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_crtc.c
+++ b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_crtc.c
@@ -27,6 +27,9 @@ static void fsl_dcu_drm_crtc_atomic_flush(struct drm_crtc
*crtc,
{
struct drm_pending_vblank_event *event = crtc->state->event;
+ regmap_write(fsl_dev->regmap,
+DCU_UPDATE_MODE, DCU_UPDATE_MODE_READREG);
+
if (event) {
crtc->state->event = NULL;
diff --git a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_plane.c
b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_plane.c
index a6af3d9..d7412ff 100644
--- a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_plane.c
+++ b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_plane.c
@@ -160,11 +160,6 @@ static void fsl_dcu_drm_plane_atomic_update(struct
drm_plane *plane,
DCU_LAYER_POST_SKIP(0) |
DCU_LAYER_PRE_SKIP(0));
}
- regmap_update_bits(fsl_dev->regmap, DCU_DCU_MODE,
- DCU_MODE_DCU_MODE_MASK,
- DCU_MODE_DCU_MODE(DCU_MODE_NORMAL));
- regmap_write(fsl_dev->regmap,
-DCU_UPDATE_MODE, DCU_UPDATE_MODE_READREG);
return;
}
--
2.9.3
[PATCH 4/4] drm/fsl-dcu: do not update when modifying irq registers
The IRQ status and mask registers are not "double buffered" according to the reference manual. Hence, there is no extra transfer/update write needed when modifying these registers. Signed-off-by: Stefan Agner --- drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c | 4 1 file changed, 4 deletions(-) diff --git a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c index 092aaec..4e700bc4 100644 --- a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c +++ b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c @@ -59,8 +59,6 @@ static int fsl_dcu_drm_irq_init(struct drm_device *dev) regmap_write(fsl_dev->regmap, DCU_INT_STATUS, 0); regmap_write(fsl_dev->regmap, DCU_INT_MASK, ~0); - regmap_write(fsl_dev->regmap, DCU_UPDATE_MODE, -DCU_UPDATE_MODE_READREG); return ret; } @@ -139,8 +137,6 @@ static irqreturn_t fsl_dcu_drm_irq(int irq, void *arg) drm_handle_vblank(dev, 0); regmap_write(fsl_dev->regmap, DCU_INT_STATUS, int_status); - regmap_write(fsl_dev->regmap, DCU_UPDATE_MODE, -DCU_UPDATE_MODE_READREG); return IRQ_HANDLED; } -- 2.9.3
[v14.2 PATCH 5/5] drm/rockchip: cdn-dp: add cdn DP support for rk3399
Add support for cdn DP controller which is embedded in the rk3399 SoCs. The DP is compliant with DisplayPort Specification, Version 1.3, This IP is compatible with the rockchip type-c PHY IP. There is a uCPU in DP controller, it need a firmware to work, please put the firmware file to /lib/firmware/rockchip/dptx.bin. The uCPU in charge of aux communication and link training, the host use mailbox to communicate with the ucpu. The dclk pin_pol of vop must not be invert for DP. Signed-off-by: Chris Zhong Reviewed-by: Sean Paul Acked-by: Mark Yao --- Changes in v14.2: - Modify some grammatical errors - remove the mutex around cdn_dp_audio_get_eld Changes in v14.1: - power on the power domain after clk_enable - retry to read edid Changes in v14: - change super speed property name to EXTCON_PROP_USB_SS - do a correct mode_valid check when bpc is 0 Changes in v13: - support suspend/resume - switch power domain dynamically - re-training when hpd signal is triggered Changes in v12: - use EXTCON_PROP_USB_SUPERSPEED to replace EXTCON_USB_HOST Changes in v11: - add best_encoder back, since it required by drm_atomic_helper_check Changes in v10: - remove best_encoder ops - support read sink count from DPCD - control the grf_clk in DP Changes in v9: - do not need reset the phy before power_on - add a orientation information for set_capability - retry to read dpcd in 10 seconds Changes in v8: - optimization the err log Changes in v7: - support firmware standby when no dptx connection - optimization the calculation of tu size and valid symbol Changes in v6: - add a port struct - select SND_SOC_HDMI_CODEC - force reset the phy when hpd detected Changes in v5: - alphabetical order - do not use long, use u32 or u64 - return MODE_CLOCK_HIGH when requested > actual - Optimized Coding Style - add a formula to get better tu size and symbol value. - modify according to Sean Paul's comments - fixed the fw_wait always 0 Changes in v4: - use phy framework to control DP phy - support 2 phys Changes in v3: - use EXTCON_DISP_DP and EXTCON_DISP_DP_ALT cable to get dp port state. - reset spdif before config it - modify the firmware clk to 100Mhz - retry load firmware if fw file is requested too early Changes in v2: - Alphabetic order - remove excess error message - use define clk_rate - check all return value - remove dev_set_name(dp->dev, "cdn-dp"); - use schedule_delayed_work - remove never-called functions - remove some unnecessary () Changes in v1: - use extcon API - use hdmi-codec for the DP Asoc - do not initialize the "ret" - printk a err log when drm_of_encoder_active_endpoint_id - modify the dclk pin_pol to a single line drivers/gpu/drm/rockchip/Kconfig| 10 + drivers/gpu/drm/rockchip/Makefile |1 + drivers/gpu/drm/rockchip/cdn-dp-core.c | 1053 +++ drivers/gpu/drm/rockchip/cdn-dp-core.h | 106 +++ drivers/gpu/drm/rockchip/cdn-dp-reg.c | 961 drivers/gpu/drm/rockchip/cdn-dp-reg.h | 482 drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 13 +- drivers/gpu/drm/rockchip/rockchip_drm_vop.h |9 + drivers/gpu/drm/rockchip/rockchip_vop_reg.c |2 + 9 files changed, 2634 insertions(+), 3 deletions(-) create mode 100644 drivers/gpu/drm/rockchip/cdn-dp-core.c create mode 100644 drivers/gpu/drm/rockchip/cdn-dp-core.h create mode 100644 drivers/gpu/drm/rockchip/cdn-dp-reg.c create mode 100644 drivers/gpu/drm/rockchip/cdn-dp-reg.h diff --git a/drivers/gpu/drm/rockchip/Kconfig b/drivers/gpu/drm/rockchip/Kconfig index d30bdc3..20aaafe 100644 --- a/drivers/gpu/drm/rockchip/Kconfig +++ b/drivers/gpu/drm/rockchip/Kconfig @@ -25,6 +25,16 @@ config ROCKCHIP_ANALOGIX_DP for the Analogix Core DP driver. If you want to enable DP on RK3288 based SoC, you should selet this option. +config ROCKCHIP_CDN_DP +tristate "Rockchip cdn DP" +depends on DRM_ROCKCHIP + select SND_SOC_HDMI_CODEC if SND_SOC +help + This selects support for Rockchip SoC specific extensions + for the cdn DP driver. If you want to enable Dp on + RK3399 based SoC, you should select this + option. + config ROCKCHIP_DW_HDMI tristate "Rockchip specific extensions for Synopsys DW HDMI" depends on DRM_ROCKCHIP diff --git a/drivers/gpu/drm/rockchip/Makefile b/drivers/gpu/drm/rockchip/Makefile index 9746365..6a07809 100644 --- a/drivers/gpu/drm/rockchip/Makefile +++ b/drivers/gpu/drm/rockchip/Makefile @@ -7,6 +7,7 @@ rockchipdrm-y := rockchip_drm_drv.o rockchip_drm_fb.o \ rockchipdrm-$(CONFIG_DRM_FBDEV_EMULATION) += rockchip_drm_fbdev.o obj-$(CONFIG_ROCKCHIP_ANALOGIX_DP) += analogix_dp-rockchip.o +obj-$(CONFIG_ROCKCHIP_CDN_DP) += cdn-dp-core.o cdn-dp-reg.o obj-$(CONFIG_ROCKCHIP_DW_HDMI) += dw_hdmi-rockchip.o obj-$(CONFIG_ROCKCHIP_DW_MIPI_DSI) += dw-mipi-dsi.o obj-$(CONFIG_ROCKCHIP_INNO_HDMI) += inno_hdmi.o diff --git a/drivers/gpu/drm/rockchi
