All of lore.kernel.org
 help / color / mirror / Atom feed
* [RFC/RFT 02/14] clk: core: introduce clk_hw_set_parent()
From: Neil Armstrong @ 2019-06-20 15:00 UTC (permalink / raw)
  To: jbrunet, khilman
  Cc: linux-arm-kernel, linux-amlogic, linux-kernel, linux-clk,
	martin.blumenstingl, Neil Armstrong
In-Reply-To: <20190620150013.13462-1-narmstrong@baylibre.com>

Introduce the clk_hw_set_parent() provider call to change parent of
a clock by using the clk_hw pointers.

This eases the clock reparenting from clock rate notifiers and
implementing DVFS with simpler code avoiding the boilerplates
functions as __clk_lookup(clk_hw_get_name()) then clk_set_parent().

Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
 drivers/clk/clk.c            | 5 +++++
 include/linux/clk-provider.h | 1 +
 2 files changed, 6 insertions(+)

diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index aa51756fd4d6..3e98f7dec626 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -2490,6 +2490,11 @@ static int clk_core_set_parent_nolock(struct clk_core *core,
 	return ret;
 }
 
+int clk_hw_set_parent(struct clk_hw *hw, struct clk_hw *parent)
+{
+	return clk_core_set_parent_nolock(hw->core, parent->core);
+}
+
 /**
  * clk_set_parent - switch the parent of a mux clk
  * @clk: the mux clk whose input we are switching
diff --git a/include/linux/clk-provider.h b/include/linux/clk-provider.h
index bb6118f79784..8a453380f9a4 100644
--- a/include/linux/clk-provider.h
+++ b/include/linux/clk-provider.h
@@ -812,6 +812,7 @@ unsigned int clk_hw_get_num_parents(const struct clk_hw *hw);
 struct clk_hw *clk_hw_get_parent(const struct clk_hw *hw);
 struct clk_hw *clk_hw_get_parent_by_index(const struct clk_hw *hw,
 					  unsigned int index);
+int clk_hw_set_parent(struct clk_hw *hw, struct clk_hw *new_parent);
 unsigned int __clk_get_enable_count(struct clk *clk);
 unsigned long clk_hw_get_rate(const struct clk_hw *hw);
 unsigned long __clk_get_flags(struct clk *clk);
-- 
2.21.0


^ permalink raw reply related

* [RFC/RFT 00/14] arm64: g12a: add support for DVFS
From: Neil Armstrong @ 2019-06-20 14:59 UTC (permalink / raw)
  To: jbrunet, khilman
  Cc: linux-arm-kernel, linux-amlogic, linux-kernel, linux-clk,
	martin.blumenstingl, Neil Armstrong

The G12A/G12B Socs embeds a specific clock tree for each CPU cluster :
cpu_clk / cpub_clk
|   \- cpu_clk_dyn
|      |  \- cpu_clk_premux0
|      |        |- cpu_clk_postmux0
|      |        |    |- cpu_clk_dyn0_div
|      |        |    \- xtal/fclk_div2/fclk_div3
|      |        \- xtal/fclk_div2/fclk_div3
|      \- cpu_clk_premux1
|            |- cpu_clk_postmux1
|            |    |- cpu_clk_dyn1_div
|            |    \- xtal/fclk_div2/fclk_div3
|            \- xtal/fclk_div2/fclk_div3
\ sys_pll / sys1_pll

This patchset adds notifiers on cpu_clk / cpub_clk, cpu_clk_dyn,
cpu_clk_premux0 and sys_pll / sys1_pll to permit change frequency of
the CPU clock in a safe way as recommended by the vendor Documentation
and reference code.

This patchset :
- introduces needed core and meson clk changes
- adds support for the G12B second cluster clock measurer ids
- protects clock measurer from cooncurent measures
- adds the clock notifiers
- moves the G12A DT to a common g12a-common dtsi
- adds the G12A and G12B OPPs
- enables DVFS on all supported boards

Dependencies:
- PWM AO input order fix at [1]
- PWM enhancements from Martin at [2]

[1] https://patchwork.kernel.org/patch/11006835/
[2] https://patchwork.kernel.org/patch/11006835/

Neil Armstrong (14):
  pinctrl: meson-g12a: add pwm_a on GPIOE_2 pinmux
  clk: core: introduce clk_hw_set_parent()
  clk: meson: regmap: export regmap_div ops functions
  clk: meson: eeclk: add setup callback
  soc: amlogic: meson-clk-measure: protect measure with a mutex
  soc: amlogic: meson-clk-measure: add G12B second cluster cpu clk
  clk: meson: g12a: add notifiers to handle cpu clock change
  clk: meson: g12a: expose CPUB clock ID for G12B
  arm64: dts: move common G12A & G12B modes to meson-g12-common.dtsi
  arm64: dts: meson-g12-common: add pwm_a on GPIOE_2 pinmux
  arm64: dts: meson-g12a: add cpus OPP table
  arm64: dts: meson-g12a: enable DVFS on G12A boards
  arm64: dts: meson-g12b: add cpus OPP tables
  arm64: dts: meson-g12b-odroid-n2: enable DVFS

 .../boot/dts/amlogic/meson-g12-common.dtsi    | 2464 +++++++++++++++++
 .../boot/dts/amlogic/meson-g12a-sei510.dts    |   55 +
 .../boot/dts/amlogic/meson-g12a-u200.dts      |   55 +
 .../boot/dts/amlogic/meson-g12a-x96-max.dts   |   52 +
 arch/arm64/boot/dts/amlogic/meson-g12a.dtsi   | 2462 +---------------
 .../boot/dts/amlogic/meson-g12b-odroid-n2.dts |   96 +
 arch/arm64/boot/dts/amlogic/meson-g12b.dtsi   |  141 +-
 drivers/clk/clk.c                             |    5 +
 drivers/clk/meson/clk-regmap.c                |   10 +-
 drivers/clk/meson/clk-regmap.h                |    5 +
 drivers/clk/meson/g12a.c                      |  500 +++-
 drivers/clk/meson/meson-eeclk.c               |    6 +
 drivers/clk/meson/meson-eeclk.h               |    1 +
 drivers/pinctrl/meson/pinctrl-meson-g12a.c    |    9 +
 drivers/soc/amlogic/meson-clk-measure.c       |   14 +-
 include/dt-bindings/clock/g12a-clkc.h         |    1 +
 include/linux/clk-provider.h                  |    1 +
 17 files changed, 3412 insertions(+), 2465 deletions(-)
 create mode 100644 arch/arm64/boot/dts/amlogic/meson-g12-common.dtsi

-- 
2.21.0


^ permalink raw reply

* Re: linux not getting gpio interrupts on xenomai 3.0.8 on raspberrypi raspbian/stretch kernel 4.9
From: Harco Kuppens @ 2019-06-20 15:00 UTC (permalink / raw)
  To: xenomai
In-Reply-To: <c7402819-9b82-cb02-4edb-d2c5e75dd30f@cs.ru.nl>


I used 'make multi_v7_defconfig '

See my build instructions at:

https://github.com/harcokuppens/xenomai3_rpi_gpio/blob/master/install/installation_of_xenomai_3.0.8_on_mainline_kernel_branch_v4.9.51_from_kernel.org__problem_linux_gpio.md


Best regards,
Harco Kuppens


Op 20/06/2019 om 16:57 schreef Harco Kuppens via Xenomai:
>
>
> Op 20/06/2019 om 16:45 schreef Greg Gallagher:
>>
>> Do you have sysfs interface turned on when building the mainline
>> kernels?  Dumb question but it was turned off by default when I was
>> doing my builds.
>> Should be under Device Drivers => GPIO Support -> /sys/class/gpio
>> (sysfs interface) when you do a menuconfig.
>>
>>
> yes, I just checked.
>
> It is the config option CONFIG_GPIO_SYSFS
> and this option is set if you use
>
>     make multi_v7_defconfig
>
> to start with an initial config.
>
> cheers
> Harco
>
> ||



^ permalink raw reply

* ✓ Fi.CI.IGT: success for Display uncore prep patches (rev2)
From: Patchwork @ 2019-06-20 15:00 UTC (permalink / raw)
  To: Daniele Ceraolo Spurio; +Cc: intel-gfx
In-Reply-To: <20190620010021.20637-1-daniele.ceraolospurio@intel.com>

== Series Details ==

Series: Display uncore prep patches (rev2)
URL   : https://patchwork.freedesktop.org/series/62232/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_6312_full -> Patchwork_13357_full
====================================================

Summary
-------

  **SUCCESS**

  No regressions found.

  

Known issues
------------

  Here are the changes found in Patchwork_13357_full that come from known issues:

### IGT changes ###

#### Issues hit ####

  * igt@gem_eio@in-flight-suspend:
    - shard-kbl:          [PASS][1] -> [DMESG-WARN][2] ([fdo#110913 ]) +2 similar issues
   [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6312/shard-kbl3/igt@gem_eio@in-flight-suspend.html
   [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13357/shard-kbl6/igt@gem_eio@in-flight-suspend.html

  * igt@gem_eio@unwedge-stress:
    - shard-snb:          [PASS][3] -> [FAIL][4] ([fdo#109661])
   [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6312/shard-snb5/igt@gem_eio@unwedge-stress.html
   [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13357/shard-snb2/igt@gem_eio@unwedge-stress.html

  * igt@gem_persistent_relocs@forked-faulting-reloc-thrashing:
    - shard-snb:          [PASS][5] -> [DMESG-WARN][6] ([fdo#110789] / [fdo#110913 ])
   [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6312/shard-snb6/igt@gem_persistent_relocs@forked-faulting-reloc-thrashing.html
   [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13357/shard-snb7/igt@gem_persistent_relocs@forked-faulting-reloc-thrashing.html

  * igt@gem_tiled_swapping@non-threaded:
    - shard-apl:          [PASS][7] -> [DMESG-WARN][8] ([fdo#108686])
   [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6312/shard-apl8/igt@gem_tiled_swapping@non-threaded.html
   [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13357/shard-apl1/igt@gem_tiled_swapping@non-threaded.html

  * igt@i915_suspend@debugfs-reader:
    - shard-apl:          [PASS][9] -> [DMESG-WARN][10] ([fdo#108566]) +2 similar issues
   [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6312/shard-apl2/igt@i915_suspend@debugfs-reader.html
   [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13357/shard-apl5/igt@i915_suspend@debugfs-reader.html

  * igt@i915_suspend@sysfs-reader:
    - shard-kbl:          [PASS][11] -> [INCOMPLETE][12] ([fdo#103665] / [fdo#108767])
   [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6312/shard-kbl4/igt@i915_suspend@sysfs-reader.html
   [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13357/shard-kbl2/igt@i915_suspend@sysfs-reader.html

  * igt@kms_atomic_transition@1x-modeset-transitions-fencing:
    - shard-snb:          [PASS][13] -> [SKIP][14] ([fdo#109271])
   [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6312/shard-snb1/igt@kms_atomic_transition@1x-modeset-transitions-fencing.html
   [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13357/shard-snb2/igt@kms_atomic_transition@1x-modeset-transitions-fencing.html

  * igt@kms_flip@2x-plain-flip:
    - shard-hsw:          [PASS][15] -> [SKIP][16] ([fdo#109271]) +17 similar issues
   [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6312/shard-hsw5/igt@kms_flip@2x-plain-flip.html
   [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13357/shard-hsw1/igt@kms_flip@2x-plain-flip.html

  * igt@kms_flip@flip-vs-suspend:
    - shard-skl:          [PASS][17] -> [INCOMPLETE][18] ([fdo#109507])
   [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6312/shard-skl8/igt@kms_flip@flip-vs-suspend.html
   [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13357/shard-skl8/igt@kms_flip@flip-vs-suspend.html
    - shard-glk:          [PASS][19] -> [INCOMPLETE][20] ([fdo#103359] / [k.org#198133])
   [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6312/shard-glk9/igt@kms_flip@flip-vs-suspend.html
   [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13357/shard-glk4/igt@kms_flip@flip-vs-suspend.html

  * igt@kms_flip@flip-vs-suspend-interruptible:
    - shard-hsw:          [PASS][21] -> [INCOMPLETE][22] ([fdo#103540])
   [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6312/shard-hsw5/igt@kms_flip@flip-vs-suspend-interruptible.html
   [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13357/shard-hsw8/igt@kms_flip@flip-vs-suspend-interruptible.html

  * igt@kms_pipe_crc_basic@hang-read-crc-pipe-c:
    - shard-skl:          [PASS][23] -> [FAIL][24] ([fdo#103191])
   [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6312/shard-skl3/igt@kms_pipe_crc_basic@hang-read-crc-pipe-c.html
   [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13357/shard-skl4/igt@kms_pipe_crc_basic@hang-read-crc-pipe-c.html

  * igt@kms_plane@plane-panning-bottom-right-suspend-pipe-a-planes:
    - shard-kbl:          [PASS][25] -> [INCOMPLETE][26] ([fdo#103665])
   [25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6312/shard-kbl4/igt@kms_plane@plane-panning-bottom-right-suspend-pipe-a-planes.html
   [26]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13357/shard-kbl2/igt@kms_plane@plane-panning-bottom-right-suspend-pipe-a-planes.html

  * igt@kms_plane_alpha_blend@pipe-c-constant-alpha-min:
    - shard-skl:          [PASS][27] -> [FAIL][28] ([fdo#108145]) +1 similar issue
   [27]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6312/shard-skl3/igt@kms_plane_alpha_blend@pipe-c-constant-alpha-min.html
   [28]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13357/shard-skl4/igt@kms_plane_alpha_blend@pipe-c-constant-alpha-min.html

  * igt@kms_setmode@basic:
    - shard-apl:          [PASS][29] -> [FAIL][30] ([fdo#99912])
   [29]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6312/shard-apl6/igt@kms_setmode@basic.html
   [30]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13357/shard-apl2/igt@kms_setmode@basic.html

  * igt@kms_sysfs_edid_timing:
    - shard-hsw:          [PASS][31] -> [FAIL][32] ([fdo#100047])
   [31]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6312/shard-hsw6/igt@kms_sysfs_edid_timing.html
   [32]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13357/shard-hsw1/igt@kms_sysfs_edid_timing.html

  * igt@perf_pmu@rc6:
    - shard-kbl:          [PASS][33] -> [SKIP][34] ([fdo#109271])
   [33]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6312/shard-kbl7/igt@perf_pmu@rc6.html
   [34]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13357/shard-kbl7/igt@perf_pmu@rc6.html

  
#### Possible fixes ####

  * igt@gem_eio@wait-10ms:
    - shard-apl:          [DMESG-WARN][35] ([fdo#110913 ]) -> [PASS][36] +1 similar issue
   [35]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6312/shard-apl8/igt@gem_eio@wait-10ms.html
   [36]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13357/shard-apl1/igt@gem_eio@wait-10ms.html

  * igt@gem_persistent_relocs@forked-interruptible-thrashing:
    - shard-snb:          [DMESG-WARN][37] ([fdo#110789] / [fdo#110913 ]) -> [PASS][38]
   [37]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6312/shard-snb4/igt@gem_persistent_relocs@forked-interruptible-thrashing.html
   [38]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13357/shard-snb6/igt@gem_persistent_relocs@forked-interruptible-thrashing.html

  * igt@gem_userptr_blits@map-fixed-invalidate-busy-gup:
    - shard-kbl:          [DMESG-WARN][39] ([fdo#110913 ]) -> [PASS][40] +1 similar issue
   [39]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6312/shard-kbl4/igt@gem_userptr_blits@map-fixed-invalidate-busy-gup.html
   [40]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13357/shard-kbl2/igt@gem_userptr_blits@map-fixed-invalidate-busy-gup.html

  * igt@kms_cursor_edge_walk@pipe-b-128x128-top-edge:
    - shard-snb:          [SKIP][41] ([fdo#109271] / [fdo#109278]) -> [PASS][42]
   [41]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6312/shard-snb2/igt@kms_cursor_edge_walk@pipe-b-128x128-top-edge.html
   [42]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13357/shard-snb1/igt@kms_cursor_edge_walk@pipe-b-128x128-top-edge.html

  * igt@kms_cursor_legacy@2x-long-flip-vs-cursor-atomic:
    - shard-glk:          [FAIL][43] ([fdo#104873]) -> [PASS][44]
   [43]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6312/shard-glk8/igt@kms_cursor_legacy@2x-long-flip-vs-cursor-atomic.html
   [44]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13357/shard-glk6/igt@kms_cursor_legacy@2x-long-flip-vs-cursor-atomic.html

  * igt@kms_flip@2x-flip-vs-expired-vblank-interruptible:
    - shard-hsw:          [SKIP][45] ([fdo#109271]) -> [PASS][46] +26 similar issues
   [45]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6312/shard-hsw1/igt@kms_flip@2x-flip-vs-expired-vblank-interruptible.html
   [46]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13357/shard-hsw6/igt@kms_flip@2x-flip-vs-expired-vblank-interruptible.html

  * igt@kms_frontbuffer_tracking@fbc-suspend:
    - shard-apl:          [DMESG-WARN][47] ([fdo#108566]) -> [PASS][48]
   [47]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6312/shard-apl3/igt@kms_frontbuffer_tracking@fbc-suspend.html
   [48]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13357/shard-apl1/igt@kms_frontbuffer_tracking@fbc-suspend.html

  * igt@kms_pipe_crc_basic@suspend-read-crc-pipe-c:
    - shard-skl:          [INCOMPLETE][49] ([fdo#104108]) -> [PASS][50]
   [49]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6312/shard-skl4/igt@kms_pipe_crc_basic@suspend-read-crc-pipe-c.html
   [50]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13357/shard-skl2/igt@kms_pipe_crc_basic@suspend-read-crc-pipe-c.html

  * igt@kms_plane@plane-panning-bottom-right-pipe-b-planes:
    - shard-snb:          [SKIP][51] ([fdo#109271]) -> [PASS][52] +1 similar issue
   [51]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6312/shard-snb2/igt@kms_plane@plane-panning-bottom-right-pipe-b-planes.html
   [52]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13357/shard-snb1/igt@kms_plane@plane-panning-bottom-right-pipe-b-planes.html

  * igt@kms_setmode@basic:
    - shard-kbl:          [FAIL][53] ([fdo#99912]) -> [PASS][54]
   [53]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6312/shard-kbl1/igt@kms_setmode@basic.html
   [54]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13357/shard-kbl4/igt@kms_setmode@basic.html

  
#### Warnings ####

  * igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-pri-indfb-draw-pwrite:
    - shard-skl:          [FAIL][55] ([fdo#108040]) -> [FAIL][56] ([fdo#103167])
   [55]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6312/shard-skl9/igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-pri-indfb-draw-pwrite.html
   [56]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13357/shard-skl10/igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-pri-indfb-draw-pwrite.html

  * igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-spr-indfb-draw-mmap-gtt:
    - shard-skl:          [FAIL][57] ([fdo#103167]) -> [FAIL][58] ([fdo#108040])
   [57]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6312/shard-skl1/igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-spr-indfb-draw-mmap-gtt.html
   [58]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13357/shard-skl9/igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-spr-indfb-draw-mmap-gtt.html

  
  [fdo#100047]: https://bugs.freedesktop.org/show_bug.cgi?id=100047
  [fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167
  [fdo#103191]: https://bugs.freedesktop.org/show_bug.cgi?id=103191
  [fdo#103359]: https://bugs.freedesktop.org/show_bug.cgi?id=103359
  [fdo#103540]: https://bugs.freedesktop.org/show_bug.cgi?id=103540
  [fdo#103665]: https://bugs.freedesktop.org/show_bug.cgi?id=103665
  [fdo#104108]: https://bugs.freedesktop.org/show_bug.cgi?id=104108
  [fdo#104873]: https://bugs.freedesktop.org/show_bug.cgi?id=104873
  [fdo#108040]: https://bugs.freedesktop.org/show_bug.cgi?id=108040
  [fdo#108145]: https://bugs.freedesktop.org/show_bug.cgi?id=108145
  [fdo#108566]: https://bugs.freedesktop.org/show_bug.cgi?id=108566
  [fdo#108686]: https://bugs.freedesktop.org/show_bug.cgi?id=108686
  [fdo#108767]: https://bugs.freedesktop.org/show_bug.cgi?id=108767
  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [fdo#109278]: https://bugs.freedesktop.org/show_bug.cgi?id=109278
  [fdo#109507]: https://bugs.freedesktop.org/show_bug.cgi?id=109507
  [fdo#109661]: https://bugs.freedesktop.org/show_bug.cgi?id=109661
  [fdo#110789]: https://bugs.freedesktop.org/show_bug.cgi?id=110789
  [fdo#110913 ]: https://bugs.freedesktop.org/show_bug.cgi?id=110913 
  [fdo#99912]: https://bugs.freedesktop.org/show_bug.cgi?id=99912
  [k.org#198133]: https://bugzilla.kernel.org/show_bug.cgi?id=198133


Participating hosts (10 -> 9)
------------------------------

  Missing    (1): shard-iclb 


Build changes
-------------

  * Linux: CI_DRM_6312 -> Patchwork_13357

  CI_DRM_6312: 034e3ac6a2d180d188da927388b60c7e62c5655b @ git://anongit.freedesktop.org/gfx-ci/linux
  IGT_5061: c88ced79a7b71aec58f1d9c5c599ac2f431bcf7a @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_13357: 776298c3ec6b6f35479ec3ca194c3f11e809b916 @ git://anongit.freedesktop.org/gfx-ci/linux
  piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @ git://anongit.freedesktop.org/piglit

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13357/
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply

* [Qemu-devel] [PATCH v4 05/13] vfio: Add VM state change handler to know state of VM
From: Kirti Wankhede @ 2019-06-20 14:37 UTC (permalink / raw)
  To: alex.williamson, cjia
  Cc: Kirti Wankhede, Zhengxiao.zx, kevin.tian, yi.l.liu, yan.y.zhao,
	eskultet, ziye.yang, qemu-devel, cohuck, shuangtai.tst, dgilbert,
	zhi.a.wang, mlevitsk, pasic, aik, yulei.zhang, eauger, felipe,
	jonathan.davies, changpeng.liu, Ken.Xue
In-Reply-To: <1561041461-22326-1-git-send-email-kwankhede@nvidia.com>

VM state change handler gets called on change in VM's state. This is used to set
VFIO device state to _RUNNING.
VM state change handler, migration state change handler and log_sync listener
are called asynchronously, which sometimes lead to data corruption in migration
region. Initialised mutex that is used to serialize operations on migration data
region during saving state.

Signed-off-by: Kirti Wankhede <kwankhede@nvidia.com>
Reviewed-by: Neo Jia <cjia@nvidia.com>
---
 hw/vfio/migration.c           | 45 +++++++++++++++++++++++++++++++++++++++++++
 include/hw/vfio/vfio-common.h |  4 ++++
 2 files changed, 49 insertions(+)

diff --git a/hw/vfio/migration.c b/hw/vfio/migration.c
index ba58d9253d26..15af218c23d1 100644
--- a/hw/vfio/migration.c
+++ b/hw/vfio/migration.c
@@ -77,6 +77,41 @@ err:
     return ret;
 }
 
+static int vfio_migration_set_state(VFIODevice *vbasedev, uint32_t state)
+{
+    VFIOMigration *migration = vbasedev->migration;
+    VFIORegion *region = &migration->region.buffer;
+    int ret = 0;
+
+    ret = pwrite(vbasedev->fd, &state, sizeof(state),
+                 region->fd_offset + offsetof(struct vfio_device_migration_info,
+                                              device_state));
+    if (ret < 0) {
+        error_report("Failed to set migration state %d %s",
+                     ret, strerror(errno));
+        return ret;
+    }
+
+    vbasedev->device_state = state;
+    return 0;
+}
+
+static void vfio_vmstate_change(void *opaque, int running, RunState state)
+{
+    VFIODevice *vbasedev = opaque;
+
+    if ((vbasedev->vm_running != running) && running) {
+        int ret;
+
+        ret = vfio_migration_set_state(vbasedev, VFIO_DEVICE_STATE_RUNNING);
+        if (ret) {
+            error_report("Failed to set state RUNNING");
+        }
+    }
+
+    vbasedev->vm_running = running;
+}
+
 static int vfio_migration_init(VFIODevice *vbasedev,
                                struct vfio_region_info *info)
 {
@@ -91,6 +126,11 @@ static int vfio_migration_init(VFIODevice *vbasedev,
         return ret;
     }
 
+    qemu_mutex_init(&vbasedev->migration->lock);
+
+    vbasedev->vm_state = qemu_add_vm_change_state_handler(vfio_vmstate_change,
+                                                          vbasedev);
+
     return 0;
 }
 
@@ -127,11 +167,16 @@ void vfio_migration_finalize(VFIODevice *vbasedev)
         return;
     }
 
+    if (vbasedev->vm_state) {
+        qemu_del_vm_change_state_handler(vbasedev->vm_state);
+    }
+
     if (vbasedev->migration_blocker) {
         migrate_del_blocker(vbasedev->migration_blocker);
         error_free(vbasedev->migration_blocker);
     }
 
+    qemu_mutex_destroy(&vbasedev->migration->lock);
     vfio_migration_region_exit(vbasedev);
     g_free(vbasedev->migration);
 }
diff --git a/include/hw/vfio/vfio-common.h b/include/hw/vfio/vfio-common.h
index 1374a03470d8..f2392e97fa57 100644
--- a/include/hw/vfio/vfio-common.h
+++ b/include/hw/vfio/vfio-common.h
@@ -29,6 +29,7 @@
 #ifdef CONFIG_LINUX
 #include <linux/vfio.h>
 #endif
+#include "sysemu/sysemu.h"
 
 #define VFIO_MSG_PREFIX "vfio %s: "
 
@@ -129,6 +130,9 @@ typedef struct VFIODevice {
     unsigned int flags;
     VFIOMigration *migration;
     Error *migration_blocker;
+    uint32_t device_state;
+    VMChangeStateEntry *vm_state;
+    int vm_running;
 } VFIODevice;
 
 struct VFIODeviceOps {
-- 
2.7.0



^ permalink raw reply related

* Re: [PATCH v5 4/7] i2c: core: Make i2c_acpi_get_irq available to the rest of the I2C core
From: Andy Shevchenko @ 2019-06-20 14:59 UTC (permalink / raw)
  To: Charles Keepax
  Cc: wsa, mika.westerberg, jarkko.nikula, linux-i2c, linux-acpi,
	linux-kernel, benjamin.tissoires, jbroadus, patches
In-Reply-To: <20190620133420.4632-5-ckeepax@opensource.cirrus.com>

On Thu, Jun 20, 2019 at 02:34:17PM +0100, Charles Keepax wrote:
> In preparation for more refactoring make i2c_acpi_get_irq available
> outside i2c-core-acpi.c.

> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>

I'm not sure Rb tags are suitable for patches 4 and 5 since the changes made.

> +struct acpi_device;

Hmm... Doesn't acpi.h define that for !ACPI case?

>  #ifdef CONFIG_ACPI
>  const struct acpi_device_id *
>  i2c_acpi_match_device(const struct acpi_device_id *matches,
>  		      struct i2c_client *client);
>  void i2c_acpi_register_devices(struct i2c_adapter *adap);
> +
> +int i2c_acpi_get_irq(struct acpi_device *adev);

Since you call this afterwards with struct device from which companion is
derived, can't we directly use struct device as a parameter?

Yes, in case of adev call, it might be &adev->dev I suppose?

-- 
With Best Regards,
Andy Shevchenko



^ permalink raw reply

* RE: [PATCH 3/3] crypto: inside-secure - add support for using the EIP197 without firmware images
From: Pascal Van Leeuwen @ 2019-06-20 14:59 UTC (permalink / raw)
  To: Antoine Tenart
  Cc: Pascal van Leeuwen, linux-crypto@vger.kernel.org,
	herbert@gondor.apana.org.au, davem@davemloft.net
In-Reply-To: <20190620131512.GB4642@kwain>

> -----Original Message-----
> From: Antoine Tenart <antoine.tenart@bootlin.com>
> Sent: Thursday, June 20, 2019 3:15 PM
> To: Pascal Van Leeuwen <pvanleeuwen@insidesecure.com>
> Cc: Antoine Tenart <antoine.tenart@bootlin.com>; Pascal van Leeuwen <pascalvanl@gmail.com>; linux-crypto@vger.kernel.org;
> herbert@gondor.apana.org.au; davem@davemloft.net
> Subject: Re: [PATCH 3/3] crypto: inside-secure - add support for using the EIP197 without firmware images
> 
> Hi Pascal,
> 
> On Wed, Jun 19, 2019 at 02:37:44PM +0000, Pascal Van Leeuwen wrote:
> > > From: Antoine Tenart <antoine.tenart@bootlin.com>
> > > On Tue, Jun 18, 2019 at 07:56:24AM +0200, Pascal van Leeuwen wrote:
> >
> > > In addition to this, the direction the kernel has taken was to *remove*
> > > binary firmwares from its source code. I'm afraid adding this is a
> > > no-go.
> >
> > For a HW engineer, there really is no fundamental difference between
> > control register contents or an instruction word. They can both have
> > the exact same effects internal to the HW.
> > If I had disguised this as a handful of config reg writes writing
> > some #define'd magic values, probably no one would have even noticed.
> 
> I do not fully agree. If this is comparable to configuring h/w
> registers, then you could probably have defines explaining why each bit
> is set and what it's doing. Which would be fine.
> 
Strictly speaking, we (and probably most other HW vendors as well) don't do 
that for every register bit either, not even in the official Programmer Manual. 
Some bits are just "you don't need to know, just write this" :-)

But I get your point.

> > By that same definition, the tokens the driver generates for
> > processing could be considered "firmware" as well (as they are used by
> > the hardware in a very similar way) ...
> 
> Right. The main difference here is we do have a clear definition of what
> the tokens are doing. Thanks to your explanation, if this firmware is
> really looking like the token we're using, the words have a defined
> structure and the magic values could be generated with proper defines
> and macros. And I think it's the main issue here: it's not acceptable to
> have an array of magic values. If you can give a meaning to those bits,
> I see no reason why it couldn't be added to the driver.
> 
> (And I'm all for what you're trying to achieve here :)).
> 
Now we're reaching a tricky subject. Because I think if some people here
find out those token bits are explicitly documented in the driver, they
will not be so happy ... (don't worry, I won't wake any sleeping dogs :-)
We provide this information to our customers under NDA, but it's 
obviously quite sensitive information as it reveals a lot about the
inner workings of our HW design.

The encoding of the microengine control words is considered even
more sensitive, so we don't even provide that under NDA.
Adding that to the driver will probably get me in trouble.

So maybe putting these images in /lib/firmware is unavoidable, but
I'd really like to hear some more opinions on that subject.

> > > The proper solution I believe would be to support loading this "MiniFW",
> > > which (depending on the license) could be either distributed in the
> > > rootfs and loaded (like what's done currently), or through
> > > CONFIG_EXTRA_FIRMWARE.
> > >
> > That seems total overkill for just a handful of words though.
> 
> Given your explanation, I agree. (If those bits can have meaning).
> 
> Thanks!
> Antoine
> 
> --
> Antoine Ténart, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com

Thanks,

Pascal van Leeuwen
Silicon IP Architect, Multi-Protocol Engines @ Inside Secure
www.insidesecure.com


^ permalink raw reply

* [PATCH -next] Staging: kpc2000: kpc_dma: Fix platform_no_drv_owner.cocci warnings
From: YueHaibing @ 2019-06-20 14:59 UTC (permalink / raw)
  To: Greg Kroah-Hartman, Matt.Sickler, bnvandana, valerio.click,
	manwatkar, simon
  Cc: devel, kernel-janitors, YueHaibing, linux-kernel

Remove .owner field if calls are used which set it automatically
Generated by: scripts/coccinelle/api/platform_no_drv_owner.cocci

Signed-off-by: YueHaibing <yuehaibing@huawei.com>
---
 drivers/staging/kpc2000/kpc_dma/kpc_dma_driver.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/staging/kpc2000/kpc_dma/kpc_dma_driver.c b/drivers/staging/kpc2000/kpc_dma/kpc_dma_driver.c
index 08af269adabe..a05ae6d40db9 100644
--- a/drivers/staging/kpc2000/kpc_dma/kpc_dma_driver.c
+++ b/drivers/staging/kpc2000/kpc_dma/kpc_dma_driver.c
@@ -197,7 +197,6 @@ static struct platform_driver kpc_dma_plat_driver_i = {
 	.remove       = kpc_dma_remove,
 	.driver = {
 		.name   = KP_DRIVER_NAME_DMA_CONTROLLER,
-		.owner  = THIS_MODULE,
 	},
 };
 

^ permalink raw reply related

* [Qemu-devel] [Bug 1832535] Re: [riscv/regression] Missing tlb flush introduced in refactoring
From: QEMU @ 2019-06-20 13:22 UTC (permalink / raw)
  To: qemu-devel
In-Reply-To: <156034277180.16851.16263953909128956213.malonedeb@soybean.canonical.com>

It has been solved thanks to the mailing-list members.

** Changed in: qemu
       Status: Incomplete => Invalid

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1832535

Title:
  [riscv/regression] Missing tlb flush introduced in refactoring

Status in QEMU:
  Invalid

Bug description:
  Hello,

  In qemu-system-riscv64, following a QEMU update, I get all sort of
  weird and not easily reproducible crashes in my risc-v guest.

  I have bissected this issue to commit c7b951718815694284501ed01fec7acb8654db7b.
  Some TLB flushes were removed in the following places:
  target/riscv/cpu_helper.c: `csr_write_helper(env, s, CSR_MSTATUS);` -> `env->mstatus = s;` (twice)
  target/riscv/op_helper.c: `csr_write_helper(env, s, CSR_MSTATUS);` -> `env->mstatus = s;` (twice)

  Adding TLB flushes in all 4 places fixes the issues for me.

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1832535/+subscriptions


^ permalink raw reply

* [Qemu-devel] [PATCH v4 03/13] vfio: Add save and load functions for VFIO PCI devices
From: Kirti Wankhede @ 2019-06-20 14:37 UTC (permalink / raw)
  To: alex.williamson, cjia
  Cc: Kirti Wankhede, Zhengxiao.zx, kevin.tian, yi.l.liu, yan.y.zhao,
	eskultet, ziye.yang, qemu-devel, cohuck, shuangtai.tst, dgilbert,
	zhi.a.wang, mlevitsk, pasic, aik, yulei.zhang, eauger, felipe,
	jonathan.davies, changpeng.liu, Ken.Xue
In-Reply-To: <1561041461-22326-1-git-send-email-kwankhede@nvidia.com>

These functions save and restore PCI device specific data - config
space of PCI device.
Tested save and restore with MSI and MSIX type.

Signed-off-by: Kirti Wankhede <kwankhede@nvidia.com>
Reviewed-by: Neo Jia <cjia@nvidia.com>
---
 hw/vfio/pci.c | 112 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 hw/vfio/pci.h |  29 +++++++++++++++
 2 files changed, 141 insertions(+)

diff --git a/hw/vfio/pci.c b/hw/vfio/pci.c
index ce3fe96efe2c..09a0821a5b1c 100644
--- a/hw/vfio/pci.c
+++ b/hw/vfio/pci.c
@@ -1187,6 +1187,118 @@ void vfio_pci_write_config(PCIDevice *pdev,
     }
 }
 
+void vfio_pci_save_config(VFIODevice *vbasedev, QEMUFile *f)
+{
+    VFIOPCIDevice *vdev = container_of(vbasedev, VFIOPCIDevice, vbasedev);
+    PCIDevice *pdev = &vdev->pdev;
+    uint16_t pci_cmd;
+    int i;
+
+    for (i = 0; i < PCI_ROM_SLOT; i++) {
+        uint32_t bar;
+
+        bar = pci_default_read_config(pdev, PCI_BASE_ADDRESS_0 + i * 4, 4);
+        qemu_put_be32(f, bar);
+    }
+
+    qemu_put_be32(f, vdev->interrupt);
+    if (vdev->interrupt == VFIO_INT_MSI) {
+        uint32_t msi_flags, msi_addr_lo, msi_addr_hi = 0, msi_data;
+        bool msi_64bit;
+
+        msi_flags = pci_default_read_config(pdev, pdev->msi_cap + PCI_MSI_FLAGS,
+                                            2);
+        msi_64bit = (msi_flags & PCI_MSI_FLAGS_64BIT);
+
+        msi_addr_lo = pci_default_read_config(pdev,
+                                         pdev->msi_cap + PCI_MSI_ADDRESS_LO, 4);
+        qemu_put_be32(f, msi_addr_lo);
+
+        if (msi_64bit) {
+            msi_addr_hi = pci_default_read_config(pdev,
+                                             pdev->msi_cap + PCI_MSI_ADDRESS_HI,
+                                             4);
+        }
+        qemu_put_be32(f, msi_addr_hi);
+
+        msi_data = pci_default_read_config(pdev,
+                pdev->msi_cap + (msi_64bit ? PCI_MSI_DATA_64 : PCI_MSI_DATA_32),
+                2);
+        qemu_put_be32(f, msi_data);
+    } else if (vdev->interrupt == VFIO_INT_MSIX) {
+        uint16_t offset;
+
+        /* save enable bit and maskall bit */
+        offset = pci_default_read_config(pdev,
+                                       pdev->msix_cap + PCI_MSIX_FLAGS + 1, 2);
+        qemu_put_be16(f, offset);
+        msix_save(pdev, f);
+    }
+    pci_cmd = pci_default_read_config(pdev, PCI_COMMAND, 2);
+    qemu_put_be16(f, pci_cmd);
+}
+
+void vfio_pci_load_config(VFIODevice *vbasedev, QEMUFile *f)
+{
+    VFIOPCIDevice *vdev = container_of(vbasedev, VFIOPCIDevice, vbasedev);
+    PCIDevice *pdev = &vdev->pdev;
+    uint32_t interrupt_type;
+    uint32_t msi_flags, msi_addr_lo, msi_addr_hi = 0, msi_data;
+    uint16_t pci_cmd;
+    bool msi_64bit;
+    int i;
+
+    /* retore pci bar configuration */
+    pci_cmd = pci_default_read_config(pdev, PCI_COMMAND, 2);
+    vfio_pci_write_config(pdev, PCI_COMMAND,
+                        pci_cmd & (!(PCI_COMMAND_IO | PCI_COMMAND_MEMORY)), 2);
+    for (i = 0; i < PCI_ROM_SLOT; i++) {
+        uint32_t bar = qemu_get_be32(f);
+
+        vfio_pci_write_config(pdev, PCI_BASE_ADDRESS_0 + i * 4, bar, 4);
+    }
+    vfio_pci_write_config(pdev, PCI_COMMAND,
+                          pci_cmd | PCI_COMMAND_IO | PCI_COMMAND_MEMORY, 2);
+
+    interrupt_type = qemu_get_be32(f);
+
+    if (interrupt_type == VFIO_INT_MSI) {
+        /* restore msi configuration */
+        msi_flags = pci_default_read_config(pdev,
+                                            pdev->msi_cap + PCI_MSI_FLAGS, 2);
+        msi_64bit = (msi_flags & PCI_MSI_FLAGS_64BIT);
+
+        vfio_pci_write_config(pdev, pdev->msi_cap + PCI_MSI_FLAGS,
+                              msi_flags & (!PCI_MSI_FLAGS_ENABLE), 2);
+
+        msi_addr_lo = qemu_get_be32(f);
+        vfio_pci_write_config(pdev, pdev->msi_cap + PCI_MSI_ADDRESS_LO,
+                              msi_addr_lo, 4);
+
+        msi_addr_hi = qemu_get_be32(f);
+        if (msi_64bit) {
+            vfio_pci_write_config(pdev, pdev->msi_cap + PCI_MSI_ADDRESS_HI,
+                                  msi_addr_hi, 4);
+        }
+        msi_data = qemu_get_be32(f);
+        vfio_pci_write_config(pdev,
+                pdev->msi_cap + (msi_64bit ? PCI_MSI_DATA_64 : PCI_MSI_DATA_32),
+                msi_data, 2);
+
+        vfio_pci_write_config(pdev, pdev->msi_cap + PCI_MSI_FLAGS,
+                              msi_flags | PCI_MSI_FLAGS_ENABLE, 2);
+    } else if (interrupt_type == VFIO_INT_MSIX) {
+        uint16_t offset = qemu_get_be16(f);
+
+        /* load enable bit and maskall bit */
+        vfio_pci_write_config(pdev, pdev->msix_cap + PCI_MSIX_FLAGS + 1,
+                              offset, 2);
+        msix_load(pdev, f);
+    }
+    pci_cmd = qemu_get_be16(f);
+    vfio_pci_write_config(pdev, PCI_COMMAND, pci_cmd, 2);
+}
+
 /*
  * Interrupt setup
  */
diff --git a/hw/vfio/pci.h b/hw/vfio/pci.h
index 834a90d64686..847be5f56478 100644
--- a/hw/vfio/pci.h
+++ b/hw/vfio/pci.h
@@ -19,6 +19,7 @@
 #include "qemu/queue.h"
 #include "qemu/timer.h"
 
+#ifdef CONFIG_LINUX
 #define PCI_ANY_ID (~0)
 
 struct VFIOPCIDevice;
@@ -202,4 +203,32 @@ void vfio_display_reset(VFIOPCIDevice *vdev);
 int vfio_display_probe(VFIOPCIDevice *vdev, Error **errp);
 void vfio_display_finalize(VFIOPCIDevice *vdev);
 
+void vfio_pci_save_config(VFIODevice *vbasedev, QEMUFile *f);
+void vfio_pci_load_config(VFIODevice *vbasedev, QEMUFile *f);
+
+static inline Object *vfio_pci_get_object(VFIODevice *vbasedev)
+{
+    VFIOPCIDevice *vdev = container_of(vbasedev, VFIOPCIDevice, vbasedev);
+
+    return OBJECT(vdev);
+}
+
+#else
+static inline void vfio_pci_save_config(VFIODevice *vbasedev, QEMUFile *f)
+{
+    g_assert(false);
+}
+
+static inline void vfio_pci_load_config(VFIODevice *vbasedev, QEMUFile *f)
+{
+    g_assert(false);
+}
+
+static inline Object *vfio_pci_get_object(VFIODevice *vbasedev)
+{
+    return NULL;
+}
+
+#endif
+
 #endif /* HW_VFIO_VFIO_PCI_H */
-- 
2.7.0



^ permalink raw reply related

* Re: [PATCH 4/4] restore: add --intent-to-add (restoring worktree only)
From: Duy Nguyen @ 2019-06-20 14:58 UTC (permalink / raw)
  To: Derrick Stolee; +Cc: Git Mailing List
In-Reply-To: <e232fbc4-06ec-d4ed-826a-3bcbc923cafe@gmail.com>

On Thu, Jun 20, 2019 at 9:34 PM Derrick Stolee <stolee@gmail.com> wrote:
>
> On 6/20/2019 5:55 AM, Nguyễn Thái Ngọc Duy wrote:
> > "git restore --source" (without --staged) could create new files
> > (i.e. not present in index) on worktree to match the given source. But
> > the new files are not tracked, so both "git diff" and "git diff
> > <source>" ignore new files. "git commit -a" will not recreate a commit
> > exactly as the given source either.
> >
> > Add --intent-to-add to help track new files in this case, which is the
> > default on the least surprise principle.
>
> I was unfamiliar with this behavior, but did check the 'restore' command
> myself and saw that it would register the file as untracked. I agree that
> could be confusing for a user, so adding it to the staging environment
> makes this more in-line with `git checkout <rev> -- <path>`.

It's actually not the same as "git checkout <rev>" which would restore
<path> in both index and worktree, while "git restore" (no --staged)
only touches worktree . Try "git diff --cached" and "git diff" in both
cases, you'll see the differences.

Or in other words, "git commit" (no -a) after "git checkout" records
the version of <path> from <rev>, while "git commit" after "git
restore" will commit whatever you have before git-restore. "git commit
-a" behaves the same way for both (though it drops <path> without this
patch).

> > @@ -392,6 +393,69 @@ static int checkout_worktree(const struct checkout_opts *opts)
> >       return errs;
> >  }
> >
> > +/*
> > + * Input condition: r->index contains the file list matching worktree.
> > + *
> > + * r->index is reloaded with $GIT_DIR/index. Files that exist in the
> > + * current worktree but not in $GIT_DIR/index are added back as
> > + * intent-to-add.
> > + */
>
> Reading this code (and being unfamiliar with the cache array) I thought
> it might accidentally add untracked files from the working directory into
> the index. A local test verified that was not the case. Is that worth
> adding to your test below?

It never occured to me because r->index (before this function) should
be the same as <rev>, more or less. But yeah, adding a garbage file
and checking that it remains garbage is a good idea. I'll rename it
"untracked" though to be clear.
-- 
Duy

^ permalink raw reply

* Re: [PATCH V6 06/27] PCI: tegra: Add PCIe Gen2 link speed support
From: Manikanta Maddireddy @ 2019-06-20 14:57 UTC (permalink / raw)
  To: Lorenzo Pieralisi
  Cc: thierry.reding, bhelgaas, robh+dt, mark.rutland, jonathanh,
	vidyas, linux-tegra, linux-pci, devicetree
In-Reply-To: <20190620143251.GB31996@e121166-lin.cambridge.arm.com>



On 20-Jun-19 8:02 PM, Lorenzo Pieralisi wrote:
> On Tue, Jun 18, 2019 at 11:31:45PM +0530, Manikanta Maddireddy wrote:
>> Tegra124, Tegra132, Tegra210 and Tegra186 support Gen2 link speed. After
>> PCIe link is up in Gen1, set target link speed as Gen2 and retrain link.
>> Link switches to Gen2 speed if Gen2 capable end point is connected, else
>> link stays in Gen1.
>>
>> Per PCIe 4.0r0.9 sec 7.6.3.7 implementation note, driver need to wait for
>> PCIe LTSSM to come back from recovery before retraining the link.
>>
>> Signed-off-by: Manikanta Maddireddy <mmaddireddy@nvidia.com>
>> Acked-by: Thierry Reding <treding@nvidia.com>
>> ---
>> V6: No change
>>
>> V5: No change
>>
>> V4: No change
>>
>> V3: Added blank line after each while loop.
>>
>> V2: Changed "for loop" to "while", to make it compact and handled coding
>> style comments.
>>
>>  drivers/pci/controller/pci-tegra.c | 64 ++++++++++++++++++++++++++++++
>>  1 file changed, 64 insertions(+)
>>
>> diff --git a/drivers/pci/controller/pci-tegra.c b/drivers/pci/controller/pci-tegra.c
>> index 5e9fcef5f8eb..5d19067f7193 100644
>> --- a/drivers/pci/controller/pci-tegra.c
>> +++ b/drivers/pci/controller/pci-tegra.c
>> @@ -191,6 +191,8 @@
>>  #define  RP_LINK_CONTROL_STATUS_DL_LINK_ACTIVE	0x20000000
>>  #define  RP_LINK_CONTROL_STATUS_LINKSTAT_MASK	0x3fff0000
>>  
>> +#define RP_LINK_CONTROL_STATUS_2		0x000000b0
>> +
>>  #define PADS_CTL_SEL		0x0000009c
>>  
>>  #define PADS_CTL		0x000000a0
>> @@ -226,6 +228,7 @@
>>  #define PADS_REFCLK_CFG_DRVI_SHIFT		12 /* 15:12 */
>>  
>>  #define PME_ACK_TIMEOUT 10000
>> +#define LINK_RETRAIN_TIMEOUT 100000 /* in usec */
>>  
>>  struct tegra_msi {
>>  	struct msi_controller chip;
>> @@ -2089,6 +2092,64 @@ static bool tegra_pcie_port_check_link(struct tegra_pcie_port *port)
>>  	return false;
>>  }
>>  
>> +static void tegra_pcie_change_link_speed(struct tegra_pcie *pcie)
>> +{
>> +	struct device *dev = pcie->dev;
>> +	struct tegra_pcie_port *port, *tmp;
>> +	ktime_t deadline;
>> +	u32 value;
>> +
>> +	list_for_each_entry_safe(port, tmp, &pcie->ports, list) {
> And the reason to use the _safe version is ?
>
> Lorenzo

This function is called in probe and resume_noirq. list entry is deleted in
remove, I don't see any scenario where it can cause a race condition.
It is fine to drop _safe. I will fix it in next version.

Manikanta

>> +		/*
>> +		 * "Supported Link Speeds Vector" in "Link Capabilities 2"
>> +		 * is not supported by Tegra. tegra_pcie_change_link_speed()
>> +		 * is called only for Tegra chips which support Gen2.
>> +		 * So there no harm if supported link speed is not verified.
>> +		 */
>> +		value = readl(port->base + RP_LINK_CONTROL_STATUS_2);
>> +		value &= ~PCI_EXP_LNKSTA_CLS;
>> +		value |= PCI_EXP_LNKSTA_CLS_5_0GB;
>> +		writel(value, port->base + RP_LINK_CONTROL_STATUS_2);
>> +
>> +		/*
>> +		 * Poll until link comes back from recovery to avoid race
>> +		 * condition.
>> +		 */
>> +		deadline = ktime_add_us(ktime_get(), LINK_RETRAIN_TIMEOUT);
>> +
>> +		while (ktime_before(ktime_get(), deadline)) {
>> +			value = readl(port->base + RP_LINK_CONTROL_STATUS);
>> +			if ((value & PCI_EXP_LNKSTA_LT) == 0)
>> +				break;
>> +
>> +			usleep_range(2000, 3000);
>> +		}
>> +
>> +		if (value & PCI_EXP_LNKSTA_LT)
>> +			dev_warn(dev, "PCIe port %u link is in recovery\n",
>> +				 port->index);
>> +
>> +		/* Retrain the link */
>> +		value = readl(port->base + RP_LINK_CONTROL_STATUS);
>> +		value |= PCI_EXP_LNKCTL_RL;
>> +		writel(value, port->base + RP_LINK_CONTROL_STATUS);
>> +
>> +		deadline = ktime_add_us(ktime_get(), LINK_RETRAIN_TIMEOUT);
>> +
>> +		while (ktime_before(ktime_get(), deadline)) {
>> +			value = readl(port->base + RP_LINK_CONTROL_STATUS);
>> +			if ((value & PCI_EXP_LNKSTA_LT) == 0)
>> +				break;
>> +
>> +			usleep_range(2000, 3000);
>> +		}
>> +
>> +		if (value & PCI_EXP_LNKSTA_LT)
>> +			dev_err(dev, "failed to retrain link of port %u\n",
>> +				port->index);
>> +	}
>> +}
>> +
>>  static void tegra_pcie_enable_ports(struct tegra_pcie *pcie)
>>  {
>>  	struct device *dev = pcie->dev;
>> @@ -2113,6 +2174,9 @@ static void tegra_pcie_enable_ports(struct tegra_pcie *pcie)
>>  		tegra_pcie_port_disable(port);
>>  		tegra_pcie_port_free(port);
>>  	}
>> +
>> +	if (pcie->soc->has_gen2)
>> +		tegra_pcie_change_link_speed(pcie);
>>  }
>>  
>>  static void tegra_pcie_disable_ports(struct tegra_pcie *pcie)
>> -- 
>> 2.17.1
>>


^ permalink raw reply

* Re: linux not getting gpio interrupts on xenomai 3.0.8 on raspberrypi raspbian/stretch kernel 4.9
From: Harco Kuppens @ 2019-06-20 14:57 UTC (permalink / raw)
  To: Greg Gallagher; +Cc: Jan Kiszka, Xenomai@xenomai.org
In-Reply-To: <CALLqZ8T9B2Wxeu=w-Or_iYqY-spCZCN5xv+81cUbjaPS+c-vLw@mail.gmail.com>



Op 20/06/2019 om 16:45 schreef Greg Gallagher:
>
> Do you have sysfs interface turned on when building the mainline
> kernels?  Dumb question but it was turned off by default when I was
> doing my builds.
> Should be under Device Drivers => GPIO Support -> /sys/class/gpio
> (sysfs interface) when you do a menuconfig.
>
>
yes, I just checked.

It is the config option CONFIG_GPIO_SYSFS
and this option is set if you use

     make multi_v7_defconfig

to start with an initial config.

cheers
Harco

||

^ permalink raw reply

* [Buildroot] [git commit] package/flashbench: remove old toolchain microblaze & sh2a workaround
From: Thomas Petazzoni @ 2019-06-20 14:57 UTC (permalink / raw)
  To: buildroot

commit: https://git.buildroot.net/buildroot/commit/?id=dc7fa8491c633a112709a038ba44cd9999be33b5
branch: https://git.buildroot.net/buildroot/commit/?id=refs/heads/master

The old binary Microblaze and Sh2a toolchains were affected by Glibc
Bug 1228: https://sourceware.org/bugzilla/show_bug.cgi?id=1228 that
has been fixed in 2005, so let's remove actual work around:
'FLASHBENCH_CFLAGS += -std=gnu99' for both BR2_microblaze and BR2_sh2a
and remove local FLASHBENCH_CFLAGS in favour of TARGET_CFLAGS.

Signed-off-by: Giulio Benetti <giulio.benetti@micronovasrl.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
---
 package/flashbench/flashbench.mk | 9 +--------
 1 file changed, 1 insertion(+), 8 deletions(-)

diff --git a/package/flashbench/flashbench.mk b/package/flashbench/flashbench.mk
index cbcf9ea2d1..e89a250aa3 100644
--- a/package/flashbench/flashbench.mk
+++ b/package/flashbench/flashbench.mk
@@ -9,16 +9,9 @@ FLASHBENCH_SITE = git://git.linaro.org/people/arnd/flashbench.git
 FLASHBENCH_LICENSE = GPL-2.0
 FLASHBENCH_LICENSE_FILES = COPYING
 
-FLASHBENCH_CFLAGS = $(TARGET_CFLAGS)
-
-ifeq ($(BR2_microblaze)$(BR2_sh2a),y)
-# microblaze and sh2a toolchains only provide LLONG_MAX when used with gnu99 dialect
-FLASHBENCH_CFLAGS += -std=gnu99
-endif
-
 define FLASHBENCH_BUILD_CMDS
 	$(MAKE) -C $(@D) $(TARGET_CONFIGURE_OPTS) \
-		CFLAGS="$(FLASHBENCH_CFLAGS)" \
+		CFLAGS="$(TARGET_CFLAGS)" \
 		LDFLAGS="$(TARGET_LDFLAGS) -lrt"
 endef
 

^ permalink raw reply related

* Re: drm connectors, tegra,  and the web they weave (was Re: [PATCH 58/59] drm/todo: Add new debugfs todo)
From: Thierry Reding @ 2019-06-20 14:57 UTC (permalink / raw)
  To: Greg Kroah-Hartman
  Cc: Daniel Vetter, Intel Graphics Development, DRI Development,
	Jonathan Hunter, linux-tegra, Daniel Vetter
In-Reply-To: <20190618151938.GA2567@kroah.com>


[-- Attachment #1.1: Type: text/plain, Size: 2429 bytes --]

On Tue, Jun 18, 2019 at 05:19:38PM +0200, Greg Kroah-Hartman wrote:
> On Fri, Jun 14, 2019 at 10:36:14PM +0200, Daniel Vetter wrote:
> > Greg is busy already, but maybe he won't do everything ...
> > 
> > Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> > Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> > ---
> >  Documentation/gpu/todo.rst | 3 +++
> >  1 file changed, 3 insertions(+)
> > 
> > diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst
> > index 9717540ee28f..026e55c517e1 100644
> > --- a/Documentation/gpu/todo.rst
> > +++ b/Documentation/gpu/todo.rst
> > @@ -375,6 +375,9 @@ There's a bunch of issues with it:
> >    this (together with the drm_minor->drm_device move) would allow us to remove
> >    debugfs_init.
> >  
> > +- Drop the return code and error checking from all debugfs functions. Greg KH is
> > +  working on this already.
> 
> 
> Part of this work was to try to delete drm_debugfs_remove_files().
> 
> There are only 4 files that currently still call this function:
> 	drivers/gpu/drm/tegra/dc.c
> 	drivers/gpu/drm/tegra/dsi.c
> 	drivers/gpu/drm/tegra/hdmi.c
> 	drivers/gpu/drm/tegra/sor.c
> 
> For dc.c, the driver wants to add debugfs files to the struct drm_crtc
> debugfs directory.  Which is fine, but it has to do some special memory
> allocation to get the debugfs callback to point not to the struct
> drm_minor pointer, but rather the drm_crtc structure.

Actually the reason why the memory allocation is done is because there
can be multiple instances of the display controller. In fact, there's
always at least two (and up to four in later Tegra generations). The DRM
debugfs infrastructure, however, doesn't automatically duplicate the
data for each drm_debugfs_create_files() call and at the same time it
does not allow you to specify driver-private data other than by
embedding it in the drm_info_list structure. So rather than manually
create the drm_info_list for each display controller instance, the code
creates a template that is then duplicated and for which the driver-
private is then set. That way multiple invocations end up with different
data.

This is because of the extra indirection that the DRM debugfs
infrastructure introduces. It's in fact much easier to do this with just
plain debugfs function calls. The only downside is the boilerplate
required to make that happen.

Thierry

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

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

^ permalink raw reply

* Re: [PATCH V6 06/27] PCI: tegra: Add PCIe Gen2 link speed support
From: Manikanta Maddireddy @ 2019-06-20 14:57 UTC (permalink / raw)
  To: Lorenzo Pieralisi
  Cc: thierry.reding, bhelgaas, robh+dt, mark.rutland, jonathanh,
	vidyas, linux-tegra, linux-pci, devicetree
In-Reply-To: <20190620143251.GB31996@e121166-lin.cambridge.arm.com>



On 20-Jun-19 8:02 PM, Lorenzo Pieralisi wrote:
> On Tue, Jun 18, 2019 at 11:31:45PM +0530, Manikanta Maddireddy wrote:
>> Tegra124, Tegra132, Tegra210 and Tegra186 support Gen2 link speed. After
>> PCIe link is up in Gen1, set target link speed as Gen2 and retrain link.
>> Link switches to Gen2 speed if Gen2 capable end point is connected, else
>> link stays in Gen1.
>>
>> Per PCIe 4.0r0.9 sec 7.6.3.7 implementation note, driver need to wait for
>> PCIe LTSSM to come back from recovery before retraining the link.
>>
>> Signed-off-by: Manikanta Maddireddy <mmaddireddy@nvidia.com>
>> Acked-by: Thierry Reding <treding@nvidia.com>
>> ---
>> V6: No change
>>
>> V5: No change
>>
>> V4: No change
>>
>> V3: Added blank line after each while loop.
>>
>> V2: Changed "for loop" to "while", to make it compact and handled coding
>> style comments.
>>
>>  drivers/pci/controller/pci-tegra.c | 64 ++++++++++++++++++++++++++++++
>>  1 file changed, 64 insertions(+)
>>
>> diff --git a/drivers/pci/controller/pci-tegra.c b/drivers/pci/controller/pci-tegra.c
>> index 5e9fcef5f8eb..5d19067f7193 100644
>> --- a/drivers/pci/controller/pci-tegra.c
>> +++ b/drivers/pci/controller/pci-tegra.c
>> @@ -191,6 +191,8 @@
>>  #define  RP_LINK_CONTROL_STATUS_DL_LINK_ACTIVE	0x20000000
>>  #define  RP_LINK_CONTROL_STATUS_LINKSTAT_MASK	0x3fff0000
>>  
>> +#define RP_LINK_CONTROL_STATUS_2		0x000000b0
>> +
>>  #define PADS_CTL_SEL		0x0000009c
>>  
>>  #define PADS_CTL		0x000000a0
>> @@ -226,6 +228,7 @@
>>  #define PADS_REFCLK_CFG_DRVI_SHIFT		12 /* 15:12 */
>>  
>>  #define PME_ACK_TIMEOUT 10000
>> +#define LINK_RETRAIN_TIMEOUT 100000 /* in usec */
>>  
>>  struct tegra_msi {
>>  	struct msi_controller chip;
>> @@ -2089,6 +2092,64 @@ static bool tegra_pcie_port_check_link(struct tegra_pcie_port *port)
>>  	return false;
>>  }
>>  
>> +static void tegra_pcie_change_link_speed(struct tegra_pcie *pcie)
>> +{
>> +	struct device *dev = pcie->dev;
>> +	struct tegra_pcie_port *port, *tmp;
>> +	ktime_t deadline;
>> +	u32 value;
>> +
>> +	list_for_each_entry_safe(port, tmp, &pcie->ports, list) {
> And the reason to use the _safe version is ?
>
> Lorenzo

This function is called in probe and resume_noirq. list entry is deleted in
remove, I don't see any scenario where it can cause a race condition.
It is fine to drop _safe. I will fix it in next version.

Manikanta

>> +		/*
>> +		 * "Supported Link Speeds Vector" in "Link Capabilities 2"
>> +		 * is not supported by Tegra. tegra_pcie_change_link_speed()
>> +		 * is called only for Tegra chips which support Gen2.
>> +		 * So there no harm if supported link speed is not verified.
>> +		 */
>> +		value = readl(port->base + RP_LINK_CONTROL_STATUS_2);
>> +		value &= ~PCI_EXP_LNKSTA_CLS;
>> +		value |= PCI_EXP_LNKSTA_CLS_5_0GB;
>> +		writel(value, port->base + RP_LINK_CONTROL_STATUS_2);
>> +
>> +		/*
>> +		 * Poll until link comes back from recovery to avoid race
>> +		 * condition.
>> +		 */
>> +		deadline = ktime_add_us(ktime_get(), LINK_RETRAIN_TIMEOUT);
>> +
>> +		while (ktime_before(ktime_get(), deadline)) {
>> +			value = readl(port->base + RP_LINK_CONTROL_STATUS);
>> +			if ((value & PCI_EXP_LNKSTA_LT) == 0)
>> +				break;
>> +
>> +			usleep_range(2000, 3000);
>> +		}
>> +
>> +		if (value & PCI_EXP_LNKSTA_LT)
>> +			dev_warn(dev, "PCIe port %u link is in recovery\n",
>> +				 port->index);
>> +
>> +		/* Retrain the link */
>> +		value = readl(port->base + RP_LINK_CONTROL_STATUS);
>> +		value |= PCI_EXP_LNKCTL_RL;
>> +		writel(value, port->base + RP_LINK_CONTROL_STATUS);
>> +
>> +		deadline = ktime_add_us(ktime_get(), LINK_RETRAIN_TIMEOUT);
>> +
>> +		while (ktime_before(ktime_get(), deadline)) {
>> +			value = readl(port->base + RP_LINK_CONTROL_STATUS);
>> +			if ((value & PCI_EXP_LNKSTA_LT) == 0)
>> +				break;
>> +
>> +			usleep_range(2000, 3000);
>> +		}
>> +
>> +		if (value & PCI_EXP_LNKSTA_LT)
>> +			dev_err(dev, "failed to retrain link of port %u\n",
>> +				port->index);
>> +	}
>> +}
>> +
>>  static void tegra_pcie_enable_ports(struct tegra_pcie *pcie)
>>  {
>>  	struct device *dev = pcie->dev;
>> @@ -2113,6 +2174,9 @@ static void tegra_pcie_enable_ports(struct tegra_pcie *pcie)
>>  		tegra_pcie_port_disable(port);
>>  		tegra_pcie_port_free(port);
>>  	}
>> +
>> +	if (pcie->soc->has_gen2)
>> +		tegra_pcie_change_link_speed(pcie);
>>  }
>>  
>>  static void tegra_pcie_disable_ports(struct tegra_pcie *pcie)
>> -- 
>> 2.17.1
>>

^ permalink raw reply

* [PATCH -next] ASoC: SOF: Intel: hda: remove duplicated include from hda.c
From: YueHaibing @ 2019-06-20 14:57 UTC (permalink / raw)
  To: Liam Girdwood, Mark Brown, Jaroslav Kysela, Takashi Iwai,
	Bard Liao, Arnd Bergmann, Pierre-Louis Bossart, Zhu Yingjiang,
	Kai Vehmanen
  Cc: YueHaibing, alsa-devel, linux-kernel, kernel-janitors

Remove duplicated include.

Signed-off-by: YueHaibing <yuehaibing@huawei.com>
---
 sound/soc/sof/intel/hda.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/sound/soc/sof/intel/hda.c b/sound/soc/sof/intel/hda.c
index 51c1c1787de7..7f665392618f 100644
--- a/sound/soc/sof/intel/hda.c
+++ b/sound/soc/sof/intel/hda.c
@@ -19,7 +19,6 @@
 #include <sound/hda_register.h>
 
 #include <linux/module.h>
-#include <sound/hdaudio_ext.h>
 #include <sound/sof.h>
 #include <sound/sof/xtensa.h>
 #include "../ops.h"

^ permalink raw reply related

* [PATCH -next] drm/sti: Remove duplicated include from sti_drv.c
From: YueHaibing @ 2019-06-20 15:03 UTC (permalink / raw)
  To: Benjamin Gaignard, Vincent Abriou, David Airlie,
	Sam Ravnborg , Daniel Vetter
  Cc: kernel-janitors, YueHaibing, linux-kernel, dri-devel

Remove duplicated include.

Signed-off-by: YueHaibing <yuehaibing@huawei.com>
---
 drivers/gpu/drm/sti/sti_drv.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/sti/sti_drv.c b/drivers/gpu/drm/sti/sti_drv.c
index bb6ae6dd66c9..2edd666fb44a 100644
--- a/drivers/gpu/drm/sti/sti_drv.c
+++ b/drivers/gpu/drm/sti/sti_drv.c
@@ -23,7 +23,6 @@
 
 #include "sti_crtc.h"
 #include "sti_drv.h"
-#include "sti_drv.h"
 #include "sti_plane.h"
 
 #define DRIVER_NAME	"sti"



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

^ permalink raw reply related

* Re: [PATCH v1 5/5] coresight: etm4x: save/restore state across CPU low power states
From: Mathieu Poirier @ 2019-06-20 14:55 UTC (permalink / raw)
  To: Andrew Murray
  Cc: Al Grant, Suzuki K Poulose, Alexander Shishkin, Sudeep Holla,
	linux-arm-kernel, Mike Leach
In-Reply-To: <20190620114116.GE20984@e119886-lin.cambridge.arm.com>

On Thu, 20 Jun 2019 at 05:41, Andrew Murray <andrew.murray@arm.com> wrote:
>
> On Wed, Jun 19, 2019 at 10:22:58AM -0600, Mathieu Poirier wrote:
> > On Wed, 19 Jun 2019 at 05:07, Sudeep Holla <sudeep.holla@arm.com> wrote:
> > >
> > > On Wed, Jun 19, 2019 at 11:38:12AM +0100, Suzuki K Poulose wrote:
> > > > Cc: Al Grant, Mike Leach
> > > >
> > > > Hi Sudeep,
> > > >
> > > > On 18/06/2019 14:21, Sudeep Holla wrote:
> > > > > On Tue, Jun 18, 2019 at 01:54:33PM +0100, Andrew Murray wrote:
> > > > > > Some hardware will ignore bit TRCPDCR.PU which is used to signal
> > > > > > to hardware that power should not be removed from the trace unit.
> > > > >
> > > > > So, how or can we identify or discover such system ? DT/ACPI ?
> > > > >
> > > >
> > > > I don't think there is a mechanism at the moment to identify such
> > > > systems. But if we really need to know this information, we could
> > > > always think about it.
> > > >
> > >
> > > I prefer that as we shouldn't systems that are not broken.
> > >
> > > > > > Let's mitigate against this by saving and restoring the trace
> > > > > > unit state when the CPU enters low power states.
> > > > > >
> > > > >
> > > > > I prefer to do this conditionally. It's unnecessary on systems which
> > > > > don't ignore the TRCPDCR.PU and I really don't like them to be penalised
> > > > > while we want to add this support for *broken* systems.
> > > >
> > > > It is conditional. i.e, you may disable the operation using a kernel/module
> > > > parameter, which I think should be mentioned in the description here.
> > > >
> > >
> > > Why should the user of coresight need to know if the corresponding
> > > hardware module is broken or not. I prefer the firmware tell OS.
> >
> > I think using ACPI/DT is the best and simplest solution.
>
> I certainly agree that it feels wrong to have a default level of support
> which is targeted at broken systems. However the penalty (latency) for doing so
> doesn't seem high - seeing as this only effects users that are actively using
> coresight (I assume self hosted mode is only used as a debug tool, rather than to
> obtain metrics during normal use?).
>
> Adding some broken tag in ACPI/DT seems like a good solution - assuming it will
> get adopted and used in systems. The existing "disable_pm_save" module option
> can be renamed to "enable_pm_save" for those that have less control of their
> firmware.

"enable_pm_save" would work.

>
> Unless of course we think it's unlikely we'll ever see hardware that isn't
> broken - I don't have enough knowledge of how likely or not this is.

The unlikely part is to see platforms where TRCPDCR.PU is taken into
account.  As I previously indicated Juno is the only one that handles
it correctly.

Thanks,
Mathieu

>
> Another solution might be to enable save/restore by default (as it is now),
> and then on resume we read the hardware registers to determine if state was
> lost. If it wasn't lost then we can disable the save/restore feature. (Though
> is it possible for systems to be partly broken, e.g. working for some CPUs
> but not others?). With this approach on good systems you only get penalised
> once.
>
> >
> > >
> > > > >
> > > > > This is generally most useful to debug CPU suspend/resume exercising
> > > > > the code path completely with emulated CPU power on/off as most of the
> > > > > systems have the trace unit and the CPUs in the same power domain.
> > > >
> > > > I understand, which is specifically why this comes with an option to handle
> > > > such cases.
> > > >
> > >
> > > OK
>
> I'll update the cover letter and commit messages to reflect that this
> option is present. (And likewise for conditionally saving/restoring the
> registers only if coresight is in use).
>
> > >
> > > > >
> > > > > Just curious if this reported on any platforms ?
> > > > >
> > > >
> > > > I have heard people complaining about this, but not sure about the exact
> > > > platform(s) affected.
> >
> > Are you referring to platforms that ignore the TRCPDCR.PU bit?  If so
> > Juno is the only one that does _not_ ignore it, hence the need to find
> > another solution.
> >
> > > >
> > >
> > > One we add mechanism in place, platform need to advertise that it's
> > > broken in firmware(DT/ACPI). Or just have a blacklist if we don't
> > > want to add anything extra to the firmware(DT/ACPI) ?
> > >
> > > > > I wounder if we can use TRCPDSR(Power Down Status Register) to check the
> > > > > status. I know on Juno, it doesn't loose context rather the power down
> > > > > is emulated and saving/restoring may not be needed at all. Have you
> > > > > tested on Juno with and without these patches and seen any difference ?
> > > >
> > > > The problem is trace unit looses power the moment CPU goes to low power mode
> > > > and if we try to read this register, it could cause unexpected side-effects.
> > > >
> > >
> > > No I meant before CPU loose power i.e. in CPU_ENTER case. However I do
> > > remember you/Andrew mentioning that even that may be bogus on broken
> > > systems, so firmware is only way to avoid penalising all platforms IMO.
> >
> > I wouldn't assume that anything is working properly.
>
> Thanks,
>
> Andrew Murray
>
> >
> > >
> > > Or other option is to stop the coresight tracing session like we do
> > > for PMUs or not entering idle when there's any active coresight session
> > > in progress on such platforms.
> > >
> > > --
> > > Regards,
> > > Sudeep

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* [Qemu-devel] [PATCH v4 00/13] Add migration support for VFIO device
From: Kirti Wankhede @ 2019-06-20 14:37 UTC (permalink / raw)
  To: alex.williamson, cjia
  Cc: Kirti Wankhede, Zhengxiao.zx, kevin.tian, yi.l.liu, yan.y.zhao,
	eskultet, ziye.yang, qemu-devel, cohuck, shuangtai.tst, dgilbert,
	zhi.a.wang, mlevitsk, pasic, aik, yulei.zhang, eauger, felipe,
	jonathan.davies, changpeng.liu, Ken.Xue

Add migration support for VFIO device

This Patch set include patches as below:
- Define KABI for VFIO device for migration support.
- Added save and restore functions for PCI configuration space
- Generic migration functionality for VFIO device.
  * This patch set adds functionality only for PCI devices, but can be
    extended to other VFIO devices.
  * Added all the basic functions required for pre-copy, stop-and-copy and
    resume phases of migration.
  * Added state change notifier and from that notifier function, VFIO
    device's state changed is conveyed to VFIO device driver.
  * During save setup phase and resume/load setup phase, migration region
    is queried and is used to read/write VFIO device data.
  * .save_live_pending and .save_live_iterate are implemented to use QEMU's
    functionality of iteration during pre-copy phase.
  * In .save_live_complete_precopy, that is in stop-and-copy phase,
    iteration to read data from VFIO device driver is implemented till pending
    bytes returned by driver are not zero.
  * Added function to get dirty pages bitmap for the pages which are used by
    driver.
- Add vfio_listerner_log_sync to mark dirty pages.
- Make VFIO PCI device migration capable. If migration region is not provided by
  driver, migration is blocked.

Below is the flow of state change for live migration where states in brackets
represent VM state, migration state and VFIO device state as:
    (VM state, MIGRATION_STATUS, VFIO_DEVICE_STATE)

Live migration save path:
        QEMU normal running state
        (RUNNING, _NONE, _RUNNING)
                        |
    migrate_init spawns migration_thread.
    (RUNNING, _SETUP, _RUNNING|_SAVING)
    Migration thread then calls each device's .save_setup()
                        |
    (RUNNING, _ACTIVE, _RUNNING|_SAVING)
    If device is active, get pending bytes by .save_live_pending()
    if pending bytes >= threshold_size,  call save_live_iterate()
    Data of VFIO device for pre-copy phase is copied.
    Iterate till pending bytes converge and are less than threshold
                        |
    On migration completion, vCPUs stops and calls .save_live_complete_precopy
    for each active device. VFIO device is then transitioned in
     _SAVING state.
    (FINISH_MIGRATE, _DEVICE, _SAVING)
    For VFIO device, iterate in  .save_live_complete_precopy  until
    pending data is 0.
    (FINISH_MIGRATE, _DEVICE, _STOPPED)
                        |
    (FINISH_MIGRATE, _COMPLETED, STOPPED)
    Migraton thread schedule cleanup bottom half and exit

Live migration resume path:
    Incomming migration calls .load_setup for each device
    (RESTORE_VM, _ACTIVE, STOPPED)
                        |
    For each device, .load_state is called for that device section data
                        |
    At the end, called .load_cleanup for each device and vCPUs are started.
                        |
        (RUNNING, _NONE, _RUNNING)

Note that:
- Migration post copy is not supported.

v3 -> v4:
- Added one more bit for _RESUMING flag to be set explicitly.
- data_offset field is read-only for user space application.
- data_size is read for every iteration before reading data from migration, that
  is removed assumption that data will be till end of migration region.
- If vendor driver supports mappable sparsed region, map those region during
  setup state of save/load, similarly unmap those from cleanup routines.
- Handles race condition that causes data corruption in migration region during
  save device state by adding mutex and serialiaing save_buffer and
  get_dirty_pages routines.
- Skip called get_dirty_pages routine for mapped MMIO region of device.
- Added trace events.
- Splitted into multiple functional patches.

v2 -> v3:
- Removed enum of VFIO device states. Defined VFIO device state with 2 bits.
- Re-structured vfio_device_migration_info to keep it minimal and defined action
  on read and write access on its members.

v1 -> v2:
- Defined MIGRATION region type and sub-type which should be used with region
  type capability.
- Re-structured vfio_device_migration_info. This structure will be placed at 0th
  offset of migration region.
- Replaced ioctl with read/write for trapped part of migration region.
- Added both type of access support, trapped or mmapped, for data section of the
  region.
- Moved PCI device functions to pci file.
- Added iteration to get dirty page bitmap until bitmap for all requested pages
  are copied.

Thanks,
Kirti


Kirti Wankhede (13):
  vfio: KABI for migration interface
  vfio: Add function to unmap VFIO region
  vfio: Add save and load functions for VFIO PCI devices
  vfio: Add migration region initialization and finalize function
  vfio: Add VM state change handler to know state of VM
  vfio: Add migration state change notifier
  vfio: Register SaveVMHandlers for VFIO device
  vfio: Add save state functions to SaveVMHandlers
  vfio: Add load state functions to SaveVMHandlers
  vfio: Add function to get dirty page list
  vfio: Add vfio_listerner_log_sync to mark dirty pages
  vfio: Make vfio-pci device migration capable.
  vfio: Add trace events in migration code path

 hw/vfio/Makefile.objs         |   2 +-
 hw/vfio/common.c              |  55 +++
 hw/vfio/migration.c           | 815 ++++++++++++++++++++++++++++++++++++++++++
 hw/vfio/pci.c                 | 126 ++++++-
 hw/vfio/pci.h                 |  29 ++
 hw/vfio/trace-events          |  19 +
 include/hw/vfio/vfio-common.h |  22 ++
 linux-headers/linux/vfio.h    |  71 ++++
 8 files changed, 1132 insertions(+), 7 deletions(-)
 create mode 100644 hw/vfio/migration.c

-- 
2.7.0



^ permalink raw reply

* Re: [PATCH 2/2] coresight: Abort probe for missing CPU phandle
From: Sai Prakash Ranjan @ 2019-06-20 14:55 UTC (permalink / raw)
  To: Suzuki K Poulose, mathieu.poirier, leo.yan, alexander.shishkin,
	david.brown, mark.rutland
  Cc: rnayak, linux-arm-msm, linux-kernel, sibis, vivek.gautam,
	linux-arm-kernel
In-Reply-To: <1ddee3c1-8299-1991-eb88-151b9c3ee180@arm.com>

On 6/20/2019 7:28 PM, Suzuki K Poulose wrote:
> 
> 
> On 20/06/2019 14:45, Sai Prakash Ranjan wrote:
>> Currently the coresight etm and cpu-debug drivers
>> assume the affinity to CPU0 returned by coresight
>> platform and continue the probe in case of missing
>> CPU phandle. This is not true and leads to crash
>> in some cases, so abort the probe in case of missing
>> CPU phandle.
>>
>> Signed-off-by: Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org>
>> ---
>>   drivers/hwtracing/coresight/coresight-cpu-debug.c | 3 +++
>>   drivers/hwtracing/coresight/coresight-etm3x.c     | 3 +++
>>   drivers/hwtracing/coresight/coresight-etm4x.c     | 3 +++
>>   3 files changed, 9 insertions(+)
>>
>> diff --git a/drivers/hwtracing/coresight/coresight-cpu-debug.c 
>> b/drivers/hwtracing/coresight/coresight-cpu-debug.c
>> index 07a1367c733f..43f32fa71ff9 100644
>> --- a/drivers/hwtracing/coresight/coresight-cpu-debug.c
>> +++ b/drivers/hwtracing/coresight/coresight-cpu-debug.c
>> @@ -579,6 +579,9 @@ static int debug_probe(struct amba_device *adev, 
>> const struct amba_id *id)
>>           return -ENOMEM;
>>       drvdata->cpu = coresight_get_cpu(dev);
>> +    if (drvdata->cpu == -ENODEV)
>> +        return -ENODEV;
> 
> if (drvdata->cpu < 0)
>      return drvdata->cpu;
> 
> Same everywhere below ?
> 
> Also, I would like to hear Mathieu's thoughts on this change. If he's OK
> with it:
> 
> Reviewed-by: Suzuki K Poulose <suzuki.poulose@arm.com> with the change 
> above.
> 
> 

Thanks, I will make the change and repost.

-Sai

-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* Re: [PATCH 2/2] coresight: Abort probe for missing CPU phandle
From: Sai Prakash Ranjan @ 2019-06-20 14:55 UTC (permalink / raw)
  To: Suzuki K Poulose, mathieu.poirier, leo.yan, alexander.shishkin,
	david.brown, mark.rutland
  Cc: rnayak, vivek.gautam, sibis, linux-arm-kernel, linux-kernel,
	linux-arm-msm
In-Reply-To: <1ddee3c1-8299-1991-eb88-151b9c3ee180@arm.com>

On 6/20/2019 7:28 PM, Suzuki K Poulose wrote:
> 
> 
> On 20/06/2019 14:45, Sai Prakash Ranjan wrote:
>> Currently the coresight etm and cpu-debug drivers
>> assume the affinity to CPU0 returned by coresight
>> platform and continue the probe in case of missing
>> CPU phandle. This is not true and leads to crash
>> in some cases, so abort the probe in case of missing
>> CPU phandle.
>>
>> Signed-off-by: Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org>
>> ---
>>   drivers/hwtracing/coresight/coresight-cpu-debug.c | 3 +++
>>   drivers/hwtracing/coresight/coresight-etm3x.c     | 3 +++
>>   drivers/hwtracing/coresight/coresight-etm4x.c     | 3 +++
>>   3 files changed, 9 insertions(+)
>>
>> diff --git a/drivers/hwtracing/coresight/coresight-cpu-debug.c 
>> b/drivers/hwtracing/coresight/coresight-cpu-debug.c
>> index 07a1367c733f..43f32fa71ff9 100644
>> --- a/drivers/hwtracing/coresight/coresight-cpu-debug.c
>> +++ b/drivers/hwtracing/coresight/coresight-cpu-debug.c
>> @@ -579,6 +579,9 @@ static int debug_probe(struct amba_device *adev, 
>> const struct amba_id *id)
>>           return -ENOMEM;
>>       drvdata->cpu = coresight_get_cpu(dev);
>> +    if (drvdata->cpu == -ENODEV)
>> +        return -ENODEV;
> 
> if (drvdata->cpu < 0)
>      return drvdata->cpu;
> 
> Same everywhere below ?
> 
> Also, I would like to hear Mathieu's thoughts on this change. If he's OK
> with it:
> 
> Reviewed-by: Suzuki K Poulose <suzuki.poulose@arm.com> with the change 
> above.
> 
> 

Thanks, I will make the change and repost.

-Sai

-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation

^ permalink raw reply

* Re: [Qemu-devel] [SeaBIOS] [PATCH v3 3/4] geometry: Add boot_lchs_find_*() utility functions
From: Kevin O'Connor @ 2019-06-20 14:37 UTC (permalink / raw)
  To: Sam Eiderman
  Cc: kwolf, qemu-block, arbel.moshe, seabios, qemu-devel, mreitz,
	liran.alon, kraxel, karl.heubaum
In-Reply-To: <20190619092352.23583-4-shmuel.eiderman@oracle.com>

On Wed, Jun 19, 2019 at 12:23:51PM +0300, Sam Eiderman wrote:
> Adding the following utility functions:
> 
>     * boot_lchs_find_pci_device
>     * boot_lchs_find_scsi_device
>     * boot_lchs_find_ata_device

FWIW, this leads to a bit of code duplication.  I think it would be
preferable to refactor the bootprio_find_XYZ() calls.  Instead of
returning an 'int prio' they could return a znprintf'd 'char *devpath'
instead.  Then the boot_add_XYZ() calls could directly call
find_prio(devpath). The boot_add_hd() could then directly populate
drive->lchs or call setup_translation().

-Kevin


^ permalink raw reply

* Re: [PATCH] Revert "drm/amd/display: Enable fast plane updates when state->allow_modeset = true"
From: Mike Lothian @ 2019-06-20 14:55 UTC (permalink / raw)
  To: Nicholas Kazlauskas; +Cc: David Francis, Harry Wentland, amd-gfx list
In-Reply-To: <20190620123403.10252-1-nicholas.kazlauskas-5C7GfCeVMHo@public.gmane.org>

Just FYI my system was Raven1 not Raven2

On Thu, 20 Jun 2019 at 13:34, Nicholas Kazlauskas
<nicholas.kazlauskas@amd.com> wrote:
>
> This reverts commit ebc8c6f18322ad54275997a888ca1731d74b711f.
>
> There are still missing corner cases with cursor interaction and these
> fast plane updates on Picasso and Raven2 leading to endless PSTATE
> warnings for typical desktop usage depending on the userspace.
>
> This change should be reverted until these issues have been resolved.
>
> Cc: David Francis <david.francis@amd.com>
> Cc: Harry Wentland <harry.wentland@amd.com>
> Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
> ---
>  drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 8 ++++++++
>  1 file changed, 8 insertions(+)
>
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> index 33dcd4187157..d6acbcfa570c 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> @@ -6471,6 +6471,14 @@ static bool should_reset_plane(struct drm_atomic_state *state,
>         struct drm_crtc_state *new_crtc_state;
>         int i;
>
> +       /*
> +        * TODO: Remove this hack once the checks below are sufficient
> +        * enough to determine when we need to reset all the planes on
> +        * the stream.
> +        */
> +       if (state->allow_modeset)
> +               return true;
> +
>         /* Exit early if we know that we're adding or removing the plane. */
>         if (old_plane_state->crtc != new_plane_state->crtc)
>                 return true;
> --
> 2.17.1
>
> _______________________________________________
> amd-gfx mailing list
> amd-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

^ permalink raw reply

* [U-Boot] [PATCH] fastboot: Remove "bootloader-version" variable
From: Igor Opaniuk @ 2019-06-20 14:54 UTC (permalink / raw)
  To: u-boot
In-Reply-To: <20190620140001.12811-1-semen.protsenko@linaro.org>

Hi Sam,

On Thu, Jun 20, 2019 at 5:00 PM Sam Protsenko
<semen.protsenko@linaro.org> wrote:
>
> As per [1], there is no such fastboot variable as "bootloader-version".
> Only "version-bootloader" is supported. Let's reflect this and not
> confuse users further.
>
> [1] https://android.googlesource.com/platform/system/core/+/master/fastboot/README.md#client-variables
>
> Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org>
> ---
>  doc/README.android-fastboot  | 4 ++--
>  drivers/fastboot/fb_getvar.c | 9 +++------
>  2 files changed, 5 insertions(+), 8 deletions(-)
>
> diff --git a/doc/README.android-fastboot b/doc/README.android-fastboot
> index 431191c473..ce852a4fd1 100644
> --- a/doc/README.android-fastboot
> +++ b/doc/README.android-fastboot
> @@ -169,8 +169,8 @@ On the client side you can fetch the bootloader version for instance:
>
>  ::
>
> -   $ fastboot getvar bootloader-version
> -   bootloader-version: U-Boot 2014.04-00005-gd24cabc
> +   $ fastboot getvar version-bootloader
> +   version-bootloader: U-Boot 2014.04-00005-gd24cabc
>     finished. total time: 0.000s
>
>  or initiate a reboot:
> diff --git a/drivers/fastboot/fb_getvar.c b/drivers/fastboot/fb_getvar.c
> index fd0823b2bf..ebe5c8a104 100644
> --- a/drivers/fastboot/fb_getvar.c
> +++ b/drivers/fastboot/fb_getvar.c
> @@ -12,7 +12,7 @@
>  #include <version.h>
>
>  static void getvar_version(char *var_parameter, char *response);
> -static void getvar_bootloader_version(char *var_parameter, char *response);
> +static void getvar_version_bootloader(char *var_parameter, char *response);
>  static void getvar_downloadsize(char *var_parameter, char *response);
>  static void getvar_serialno(char *var_parameter, char *response);
>  static void getvar_version_baseband(char *var_parameter, char *response);
> @@ -37,12 +37,9 @@ static const struct {
>         {
>                 .variable = "version",
>                 .dispatch = getvar_version
> -       }, {
> -               .variable = "bootloader-version",
> -               .dispatch = getvar_bootloader_version
>         }, {
>                 .variable = "version-bootloader",
> -               .dispatch = getvar_bootloader_version
> +               .dispatch = getvar_version_bootloader
>         }, {
>                 .variable = "downloadsize",
>                 .dispatch = getvar_downloadsize
> @@ -131,7 +128,7 @@ static void getvar_version(char *var_parameter, char *response)
>         fastboot_okay(FASTBOOT_VERSION, response);
>  }
>
> -static void getvar_bootloader_version(char *var_parameter, char *response)
> +static void getvar_version_bootloader(char *var_parameter, char *response)
>  {
>         fastboot_okay(U_BOOT_VERSION, response);
>  }
> --
> 2.20.1
>

My two cents here,

Based on the commit messages from "git log --grep=bootloader-version"
people prefer to use "bootloader-version" instead of
"version-bootloader", and totally removing it will probably affect
usual workflow with fastboot (probably someone will be suprised that
"bootloader-version" doesn't work anymore), including some CI automate
testing etc (if there is any);

I think I does make sense to involve all of them to this discussion
also (already added to CC).

-- 
Best regards - Freundliche Grüsse - Meilleures salutations

Igor Opaniuk

mailto: igor.opaniuk at gmail.com
skype: igor.opanyuk
+380 (93) 836 40 67
http://ua.linkedin.com/in/iopaniuk

^ permalink raw reply


This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.