Re: [Intel-gfx] [PATCH v5 1/4] pwm: rename pwm_apply_state() to pwm_apply_cansleep()
On Sat, 18 Nov 2023, Sean Young wrote: > In order to introduce a pwm api which can be used from atomic context, > we will need two functions for applying pwm changes: > > int pwm_apply_cansleep(struct pwm *, struct pwm_state *); > int pwm_apply_atomic(struct pwm *, struct pwm_state *); > > This commit just deals with renaming pwm_apply_state(), a following > commit will introduce the pwm_apply_atomic() function. > > Acked-by: Hans de Goede > Acked-by: Jani Nikula > Signed-off-by: Sean Young > --- > Documentation/driver-api/pwm.rst | 8 +++--- > .../gpu/drm/i915/display/intel_backlight.c| 6 ++-- > drivers/gpu/drm/solomon/ssd130x.c | 2 +- > drivers/hwmon/pwm-fan.c | 8 +++--- > drivers/input/misc/da7280.c | 4 +-- > drivers/input/misc/pwm-beeper.c | 4 +-- > drivers/input/misc/pwm-vibra.c| 8 +++--- > drivers/leds/leds-pwm.c | 2 +- > drivers/leds/rgb/leds-pwm-multicolor.c| 4 +-- Acked-by: Lee Jones > drivers/media/rc/pwm-ir-tx.c | 4 +-- > drivers/platform/x86/lenovo-yogabook.c| 2 +- > drivers/pwm/core.c| 18 ++-- > drivers/pwm/pwm-twl-led.c | 2 +- > drivers/pwm/pwm-vt8500.c | 2 +- > drivers/pwm/sysfs.c | 10 +++ > drivers/regulator/pwm-regulator.c | 4 +-- > drivers/video/backlight/lm3630a_bl.c | 2 +- > drivers/video/backlight/lp855x_bl.c | 2 +- > drivers/video/backlight/pwm_bl.c | 12 Acked-by: Lee Jones > drivers/video/fbdev/ssd1307fb.c | 2 +- > include/linux/pwm.h | 28 +-- > 21 files changed, 67 insertions(+), 67 deletions(-) [...] -- Lee Jones [李琼斯]
Re: [Intel-gfx] [PATCH 01/19] drm/i915/i915_scatterlist: Fix kerneldoc formatting issue - missing '@'
On Wed, 05 Apr 2023, Jani Nikula wrote: > On Wed, 05 Apr 2023, Lee Jones wrote: > > On Tue, 04 Apr 2023, Jani Nikula wrote: > > > >> On Mon, 03 Apr 2023, Lee Jones wrote: > >> > On Mon, 03 Apr 2023, Jani Nikula wrote: > >> > > >> >> On Fri, 31 Mar 2023, Lee Jones wrote: > >> >> > Fixes the following W=1 kernel build warning(s): > >> >> > > >> >> > drivers/gpu/drm/i915/i915_scatterlist.c:62: warning: Function > >> >> > parameter or member 'size' not described in 'i915_refct_sgt_init' > >> >> > > >> >> > Cc: Jani Nikula > >> >> > Cc: Joonas Lahtinen > >> >> > Cc: Rodrigo Vivi > >> >> > Cc: Tvrtko Ursulin > >> >> > Cc: David Airlie > >> >> > Cc: Daniel Vetter > >> >> > Cc: intel-gfx@lists.freedesktop.org > >> >> > Cc: dri-de...@lists.freedesktop.org > >> >> > Signed-off-by: Lee Jones > >> >> > >> >> Thanks for the patches! > >> >> > >> >> Applied all but one of the drm/i915 patches to drm-intel-next or > >> >> drm-intel-gt-next depending on the area. There were a couple of issues > >> >> that I fixed while applying. There was a conflict with patch 5/19 > >> >> against drm-intel-gt-next so I left that one out. > >> > > >> > Thanks Jani. I'll rebase and see what's left. > >> > >> We also took notice and aim to track this more aggressively [1]. > > > > Thanks. > > > > I did clean-up all of the GPU warnings already a couple of years ago, > > but they seem to have crept back over time. It would be great if we > > could put some extra checks in place to prevent them in the future. > > We are pretty zealous about warnings in general in i915. We have a bunch > of extra warnings in our local Makefile and use -Werror in > development. Inspired by this series, we added kernel-doc check to the > build, and hope to add kernel-doc -Werror too once we're done. Sounds good that you're on it. At least in your part of GPU. kernel-doc warnings are surfaced by enabling W=1. > > My aim, albeit ambitious, is to clean-up all of the W=1 warnings in the > > kernel, then have them promoted to W=0, so they warn more loudly during > > development, thus keeping them from reappearing. > > I wish it was easier to do the equivalent of W=1 on a driver or Makefile > basis. I like to keep i915 clean, but I don't like to use W=1 because > there are just so many warnings currently. Well that's what I hope to improve (again). :) > The other alternative is fixing and moving extra warnings from W=1 to > W=0 one by one. Right, that's where I'd like to end up eventually. -- Lee Jones [李琼斯]
Re: [Intel-gfx] [PATCH 01/19] drm/i915/i915_scatterlist: Fix kerneldoc formatting issue - missing '@'
On Tue, 04 Apr 2023, Jani Nikula wrote: > On Mon, 03 Apr 2023, Lee Jones wrote: > > On Mon, 03 Apr 2023, Jani Nikula wrote: > > > >> On Fri, 31 Mar 2023, Lee Jones wrote: > >> > Fixes the following W=1 kernel build warning(s): > >> > > >> > drivers/gpu/drm/i915/i915_scatterlist.c:62: warning: Function parameter > >> > or member 'size' not described in 'i915_refct_sgt_init' > >> > > >> > Cc: Jani Nikula > >> > Cc: Joonas Lahtinen > >> > Cc: Rodrigo Vivi > >> > Cc: Tvrtko Ursulin > >> > Cc: David Airlie > >> > Cc: Daniel Vetter > >> > Cc: intel-gfx@lists.freedesktop.org > >> > Cc: dri-de...@lists.freedesktop.org > >> > Signed-off-by: Lee Jones > >> > >> Thanks for the patches! > >> > >> Applied all but one of the drm/i915 patches to drm-intel-next or > >> drm-intel-gt-next depending on the area. There were a couple of issues > >> that I fixed while applying. There was a conflict with patch 5/19 > >> against drm-intel-gt-next so I left that one out. > > > > Thanks Jani. I'll rebase and see what's left. > > We also took notice and aim to track this more aggressively [1]. Thanks. I did clean-up all of the GPU warnings already a couple of years ago, but they seem to have crept back over time. It would be great if we could put some extra checks in place to prevent them in the future. My aim, albeit ambitious, is to clean-up all of the W=1 warnings in the kernel, then have them promoted to W=0, so they warn more loudly during development, thus keeping them from reappearing. -- Lee Jones [李琼斯]
Re: [Intel-gfx] [PATCH 01/19] drm/i915/i915_scatterlist: Fix kerneldoc formatting issue - missing '@'
On Mon, 03 Apr 2023, Jani Nikula wrote: > On Fri, 31 Mar 2023, Lee Jones wrote: > > Fixes the following W=1 kernel build warning(s): > > > > drivers/gpu/drm/i915/i915_scatterlist.c:62: warning: Function parameter or > > member 'size' not described in 'i915_refct_sgt_init' > > > > Cc: Jani Nikula > > Cc: Joonas Lahtinen > > Cc: Rodrigo Vivi > > Cc: Tvrtko Ursulin > > Cc: David Airlie > > Cc: Daniel Vetter > > Cc: intel-gfx@lists.freedesktop.org > > Cc: dri-de...@lists.freedesktop.org > > Signed-off-by: Lee Jones > > Thanks for the patches! > > Applied all but one of the drm/i915 patches to drm-intel-next or > drm-intel-gt-next depending on the area. There were a couple of issues > that I fixed while applying. There was a conflict with patch 5/19 > against drm-intel-gt-next so I left that one out. Thanks Jani. I'll rebase and see what's left. -- Lee Jones [李琼斯]
[Intel-gfx] [PATCH 07/19] drm/i915/gem/i915_gem_create: Provide the function names for proper kerneldoc headers
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/i915/gem/i915_gem_create.c:147: warning: This comment starts
with '/**', but isn't a kernel-doc comment. Refer
Documentation/doc-guide/kernel-doc.rst
drivers/gpu/drm/i915/gem/i915_gem_create.c:218: warning: This comment starts
with '/**', but isn't a kernel-doc comment. Refer
Documentation/doc-guide/kernel-doc.rst
drivers/gpu/drm/i915/gem/i915_gem_create.c:402: warning: This comment starts
with '/**', but isn't a kernel-doc comment. Refer
Documentation/doc-guide/kernel-doc.rst
Cc: Jani Nikula
Cc: Joonas Lahtinen
Cc: Rodrigo Vivi
Cc: Tvrtko Ursulin
Cc: David Airlie
Cc: Daniel Vetter
Cc: Matthew Auld
Cc: intel-gfx@lists.freedesktop.org
Cc: dri-de...@lists.freedesktop.org
Signed-off-by: Lee Jones
---
drivers/gpu/drm/i915/gem/i915_gem_create.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_create.c
b/drivers/gpu/drm/i915/gem/i915_gem_create.c
index e76c9703680ef..4270575f88908 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_create.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_create.c
@@ -144,7 +144,8 @@ __i915_gem_object_create_user_ext(struct drm_i915_private
*i915, u64 size,
}
/**
- * Creates a new object using the same path as DRM_I915_GEM_CREATE_EXT
+ * __i915_gem_object_create_user - Creates a new object using the same path as
+ * DRM_I915_GEM_CREATE_EXT
* @i915: i915 private
* @size: size of the buffer, in bytes
* @placements: possible placement regions, in priority order
@@ -215,7 +216,7 @@ i915_gem_dumb_create(struct drm_file *file,
}
/**
- * Creates a new mm object and returns a handle to it.
+ * i915_gem_create_ioctl - Creates a new mm object and returns a handle to it.
* @dev: drm device pointer
* @data: ioctl data blob
* @file: drm file pointer
@@ -399,7 +400,7 @@ static const i915_user_extension_fn create_extensions[] = {
};
/**
- * Creates a new mm object and returns a handle to it.
+ * i915_gem_create_ext_ioct - Creates a new mm object and returns a handle to
it.
* @dev: drm device pointer
* @data: ioctl data blob
* @file: drm file pointer
--
2.40.0.348.gf938b09366-goog
[Intel-gfx] [PATCH 12/19] drm/i915/gem/i915_gem_wait: Provide function name to validate the kerneldoc header
Fixes the following W=1 kernel build warning(s): drivers/gpu/drm/i915/gem/i915_gem_wait.c:164: warning: This comment starts with '/**', but isn't a kernel-doc comment. Refer Documentation/doc-guide/kernel-doc.rst Cc: Jani Nikula Cc: Joonas Lahtinen Cc: Rodrigo Vivi Cc: Tvrtko Ursulin Cc: David Airlie Cc: Daniel Vetter Cc: Sumit Semwal Cc: "Christian König" Cc: Chris Wilson Cc: intel-gfx@lists.freedesktop.org Cc: dri-de...@lists.freedesktop.org Cc: linux-me...@vger.kernel.org Cc: linaro-mm-...@lists.linaro.org Signed-off-by: Lee Jones --- drivers/gpu/drm/i915/gem/i915_gem_wait.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/gem/i915_gem_wait.c b/drivers/gpu/drm/i915/gem/i915_gem_wait.c index e6e01c2a74a65..4a33ad2d122bd 100644 --- a/drivers/gpu/drm/i915/gem/i915_gem_wait.c +++ b/drivers/gpu/drm/i915/gem/i915_gem_wait.c @@ -161,7 +161,7 @@ i915_gem_object_wait_priority(struct drm_i915_gem_object *obj, } /** - * Waits for rendering to the object to be completed + * i915_gem_object_wait - Waits for rendering to the object to be completed * @obj: i915 gem object * @flags: how to wait (under a lock, for all rendering or just for writes etc) * @timeout: how long to wait -- 2.40.0.348.gf938b09366-goog
[Intel-gfx] [PATCH 02/19] drm/i915/intel_region_ttm: Provide missing description for 'offset' param
Fixes the following W=1 kernel build warning(s): drivers/gpu/drm/i915/intel_region_ttm.c:201: warning: Function parameter or member 'offset' not described in 'intel_region_ttm_resource_alloc' Cc: Jani Nikula Cc: Joonas Lahtinen Cc: Rodrigo Vivi Cc: Tvrtko Ursulin Cc: David Airlie Cc: Daniel Vetter Cc: intel-gfx@lists.freedesktop.org Cc: dri-de...@lists.freedesktop.org Signed-off-by: Lee Jones --- drivers/gpu/drm/i915/intel_region_ttm.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/i915/intel_region_ttm.c b/drivers/gpu/drm/i915/intel_region_ttm.c index b7fbd5abb42a5..bf6097e7433d5 100644 --- a/drivers/gpu/drm/i915/intel_region_ttm.c +++ b/drivers/gpu/drm/i915/intel_region_ttm.c @@ -181,6 +181,7 @@ intel_region_ttm_resource_to_rsgt(struct intel_memory_region *mem, /** * intel_region_ttm_resource_alloc - Allocate memory resources from a region * @mem: The memory region, + * @offset: BO offset * @size: The requested size in bytes * @flags: Allocation flags * -- 2.40.0.348.gf938b09366-goog
[Intel-gfx] [PATCH 06/19] drm/i915/gt/intel_rps: Demote a kerneldoc abuse for ips_ping_for_i915_load()
Fixes the following W=1 kernel build warning(s): drivers/gpu/drm/i915/gt/intel_rps.c:2646: warning: This comment starts with '/**', but isn't a kernel-doc comment. Refer Documentation/doc-guide/kernel-doc.rst Cc: Jani Nikula Cc: Joonas Lahtinen Cc: Rodrigo Vivi Cc: Tvrtko Ursulin Cc: David Airlie Cc: Daniel Vetter Cc: intel-gfx@lists.freedesktop.org Cc: dri-de...@lists.freedesktop.org Signed-off-by: Lee Jones --- drivers/gpu/drm/i915/gt/intel_rps.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/gt/intel_rps.c b/drivers/gpu/drm/i915/gt/intel_rps.c index e97c52c90689a..301359b500a3e 100644 --- a/drivers/gpu/drm/i915/gt/intel_rps.c +++ b/drivers/gpu/drm/i915/gt/intel_rps.c @@ -2646,7 +2646,7 @@ bool rps_read_mask_mmio(struct intel_rps *rps, static struct drm_i915_private __rcu *ips_mchdev; -/** +/* * Tells the intel_ips driver that the i915 driver is now loaded, if * IPS got loaded first. * -- 2.40.0.348.gf938b09366-goog
[Intel-gfx] [PATCH 19/19] drm/i915/display/intel_wm: Fix a little doc-rot in intel_update_watermarks()
Fixes the following W=1 kernel build warning(s): drivers/gpu/drm/i915/display/intel_wm.c:46: warning: Function parameter or member 'i915' not described in 'intel_update_watermarks' drivers/gpu/drm/i915/display/intel_wm.c:46: warning: Excess function parameter 'dev_priv' description in 'intel_update_watermarks' Cc: Jani Nikula Cc: Joonas Lahtinen Cc: Rodrigo Vivi Cc: Tvrtko Ursulin Cc: David Airlie Cc: Daniel Vetter Cc: "Ville Syrjälä" Cc: intel-gfx@lists.freedesktop.org Cc: dri-de...@lists.freedesktop.org Signed-off-by: Lee Jones --- drivers/gpu/drm/i915/display/intel_wm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/display/intel_wm.c b/drivers/gpu/drm/i915/display/intel_wm.c index bb99179cd5fd1..b615449e70b47 100644 --- a/drivers/gpu/drm/i915/display/intel_wm.c +++ b/drivers/gpu/drm/i915/display/intel_wm.c @@ -11,7 +11,7 @@ /** * intel_update_watermarks - update FIFO watermark values based on current modes - * @dev_priv: i915 device + * @i915: i915 device * * Calculate watermark values for the various WM regs based on current mode * and plane configuration. -- 2.40.0.348.gf938b09366-goog
[Intel-gfx] [PATCH 17/19] drm/i915/display/intel_display_power: Fix incorrectly documented function __intel_display_power_put_async()
Fixes the following W=1 kernel build warning(s): drivers/gpu/drm/i915/display/intel_display_power.c:712: warning: expecting prototype for intel_display_power_put_async(). Prototype was for __intel_display_power_put_async() instead Cc: Jani Nikula Cc: Joonas Lahtinen Cc: Rodrigo Vivi Cc: Tvrtko Ursulin Cc: David Airlie Cc: Daniel Vetter Cc: Imre Deak Cc: intel-gfx@lists.freedesktop.org Cc: dri-de...@lists.freedesktop.org Signed-off-by: Lee Jones --- drivers/gpu/drm/i915/display/intel_display_power.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/display/intel_display_power.c b/drivers/gpu/drm/i915/display/intel_display_power.c index f86060195987c..7d1e492b6bfb5 100644 --- a/drivers/gpu/drm/i915/display/intel_display_power.c +++ b/drivers/gpu/drm/i915/display/intel_display_power.c @@ -697,7 +697,7 @@ intel_display_power_put_async_work(struct work_struct *work) } /** - * intel_display_power_put_async - release a power domain reference asynchronously + * __intel_display_power_put_async - release a power domain reference asynchronously * @i915: i915 device instance * @domain: power domain to reference * @wakeref: wakeref acquired for the reference that is being released -- 2.40.0.348.gf938b09366-goog
[Intel-gfx] [PATCH 01/19] drm/i915/i915_scatterlist: Fix kerneldoc formatting issue - missing '@'
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/i915/i915_scatterlist.c:62: warning: Function parameter or
member 'size' not described in 'i915_refct_sgt_init'
Cc: Jani Nikula
Cc: Joonas Lahtinen
Cc: Rodrigo Vivi
Cc: Tvrtko Ursulin
Cc: David Airlie
Cc: Daniel Vetter
Cc: intel-gfx@lists.freedesktop.org
Cc: dri-de...@lists.freedesktop.org
Signed-off-by: Lee Jones
---
drivers/gpu/drm/i915/i915_scatterlist.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_scatterlist.c
b/drivers/gpu/drm/i915/i915_scatterlist.c
index 7c7a86921b1c7..e93d2538f2988 100644
--- a/drivers/gpu/drm/i915/i915_scatterlist.c
+++ b/drivers/gpu/drm/i915/i915_scatterlist.c
@@ -56,7 +56,7 @@ static const struct i915_refct_sgt_ops rsgt_ops = {
/**
* i915_refct_sgt_init - Initialize a struct i915_refct_sgt with default ops
* @rsgt: The struct i915_refct_sgt to initialize.
- * size: The size of the underlying memory buffer.
+ * @size: The size of the underlying memory buffer.
*/
void i915_refct_sgt_init(struct i915_refct_sgt *rsgt, size_t size)
{
--
2.40.0.348.gf938b09366-goog
[Intel-gfx] [PATCH 14/19] drm/i915/i915_gem: Provide function names to complete the expected kerneldoc format
Fixes the following W=1 kernel build warning(s): drivers/gpu/drm/i915/i915_gem.c:447: warning: This comment starts with '/**', but isn't a kernel-doc comment. Refer Documentation/doc-guide/kernel-doc.rst drivers/gpu/drm/i915/i915_gem.c:536: warning: This comment starts with '/**', but isn't a kernel-doc comment. Refer Documentation/doc-guide/kernel-doc.rst drivers/gpu/drm/i915/i915_gem.c:726: warning: This comment starts with '/**', but isn't a kernel-doc comment. Refer Documentation/doc-guide/kernel-doc.rst drivers/gpu/drm/i915/i915_gem.c:811: warning: This comment starts with '/**', but isn't a kernel-doc comment. Refer Documentation/doc-guide/kernel-doc.rst Cc: Jani Nikula Cc: Joonas Lahtinen Cc: Rodrigo Vivi Cc: Tvrtko Ursulin Cc: David Airlie Cc: Daniel Vetter Cc: Eric Anholt Cc: intel-gfx@lists.freedesktop.org Cc: dri-de...@lists.freedesktop.org Signed-off-by: Lee Jones --- drivers/gpu/drm/i915/i915_gem.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c index 35950fa914068..6a00d13db2893 100644 --- a/drivers/gpu/drm/i915/i915_gem.c +++ b/drivers/gpu/drm/i915/i915_gem.c @@ -444,7 +444,7 @@ i915_gem_gtt_pread(struct drm_i915_gem_object *obj, } /** - * Reads data from the object referenced by handle. + * i915_gem_pread_ioctl - Reads data from the object referenced by handle. * @dev: drm device pointer * @data: ioctl data blob * @file: drm file pointer @@ -533,7 +533,7 @@ ggtt_write(struct io_mapping *mapping, } /** - * This is the fast pwrite path, where we copy the data directly from the + * i915_gem_gtt_pwrite_fast - This is the fast pwrite path, where we copy the data directly from the * user into the GTT, uncached. * @obj: i915 GEM object * @args: pwrite arguments structure @@ -723,7 +723,7 @@ i915_gem_shmem_pwrite(struct drm_i915_gem_object *obj, } /** - * Writes data to the object referenced by handle. + * i915_gem_pwrite_ioctl - Writes data to the object referenced by handle. * @dev: drm device * @data: ioctl data blob * @file: drm file @@ -808,7 +808,7 @@ i915_gem_pwrite_ioctl(struct drm_device *dev, void *data, } /** - * Called when user space has done writes to this buffer + * i915_gem_sw_finish_ioct - Called when user space has done writes to this buffer * @dev: drm device * @data: ioctl data blob * @file: drm file -- 2.40.0.348.gf938b09366-goog
[Intel-gfx] [PATCH 08/19] drm/i915/gem/i915_gem_domain: Provide function names to complete proper kerneldoc
Fixes the following W=1 kernel build warning(s): drivers/gpu/drm/i915/gem/i915_gem_domain.c:119: warning: This comment starts with '/**', but isn't a kernel-doc comment. Refer Documentation/doc-guide/kernel-doc.rst drivers/gpu/drm/i915/gem/i915_gem_domain.c:180: warning: This comment starts with '/**', but isn't a kernel-doc comment. Refer Documentation/doc-guide/kernel-doc.rst drivers/gpu/drm/i915/gem/i915_gem_domain.c:265: warning: expecting prototype for Changes the cache(). Prototype was for i915_gem_object_set_cache_level() instead drivers/gpu/drm/i915/gem/i915_gem_domain.c:470: warning: This comment starts with '/**', but isn't a kernel-doc comment. Refer Documentation/doc-guide/kernel-doc.rst drivers/gpu/drm/i915/gem/i915_gem_domain.c:514: warning: This comment starts with '/**', but isn't a kernel-doc comment. Refer Documentation/doc-guide/kernel-doc.rst Cc: Jani Nikula Cc: Joonas Lahtinen Cc: Rodrigo Vivi Cc: Tvrtko Ursulin Cc: David Airlie Cc: Daniel Vetter Cc: intel-gfx@lists.freedesktop.org Cc: dri-de...@lists.freedesktop.org Signed-off-by: Lee Jones --- drivers/gpu/drm/i915/gem/i915_gem_domain.c | 14 +- 1 file changed, 9 insertions(+), 5 deletions(-) diff --git a/drivers/gpu/drm/i915/gem/i915_gem_domain.c b/drivers/gpu/drm/i915/gem/i915_gem_domain.c index 497de40b8e688..d2d5a24301b25 100644 --- a/drivers/gpu/drm/i915/gem/i915_gem_domain.c +++ b/drivers/gpu/drm/i915/gem/i915_gem_domain.c @@ -116,7 +116,8 @@ void i915_gem_object_flush_if_display_locked(struct drm_i915_gem_object *obj) } /** - * Moves a single object to the WC read, and possibly write domain. + * i915_gem_object_set_to_wc_domain - Moves a single object to the WC read, and + *possibly write domain. * @obj: object to act on * @write: ask for write access or read only * @@ -177,7 +178,8 @@ i915_gem_object_set_to_wc_domain(struct drm_i915_gem_object *obj, bool write) } /** - * Moves a single object to the GTT read, and possibly write domain. + * i915_gem_object_set_to_gtt_domain - Moves a single object to the GTT read, + * and possibly write domain. * @obj: object to act on * @write: ask for write access or read only * @@ -246,7 +248,7 @@ i915_gem_object_set_to_gtt_domain(struct drm_i915_gem_object *obj, bool write) } /** - * Changes the cache-level of an object across all VMA. + * i915_gem_object_set_cache_level - Changes the cache-level of an object across all VMA. * @obj: object to act on * @cache_level: new cache level to set for the object * @@ -467,7 +469,8 @@ i915_gem_object_pin_to_display_plane(struct drm_i915_gem_object *obj, } /** - * Moves a single object to the CPU read, and possibly write domain. + * i915_gem_object_set_to_cpu_domain - Moves a single object to the CPU read, + * and possibly write domain. * @obj: object to act on * @write: requesting write or read-only access * @@ -511,7 +514,8 @@ i915_gem_object_set_to_cpu_domain(struct drm_i915_gem_object *obj, bool write) } /** - * Called when user space prepares to use an object with the CPU, either + * i915_gem_set_domain_ioctl - Called when user space prepares to use an + * object with the CPU, either * through the mmap ioctl's mapping or a GTT mapping. * @dev: drm device * @data: ioctl data blob -- 2.40.0.348.gf938b09366-goog
[Intel-gfx] [PATCH 05/19] drm/i915/gt/intel_engine_cs: Fix a couple of incorrectly named functions
Fixes the following W=1 kernel build warning(s): drivers/gpu/drm/i915/gt/intel_engine_cs.c:1324: warning: expecting prototype for intel_engines_init_common(). Prototype was for engine_init_common() instead drivers/gpu/drm/i915/gt/intel_engine_cs.c:1406: warning: expecting prototype for intel_engines_cleanup_common(). Prototype was for intel_engine_cleanup_common() instead Cc: Jani Nikula Cc: Joonas Lahtinen Cc: Rodrigo Vivi Cc: Tvrtko Ursulin Cc: David Airlie Cc: Daniel Vetter Cc: intel-gfx@lists.freedesktop.org Cc: dri-de...@lists.freedesktop.org Signed-off-by: Lee Jones --- drivers/gpu/drm/i915/gt/intel_engine_cs.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c b/drivers/gpu/drm/i915/gt/intel_engine_cs.c index 2966aed422239..03c5e3df0a7e0 100644 --- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c +++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c @@ -1429,7 +1429,7 @@ create_kernel_context(struct intel_engine_cs *engine) } /** - * intel_engines_init_common - initialize cengine state which might require hw access + * engine_init_common - initialize cengine state which might require hw access * @engine: Engine to initialize. * * Initializes @engine@ structure members shared between legacy and execlists @@ -1515,8 +1515,8 @@ int intel_engines_init(struct intel_gt *gt) } /** - * intel_engines_cleanup_common - cleans up the engine state created by - *the common initiailizers. + * intel_engine_cleanup_common - cleans up the engine state created by + * the common initiailizers. * @engine: Engine to cleanup. * * This cleans up everything created by the common helpers. -- 2.40.0.348.gf938b09366-goog
[Intel-gfx] [PATCH 11/19] drm/i915/gem/i915_gem_ttm_move: Provide a couple of missing descriptions for 'num_pages' and 'ctx'
Fixes the following W=1 kernel build warning(s): drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c:272: warning: Function parameter or member 'num_pages' not described in 'i915_ttm_memcpy_arg' drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c:569: warning: Function parameter or member 'ctx' not described in 'i915_ttm_move' Cc: Jani Nikula Cc: Joonas Lahtinen Cc: Rodrigo Vivi Cc: Tvrtko Ursulin Cc: David Airlie Cc: Daniel Vetter Cc: Sumit Semwal Cc: "Christian König" Cc: intel-gfx@lists.freedesktop.org Cc: dri-de...@lists.freedesktop.org Cc: linux-me...@vger.kernel.org Cc: linaro-mm-...@lists.linaro.org Signed-off-by: Lee Jones --- drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c b/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c index d030182ca1764..dd188dfcc423e 100644 --- a/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c +++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c @@ -253,6 +253,7 @@ static struct dma_fence *i915_ttm_accel_move(struct ttm_buffer_object *bo, * @_src_iter: Storage space for the source kmap iterator. * @dst_iter: Pointer to the destination kmap iterator. * @src_iter: Pointer to the source kmap iterator. + * @num_pages: Number of pages * @clear: Whether to clear instead of copy. * @src_rsgt: Refcounted scatter-gather list of source memory. * @dst_rsgt: Refcounted scatter-gather list of destination memory. @@ -557,6 +558,8 @@ __i915_ttm_move(struct ttm_buffer_object *bo, * i915_ttm_move - The TTM move callback used by i915. * @bo: The buffer object. * @evict: Whether this is an eviction. + * @ctx: Pointer to a struct ttm_operation_ctx indicating how the waits should be + * performed if waiting * @dst_mem: The destination ttm resource. * @hop: If we need multihop, what temporary memory type to move to. * -- 2.40.0.348.gf938b09366-goog
[Intel-gfx] [PATCH 13/19] drm/i915/gem/i915_gem_object: Demote non-kerneldoc header with no param descriptions
Fixes the following W=1 kernel build warning(s): drivers/gpu/drm/i915/gem/i915_gem_object.c:887: warning: Function parameter or member 'obj' not described in 'i915_gem_object_has_unknown_state' Cc: Jani Nikula Cc: Joonas Lahtinen Cc: Rodrigo Vivi Cc: Tvrtko Ursulin Cc: David Airlie Cc: Daniel Vetter Cc: Sumit Semwal Cc: "Christian König" Cc: Matthew Auld Cc: Nirmoy Das Cc: intel-gfx@lists.freedesktop.org Cc: dri-de...@lists.freedesktop.org Cc: linux-me...@vger.kernel.org Cc: linaro-mm-...@lists.linaro.org Signed-off-by: Lee Jones --- drivers/gpu/drm/i915/gem/i915_gem_object.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.c b/drivers/gpu/drm/i915/gem/i915_gem_object.c index e6d4efde4fc51..4666bb82f312c 100644 --- a/drivers/gpu/drm/i915/gem/i915_gem_object.c +++ b/drivers/gpu/drm/i915/gem/i915_gem_object.c @@ -875,7 +875,7 @@ int i915_gem_object_wait_moving_fence(struct drm_i915_gem_object *obj, return ret < 0 ? ret : 0; } -/** +/* * i915_gem_object_has_unknown_state - Return true if the object backing pages are * in an unknown_state. This means that userspace must NEVER be allowed to touch * the pages, with either the GPU or CPU. -- 2.40.0.348.gf938b09366-goog
[Intel-gfx] [PATCH 16/19] drm/i915/i915_vma: Provide one missing param and demote another non-kerneldoc header
Fixes the following W=1 kernel build warning(s): drivers/gpu/drm/i915/i915_vma.c:756: warning: Function parameter or member 'ww' not described in 'i915_vma_insert' drivers/gpu/drm/i915/i915_vma.c:1744: warning: Function parameter or member 'vma' not described in 'i915_vma_destroy_locked' Cc: Jani Nikula Cc: Joonas Lahtinen Cc: Rodrigo Vivi Cc: Tvrtko Ursulin Cc: David Airlie Cc: Daniel Vetter Cc: Sumit Semwal Cc: "Christian König" Cc: intel-gfx@lists.freedesktop.org Cc: dri-de...@lists.freedesktop.org Cc: linux-me...@vger.kernel.org Cc: linaro-mm-...@lists.linaro.org Signed-off-by: Lee Jones --- drivers/gpu/drm/i915/i915_vma.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/i915_vma.c b/drivers/gpu/drm/i915/i915_vma.c index f51fd9fd4c89c..20a44788999e5 100644 --- a/drivers/gpu/drm/i915/i915_vma.c +++ b/drivers/gpu/drm/i915/i915_vma.c @@ -739,6 +739,7 @@ bool i915_gem_valid_gtt_space(struct i915_vma *vma, unsigned long color) /** * i915_vma_insert - finds a slot for the vma in its address space * @vma: the vma + * @ww: An optional struct i915_gem_ww_ctx * @size: requested size in bytes (can be larger than the VMA) * @alignment: required alignment * @flags: mask of PIN_* flags to use @@ -1714,7 +1715,7 @@ static void release_references(struct i915_vma *vma, struct intel_gt *gt, i915_vma_free(vma); } -/** +/* * i915_vma_destroy_locked - Remove all weak reference to the vma and put * the initial reference. * -- 2.40.0.348.gf938b09366-goog
[Intel-gfx] [PATCH 04/19] drm/i915/display/intel_display_debugfs: Fix incorrect param naming for 'intel_connector'
Fixes the following W=1 kernel build warning(s): drivers/gpu/drm/i915/display/intel_display_debugfs.c:1668: warning: Function parameter or member 'intel_connector' not described in 'intel_connector_debugfs_add' drivers/gpu/drm/i915/display/intel_display_debugfs.c:1668: warning: Excess function parameter 'connector' description in 'intel_connector_debugfs_add' Cc: Jani Nikula Cc: Joonas Lahtinen Cc: Rodrigo Vivi Cc: Tvrtko Ursulin Cc: David Airlie Cc: Daniel Vetter Cc: intel-gfx@lists.freedesktop.org Cc: dri-de...@lists.freedesktop.org Signed-off-by: Lee Jones --- drivers/gpu/drm/i915/display/intel_display_debugfs.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/display/intel_display_debugfs.c b/drivers/gpu/drm/i915/display/intel_display_debugfs.c index d5715ccc37f0e..195b6cb379ad1 100644 --- a/drivers/gpu/drm/i915/display/intel_display_debugfs.c +++ b/drivers/gpu/drm/i915/display/intel_display_debugfs.c @@ -1395,7 +1395,7 @@ DEFINE_SHOW_ATTRIBUTE(intel_crtc_pipe); /** * intel_connector_debugfs_add - add i915 specific connector debugfs files - * @connector: pointer to a registered drm_connector + * @intel_connector: pointer to a registered drm_connector * * Cleanup will be done by drm_connector_unregister() through a call to * drm_debugfs_connector_remove(). -- 2.40.0.348.gf938b09366-goog
[Intel-gfx] [PATCH 10/19] drm/i915/gem/i915_gem_ttm: Demote half-filled kerneldoc
Hopefully someone knowledgable will follow-up to complete it. Fixes the following W=1 kernel build warning(s): drivers/gpu/drm/i915/gem/i915_gem_ttm.c:1292: warning: Function parameter or member 'offset' not described in '__i915_gem_ttm_object_init' drivers/gpu/drm/i915/gem/i915_gem_ttm.c:1292: warning: Function parameter or member 'page_size' not described in '__i915_gem_ttm_object_init' Cc: Jani Nikula Cc: Joonas Lahtinen Cc: Rodrigo Vivi Cc: Tvrtko Ursulin Cc: David Airlie Cc: Daniel Vetter Cc: Sumit Semwal Cc: "Christian König" Cc: Matthew Auld Cc: intel-gfx@lists.freedesktop.org Cc: dri-de...@lists.freedesktop.org Cc: linux-me...@vger.kernel.org Cc: linaro-mm-...@lists.linaro.org Signed-off-by: Lee Jones --- drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c index 341b94672abcb..9227f8146a583 100644 --- a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c +++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c @@ -1274,7 +1274,7 @@ void i915_ttm_bo_destroy(struct ttm_buffer_object *bo) } } -/** +/* * __i915_gem_ttm_object_init - Initialize a ttm-backed i915 gem object * @mem: The initial memory region for the object. * @obj: The gem object. -- 2.40.0.348.gf938b09366-goog
[Intel-gfx] [PATCH 09/19] drm/i915/gem/i915_gem_ttm_pm: Provide a couple of missing descriptions for 'flags' and remove some superfluous ones
Fixes the following W=1 kernel build warning(s): drivers/gpu/drm/i915/gem/i915_gem_ttm_pm.c:156: warning: Function parameter or member 'flags' not described in 'i915_ttm_backup_region' drivers/gpu/drm/i915/gem/i915_gem_ttm_pm.c:156: warning: Excess function parameter 'allow_gpu' description in 'i915_ttm_backup_region' drivers/gpu/drm/i915/gem/i915_gem_ttm_pm.c:156: warning: Excess function parameter 'backup_pinned' description in 'i915_ttm_backup_region' drivers/gpu/drm/i915/gem/i915_gem_ttm_pm.c:223: warning: Function parameter or member 'flags' not described in 'i915_ttm_restore_region' drivers/gpu/drm/i915/gem/i915_gem_ttm_pm.c:223: warning: Excess function parameter 'allow_gpu' description in 'i915_ttm_restore_region' Cc: Jani Nikula Cc: Joonas Lahtinen Cc: Rodrigo Vivi Cc: Tvrtko Ursulin Cc: David Airlie Cc: Daniel Vetter Cc: Matthew Auld Cc: Nirmoy Das Cc: intel-gfx@lists.freedesktop.org Cc: dri-de...@lists.freedesktop.org Signed-off-by: Lee Jones --- drivers/gpu/drm/i915/gem/i915_gem_ttm_pm.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm_pm.c b/drivers/gpu/drm/i915/gem/i915_gem_ttm_pm.c index dfe39c8e74d8a..ad649523d5e0b 100644 --- a/drivers/gpu/drm/i915/gem/i915_gem_ttm_pm.c +++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm_pm.c @@ -144,8 +144,7 @@ void i915_ttm_recover_region(struct intel_memory_region *mr) /** * i915_ttm_backup_region - Back up all objects of a region to smem. * @mr: The memory region - * @allow_gpu: Whether to allow the gpu blitter for this backup. - * @backup_pinned: Backup also pinned objects. + * @flags: TTM backup flags * * Loops over all objects of a region and either evicts them if they are * evictable or backs them up using a backup object if they are pinned. @@ -212,7 +211,7 @@ static int i915_ttm_restore(struct i915_gem_apply_to_region *apply, /** * i915_ttm_restore_region - Restore backed-up objects of a region from smem. * @mr: The memory region - * @allow_gpu: Whether to allow the gpu blitter to recover. + * @flags: TTM backup flags * * Loops over all objects of a region and if they are backed-up, restores * them from smem. -- 2.40.0.348.gf938b09366-goog
[Intel-gfx] [PATCH 15/19] drm/i915/gt/uc/intel_guc_hwconfig: Demote a few non-conforming kerneldoc headers
Fixes the following W=1 kernel build warning(s): drivers/gpu/drm/i915/gt/uc/intel_guc_hwconfig.c:112: warning: Function parameter or member 'gt' not described in 'guc_hwconfig_init' drivers/gpu/drm/i915/gt/uc/intel_guc_hwconfig.c:112: warning: expecting prototype for intel_guc_hwconfig_init(). Prototype was for guc_hwconfig_init() instead drivers/gpu/drm/i915/gt/uc/intel_guc_hwconfig.c:145: warning: Function parameter or member 'gt' not described in 'intel_gt_init_hwconfig' drivers/gpu/drm/i915/gt/uc/intel_guc_hwconfig.c:158: warning: Function parameter or member 'gt' not described in 'intel_gt_fini_hwconfig' Cc: Jani Nikula Cc: Joonas Lahtinen Cc: Rodrigo Vivi Cc: Tvrtko Ursulin Cc: David Airlie Cc: Daniel Vetter Cc: John Harrison Cc: Matt Roper Cc: intel-gfx@lists.freedesktop.org Cc: dri-de...@lists.freedesktop.org Signed-off-by: Lee Jones --- drivers/gpu/drm/i915/gt/uc/intel_guc_hwconfig.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_hwconfig.c b/drivers/gpu/drm/i915/gt/uc/intel_guc_hwconfig.c index 4781fccc2687d..852bea0208ce4 100644 --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_hwconfig.c +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_hwconfig.c @@ -102,7 +102,7 @@ static bool has_table(struct drm_i915_private *i915) return false; } -/** +/* * intel_guc_hwconfig_init - Initialize the HWConfig * * Retrieve the HWConfig table from the GuC and save it locally. @@ -136,7 +136,7 @@ static int guc_hwconfig_init(struct intel_gt *gt) return 0; } -/** +/* * intel_gt_init_hwconfig - Initialize the HWConfig if available * * Retrieve the HWConfig table if available on the current platform. @@ -149,7 +149,7 @@ int intel_gt_init_hwconfig(struct intel_gt *gt) return guc_hwconfig_init(gt); } -/** +/* * intel_gt_fini_hwconfig - Finalize the HWConfig * * Free up the memory allocation holding the table. -- 2.40.0.348.gf938b09366-goog
Re: [Intel-gfx] [PATCH 00/29] [Set 15] Finally rid W=1 warnings from GPU!
On Tue, 19 Jan 2021, Zack Rusin wrote: > > > > On Jan 19, 2021, at 03:29, Lee Jones wrote: > > > > On Mon, 18 Jan 2021, Daniel Vetter wrote: > > > >> On Mon, Jan 18, 2021 at 03:09:45PM +, Lee Jones wrote: > >>> On Mon, 18 Jan 2021, Daniel Vetter wrote: > >>> > >>>> On Fri, Jan 15, 2021 at 06:27:15PM +, Zack Rusin wrote: > >>>>> > >>>>>> On Jan 15, 2021, at 13:15, Lee Jones wrote: > >>>>>> > >>>>>> This set is part of a larger effort attempting to clean-up W=1 > >>>>>> kernel builds, which are currently overwhelmingly riddled with > >>>>>> niggly little warnings. > >>>>>> > >>>>>> Last set! All clean after this for; Arm, Arm64, PPC, MIPS and x86. > >>>>> > >>>>> Thanks! For all the vmwgfx bits: > >>>>> Reviewed-by: Zack Rusin > >>>> > >>>> Ok I merged everything except vmwgfx (that's for Zack) and i915/nouveau > >>>> (those generally go through other trees, pls holler if they're stuck). > >>> > >>> Thanks Daniel, you're a superstar! > >>> > >>> So Zack will take the vmwgfx parts? Despite providing a R-b? > >> > >> I only merge stuff that's defacto abandoned already. Everything else I try > >> to offload to whomever actually cares :-) > > > > Understood. Thanks for the explanation. > > > > Hopefully Zack actually cares. :D > > hah, I do. I just pushed all of the changes to drm-misc-next. Let me > know if I missed anything. Thanks! Perfect. Thank you Zack. -- Lee Jones [李琼斯] Senior Technical Lead - Developer Services Linaro.org │ Open source software for Arm SoCs Follow Linaro: Facebook | Twitter | Blog ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 00/29] [Set 15] Finally rid W=1 warnings from GPU!
On Mon, 18 Jan 2021, Daniel Vetter wrote: > On Mon, Jan 18, 2021 at 03:09:45PM +0000, Lee Jones wrote: > > On Mon, 18 Jan 2021, Daniel Vetter wrote: > > > > > On Fri, Jan 15, 2021 at 06:27:15PM +, Zack Rusin wrote: > > > > > > > > > On Jan 15, 2021, at 13:15, Lee Jones wrote: > > > > > > > > > > This set is part of a larger effort attempting to clean-up W=1 > > > > > kernel builds, which are currently overwhelmingly riddled with > > > > > niggly little warnings. > > > > > > > > > > Last set! All clean after this for; Arm, Arm64, PPC, MIPS and x86. > > > > > > > > Thanks! For all the vmwgfx bits: > > > > Reviewed-by: Zack Rusin > > > > > > Ok I merged everything except vmwgfx (that's for Zack) and i915/nouveau > > > (those generally go through other trees, pls holler if they're stuck). > > > > Thanks Daniel, you're a superstar! > > > > So Zack will take the vmwgfx parts? Despite providing a R-b? > > I only merge stuff that's defacto abandoned already. Everything else I try > to offload to whomever actually cares :-) Understood. Thanks for the explanation. Hopefully Zack actually cares. :D -- Lee Jones [李琼斯] Senior Technical Lead - Developer Services Linaro.org │ Open source software for Arm SoCs Follow Linaro: Facebook | Twitter | Blog ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 00/29] [Set 15] Finally rid W=1 warnings from GPU!
On Mon, 18 Jan 2021, Daniel Vetter wrote: > On Fri, Jan 15, 2021 at 06:27:15PM +, Zack Rusin wrote: > > > > > On Jan 15, 2021, at 13:15, Lee Jones wrote: > > > > > > This set is part of a larger effort attempting to clean-up W=1 > > > kernel builds, which are currently overwhelmingly riddled with > > > niggly little warnings. > > > > > > Last set! All clean after this for; Arm, Arm64, PPC, MIPS and x86. > > > > Thanks! For all the vmwgfx bits: > > Reviewed-by: Zack Rusin > > Ok I merged everything except vmwgfx (that's for Zack) and i915/nouveau > (those generally go through other trees, pls holler if they're stuck). Thanks Daniel, you're a superstar! So Zack will take the vmwgfx parts? Despite providing a R-b? > Note that we have some build issue on some of the configs sfr uses, so drm > trees are still stuck on old versions in linux-next. Hopefully should get > resolved soon, the bugfix is in some subtree I've heard. No worries. Thanks for letting me know. -- Lee Jones [李琼斯] Senior Technical Lead - Developer Services Linaro.org │ Open source software for Arm SoCs Follow Linaro: Facebook | Twitter | Blog ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 24/29] drm/i915/gvt/handlers: Remove kernel-doc formatting from non-kernel-doc header
Fixes the following W=1 kernel build warning(s): drivers/gpu/drm/i915/gvt/handlers.c:1666: warning: Function parameter or member 'vgpu' not described in 'bxt_ppat_low_write' drivers/gpu/drm/i915/gvt/handlers.c:1666: warning: Function parameter or member 'offset' not described in 'bxt_ppat_low_write' drivers/gpu/drm/i915/gvt/handlers.c:1666: warning: Function parameter or member 'p_data' not described in 'bxt_ppat_low_write' drivers/gpu/drm/i915/gvt/handlers.c:1666: warning: Function parameter or member 'bytes' not described in 'bxt_ppat_low_write' Cc: Zhenyu Wang Cc: Zhi Wang Cc: Jani Nikula Cc: Joonas Lahtinen Cc: Rodrigo Vivi Cc: David Airlie Cc: Daniel Vetter Cc: Kevin Tian Cc: Eddie Dong Cc: Zhiyuan Lv Cc: Min He Cc: Tina Zhang Cc: Pei Zhang Cc: Niu Bing Cc: Ping Gao Cc: intel-gvt-...@lists.freedesktop.org Cc: intel-gfx@lists.freedesktop.org Cc: dri-de...@lists.freedesktop.org Signed-off-by: Lee Jones --- drivers/gpu/drm/i915/gvt/handlers.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/gvt/handlers.c b/drivers/gpu/drm/i915/gvt/handlers.c index eaba80975f42a..0d124ced5f940 100644 --- a/drivers/gpu/drm/i915/gvt/handlers.c +++ b/drivers/gpu/drm/i915/gvt/handlers.c @@ -1651,7 +1651,7 @@ static int edp_psr_imr_iir_write(struct intel_vgpu *vgpu, return 0; } -/** +/* * FixMe: * If guest fills non-priv batch buffer on ApolloLake/Broxton as Mesa i965 did: * 717e7539124d (i965: Use a WC map and memcpy for the batch instead of pwrite.) -- 2.25.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 00/29] [Set 15] Finally rid W=1 warnings from GPU!
This set is part of a larger effort attempting to clean-up W=1 kernel builds, which are currently overwhelmingly riddled with niggly little warnings. Last set! All clean after this for; Arm, Arm64, PPC, MIPS and x86. Lee Jones (29): drm/vmwgfx/vmwgfx_cmdbuf: Fix misnaming of 'headers' should be plural drm/vmwgfx/vmwgfx_cotable: Fix a couple of simple documentation problems drm/vmwgfx/vmwgfx_so: Add description for 'vmw_view's 'rcu' member drm/vmwgfx/vmwgfx_binding: Provide some missing param descriptions and remove others drm/vmwgfx/vmwgfx_msg: Fix misspelling of 'msg' drm/gma500/mmu: Actually return an error if one occurs drm/vmwgfx/vmwgfx_blit: Add description for 'vmw_bo_cpu_blit's 'diff' param drm/vmwgfx/vmwgfx_validation: Add some missing struct member/function param descriptions drm/vmwgfx/ttm_object: Demote half-assed headers and fix-up another drm/vmwgfx/vmwgfx_thp: Add description for 'vmw_thp_manager's member 'manager' drm/gma500/psb_intel_sdvo: Demote kernel-doc abuses drm/gma500/psb_irq: Demote kernel-doc abuse drm/drm_dp_helper: Fix spelling issue and add missing description for 'enable_frl_ready_hpd' drm/gma500/cdv_intel_crt: Demote kernel-doc abuse in 'cdv_intel_crt_detect_hotplug()'s header drm/gma500/cdv_intel_display: Demote kernel-doc abuse in 'cdv_intel_panel_fitter_pipe()'s header drm/gma500/cdv_intel_lvds: Demote unworthy headers to standard blocks and fix another drm/gma500/cdv_intel_dp: Demote one unworthy header fix another drm/gma500/oaktrail_lvds_i2c: Remove unused variables 'tmp' drm/gma500/oaktrail_lvds: Demote one documentation header fix another drm/gma500/oaktrail_crtc: Demote unworthy kernel-doc headers drm/gma500/mdfld_dsi_output: Demote a couple of kernel-doc formatting abuses drm/gma500/mdfld_intel_display: Demote three kernel-doc formatting abuses drm/drm_agpsupport: Strip out obviously wrong descriptions and demote to standard headers drm/i915/gvt/handlers: Remove kernel-doc formatting from non-kernel-doc header drm/nouveau/nouveau_ioc32: File headers are not good candidates for kernel-doc drm/nouveau/nouveau_svm: Remove unused variable 'ret' from void function drm/nouveau/nouveau_bios: Remove unused variable 'pdev' from 'nouveau_bios_init()' drm/nouveau/nouveau_ioc32: Demote kernel-doc abuse to standard comment block drm/vmwgfx/ttm_object: Reorder header to immediately precede its struct drivers/gpu/drm/drm_agpsupport.c | 46 +--- drivers/gpu/drm/drm_dp_helper.c | 3 +- drivers/gpu/drm/gma500/cdv_intel_crt.c | 2 +- drivers/gpu/drm/gma500/cdv_intel_display.c | 2 +- drivers/gpu/drm/gma500/cdv_intel_dp.c| 4 +- drivers/gpu/drm/gma500/cdv_intel_lvds.c | 7 +-- drivers/gpu/drm/gma500/mdfld_dsi_output.c| 4 +- drivers/gpu/drm/gma500/mdfld_intel_display.c | 6 +-- drivers/gpu/drm/gma500/mmu.c | 2 +- drivers/gpu/drm/gma500/oaktrail_crtc.c | 6 +-- drivers/gpu/drm/gma500/oaktrail_lvds.c | 3 +- drivers/gpu/drm/gma500/oaktrail_lvds_i2c.c | 8 ++-- drivers/gpu/drm/gma500/psb_intel_sdvo.c | 6 +-- drivers/gpu/drm/gma500/psb_irq.c | 3 +- drivers/gpu/drm/i915/gvt/handlers.c | 2 +- drivers/gpu/drm/nouveau/nouveau_bios.c | 2 - drivers/gpu/drm/nouveau/nouveau_ioc32.c | 4 +- drivers/gpu/drm/nouveau/nouveau_svm.c| 5 +-- drivers/gpu/drm/vmwgfx/ttm_object.c | 25 ++- drivers/gpu/drm/vmwgfx/vmwgfx_binding.c | 9 ++-- drivers/gpu/drm/vmwgfx/vmwgfx_blit.c | 1 + drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf.c | 2 +- drivers/gpu/drm/vmwgfx/vmwgfx_cotable.c | 3 +- drivers/gpu/drm/vmwgfx/vmwgfx_msg.c | 2 +- drivers/gpu/drm/vmwgfx/vmwgfx_so.c | 1 + drivers/gpu/drm/vmwgfx/vmwgfx_thp.c | 1 + drivers/gpu/drm/vmwgfx/vmwgfx_validation.c | 5 ++- 27 files changed, 74 insertions(+), 90 deletions(-) Cc: Ben Skeggs Cc: "Christian König" Cc: Daniel Vetter Cc: Dave Airlie Cc: David Airlie Cc: dri-de...@lists.freedesktop.org Cc: Eddie Dong Cc: Eric Anholt Cc: Faith Cc: Gareth Hughes Cc: intel-gfx@lists.freedesktop.org Cc: intel-gvt-...@lists.freedesktop.org Cc: Jackie Li Cc: Jani Nikula Cc: Jan Safrata Cc: Jesse Barnes Cc: jim liu Cc: Joonas Lahtinen Cc: Keith Packard Cc: Kevin Tian Cc: linaro-mm-...@lists.linaro.org Cc: linux-me...@vger.kernel.org Cc: Maarten Lankhorst Cc: Maxime Ripard Cc: Min He Cc: Niu Bing Cc: nouv...@lists.freedesktop.org Cc: Patrik Jakobsson Cc: Pei Zhang Cc: Ping Gao Cc: Rob Clark Cc: Rodrigo Vivi Cc: Roland Scheidegger Cc: Sumit Semwal Cc: Thomas Zimmermann Cc: Tina Zhang Cc: VMware Graphics Cc: Zack Rusin Cc: Zhe
Re: [Intel-gfx] [patch 16/30] mfd: ab8500-debugfs: Remove the racy fiddling with irq_desc
On Thu, 10 Dec 2020, Thomas Gleixner wrote: > First of all drivers have absolutely no business to dig into the internals > of an irq descriptor. That's core code and subject to change. All of this > information is readily available to /proc/interrupts in a safe and race > free way. > > Remove the inspection code which is a blatant violation of subsystem > boundaries and racy against concurrent modifications of the interrupt > descriptor. > > Print the irq line instead so the information can be looked up in a sane > way in /proc/interrupts. > > Signed-off-by: Thomas Gleixner > Cc: Linus Walleij > Cc: Lee Jones > Cc: linux-arm-ker...@lists.infradead.org > --- > drivers/mfd/ab8500-debugfs.c | 16 +++- > 1 file changed, 3 insertions(+), 13 deletions(-) Acked-by: Lee Jones -- Lee Jones [李琼斯] Senior Technical Lead - Developer Services Linaro.org │ Open source software for Arm SoCs Follow Linaro: Facebook | Twitter | Blog ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v13 00/11] Convert PWM period and duty cycle to u64
On Fri, 24 Apr 2020, Guru Das Srinagesh wrote: > On Fri, Apr 24, 2020 at 07:43:03AM +0100, Lee Jones wrote: > > A great deal of mailing lists contain numerous protections against > > things like flooding and spamming. One of those protections is a > > check for "Too many recipients to the message". Most of the time this > > simply requires moderator intervention by way of review and approval, > > but this ultimately depends on the ML's configuration. > > > > The first thing to ascertain is why your recipients list is so large. > > Have you added every reviewer, subsystem-maintainer, maintainer and > > contributor suggested by get-maintainer.pl? If so, consider pruning > > that a little. Contributors do not tend to care about subsequent > > changes to a file. As someone who receives a lot of patches, I tend > > to get fed-up when receiving patches simply because I made a change X > > years ago. Stick to listed maintainers/reviewers in the first > > instance and see how far that takes you. > > Thank you for the detailed reply. I did this in the first few patchsets > and then when a few patches didn't get any attention, expanded the > audience thus. Still, around 50% of the patches in this series remain > unreviewed by anyone. This isn't a reason to add more recipients (who are likely to care even less than your original group). However it *is* a good argument for including all of the specified maintainers/reviewers in on all of the patches. > > If your recipients list is as succinct as reasonably possible, maybe > > just accept that every version isn't going to be archived by every > > ML. It's still much more useful for the correct people to have > > visibility into the set than for it to be archived multiple times. > > Thank you, will prune the list and remove past contributors from the > Cc-list and add all parties to all patches. Great. Once you've done that, we can start to help you acquire the Acks you need on your remaining patches. -- Lee Jones [李琼斯] Linaro Services Technical Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v13 00/11] Convert PWM period and duty cycle to u64
To: Arnd Bergmann > To: David Laight > To: Jani Nikula > Cc: Alexander Shiyan > Cc: Alexandre Torgue > Cc: Allison Randal > Cc: Arnd Bergmann > Cc: Atish Patra > Cc: Bartlomiej Zolnierkiewicz > Cc: Chen-Yu Tsai > Cc: Chris Wilson > Cc: Dan Carpenter > Cc: Daniel Thompson > Cc: Daniel Vetter > Cc: David Airlie > Cc: David Collins > Cc: dri-de...@lists.freedesktop.org > Cc: Fabio Estevam > Cc: Fabrice Gasnier > Cc: Guenter Roeck > Cc: intel-gfx@lists.freedesktop.org > Cc: Jean Delvare > Cc: Jingoo Han > Cc: Joe Perches > Cc: Joonas Lahtinen > Cc: Kamil Debski > Cc: Kate Stewart > Cc: Lee Jones > Cc: Liam Girdwood > Cc: linux-...@vger.kernel.org > Cc: linux-fb...@vger.kernel.org > Cc: linux-hw...@vger.kernel.org > Cc: linux-me...@vger.kernel.org > Cc: linux-...@vger.kernel.org > Cc: linux-ri...@lists.infradead.org > Cc: Mark Brown > Cc: Mauro Carvalho Chehab > Cc: Maxime Coquelin > Cc: Maxime Ripard > Cc: Michael Turquette > Cc: NXP Linux Team > Cc: Palmer Dabbelt > Cc: Paul Walmsley > Cc: Pengutronix Kernel Team > Cc: Philipp Zabel > Cc: Richard Fontana > Cc: Sascha Hauer > Cc: Shawn Guo > Cc: Stephen Boyd > Cc: Thomas Gleixner > Cc: "Ville Syrjälä" > Cc: Yash Shah > > Guru Das Srinagesh (11): > drm/i915: Use 64-bit division macro > hwmon: pwm-fan: Use 64-bit division macro > ir-rx51: Use 64-bit division macro > pwm: clps711x: Cast period to u32 before use as divisor > pwm: pwm-imx-tpm: Use 64-bit division macro > pwm: imx27: Use 64-bit division macro and function > pwm: sifive: Use 64-bit division macro > pwm: sun4i: Use nsecs_to_jiffies to avoid a division > backlight: pwm_bl: Use 64-bit division function > clk: pwm: Use 64-bit division function > pwm: core: Convert period and duty cycle to u64 > > drivers/clk/clk-pwm.c | 7 +++- > drivers/gpu/drm/i915/display/intel_panel.c | 2 +- > drivers/hwmon/pwm-fan.c | 2 +- > drivers/media/rc/ir-rx51.c | 3 +- > drivers/pwm/core.c | 14 > drivers/pwm/pwm-clps711x.c | 5 ++- > drivers/pwm/pwm-imx-tpm.c | 2 +- > drivers/pwm/pwm-imx27.c| 53 > +- > drivers/pwm/pwm-sifive.c | 2 +- > drivers/pwm/pwm-stm32-lp.c | 2 +- > drivers/pwm/pwm-sun4i.c| 2 +- > drivers/pwm/sysfs.c| 8 ++--- > drivers/video/backlight/pwm_bl.c | 3 +- Acked-by: Lee Jones > include/linux/pwm.h| 12 +++ > 14 files changed, 82 insertions(+), 35 deletions(-) -- Lee Jones [李琼斯] Linaro Services Technical Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v13 00/11] Convert PWM period and duty cycle to u64
On Thu, 23 Apr 2020, Guru Das Srinagesh wrote: > On Thu, Apr 23, 2020 at 12:48:57PM +0100, Lee Jones wrote: > > What's the merge plan for this set? > > I'm not sure what you mean. My assumption is that first all the patches > need to get an Acked-by and only then will the series get applied by > Thierry... Could Thierry or Uwe weigh in on this point please? Yes, that is the merge plan. :) Whoever takes this will have to offer out an immutable PR. -- Lee Jones [李琼斯] Linaro Services Technical Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v13 00/11] Convert PWM period and duty cycle to u64
On Thu, 23 Apr 2020, Guru Das Srinagesh wrote: > On Thu, Apr 23, 2020 at 12:48:57PM +0100, Lee Jones wrote: > > What's the merge plan for this set? > > I'm not sure what you mean. My assumption is that first all the patches > need to get an Acked-by and only then will the series get applied by > Thierry... Could Thierry or Uwe weigh in on this point please? > > > FYI, it's better to send all patches to all parties. That way > > maintainers and interested persons can follow the discussion and > > progress, or lack there of. > > Something I noticed with adding all the various mailing lists to the CC > list for this cover letter is that it is causing this cover letter email > and all its replies to not be archived properly on spinics or lore - > it's probably getting rejected by email filters somehow. Compare with > v12 [1] where I'd pruned the list considerably as an experiment - that > got archived correctly. > > Any ideas on what might be going wrong? Once I fix this I can add all > parties to all patches knowing that there would be no issues in mail > archival. A great deal of mailing lists contain numerous protections against things like flooding and spamming. One of those protections is a check for "Too many recipients to the message". Most of the time this simply requires moderator intervention by way of review and approval, but this ultimately depends on the ML's configuration. The first thing to ascertain is why your recipients list is so large. Have you added every reviewer, subsystem-maintainer, maintainer and contributor suggested by get-maintainer.pl? If so, consider pruning that a little. Contributors do not tend to care about subsequent changes to a file. As someone who receives a lot of patches, I tend to get fed-up when receiving patches simply because I made a change X years ago. Stick to listed maintainers/reviewers in the first instance and see how far that takes you. If your recipients list is as succinct as reasonably possible, maybe just accept that every version isn't going to be archived by every ML. It's still much more useful for the correct people to have visibility into the set than for it to be archived multiple times. > [1] https://www.spinics.net/lists/linux-pwm/msg12131.html > > Thank you. > > Guru Das. -- Lee Jones [李琼斯] Linaro Services Technical Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v13 00/11] Convert PWM period and duty cycle to u64
On Tue, 21 Apr 2020, Guru Das Srinagesh wrote: > [REQUEST] > > Would it be possible for the patches that have already received Acked-by's in > this series to be accepted and applied to the tree? I lost an Acked-by (in > intel-panel.c) because it had a merge conflict with a new change that came in > after I rebased to tip. I wasn't sure earlier about accepting single patches > as > opposed to the entire series en masse, but this event has got me thinking. > > [COVER LETTER] > > Because period and duty cycle are defined in the PWM framework structs as ints > with units of nanoseconds, the maximum time duration that can be set is > limited > to ~2.147 seconds. Consequently, applications desiring to set greater time > periods via the PWM framework are not be able to do so - like, for instance, > causing an LED to blink at an interval of 5 seconds. > > Redefining the period and duty cycle struct members in the core PWM framework > structs as u64 values will enable larger time durations to be set and solve > this problem. Such a change to the framework mandates that drivers using these > struct members (and corresponding helper functions) also be modified correctly > in order to prevent compilation errors. > > This patch series introduces the changes to all the drivers first, followed by > the framework change at the very end so that when the latter is applied, all > the drivers are in good shape and there are no compilation errors. What's the merge plan for this set? FYI, it's better to send all patches to all parties. That way maintainers and interested persons can follow the discussion and progress, or lack there of. -- Lee Jones [李琼斯] Linaro Services Technical Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/3] mfd: intel_soc_pmic: Rename pwm_backlight pwm-lookup to pwm_pmic_backlight
On Wed, 18 Dec 2019, Jani Nikula wrote: > On Tue, 17 Dec 2019, Lee Jones wrote: > > Hans was making the case that this was impractical for DRM, due to the > > amount of churn you guys receive, hence the discussion. I'm very > > pleased that this is not the case. > > Heh, well, it is the case, but the point is that should be our problem, > not yours. ;) :) -- Lee Jones [李琼斯] Linaro Services Technical Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/3] mfd: intel_soc_pmic: Rename pwm_backlight pwm-lookup to pwm_pmic_backlight
On Tue, 17 Dec 2019, Jani Nikula wrote: > On Tue, 17 Dec 2019, Lee Jones wrote: > > On Mon, 16 Dec 2019, Hans de Goede wrote: > > > >> Hi, > >> > >> Doing immutable branches assumes that there is a base point, > >> e.g. 5.5-rc1 where the immutable branch can then be based on and > >> that the branch can then be merged without issues into both subsystems. > >> > >> drm is constantly evolving to deal with and mostly catch up with new > >> hardware as both GPUs and display-pipelines are evolving quite rapidly > >> atm drm-intel-next has about 400 commits on top of 5.5-rc1 so for an > >> immutable branch I can either base it on drm-intel-next which > >> violates your request for a clean minimal branch to merge; or I can > >> base it on 5.5-rc1 which leads to a big chance of problems when > >> merging it given to large amount of churn in drm-intel-next. > > > > This is a *slightly* more compelling reason than the ones you've > > previously provided. > > > >> So instead of the normal case of 2 subsystems seeing some changes > >> on both side the case we have here is a part of a file which has > >> not changed since 2015-06-26 in one subsys (and changing only > >> a single line there!) and OTOH we have bigger changes to a subsys > >> which see 400 patches land in the first week since rc1 . > > > > This is not. > > > >> I hope that you agree that in this case given the large amount of > >> churn in drm-intel-next it makes since to just straight forward > >> apply these patches on top of drm-intel-next. > > > > I have Acked this patch, but remember *this* is the exception rather > > than the rule. If/when we have a case where a contributor works > > cross-subsystem with DRM and the code/file adapted is live (more > > likely to change), I will have to insist on an immutable branch > > strategy. DRM will have to deal with that appropriately. > > Hi, thanks for the ack and reaching an agreement with Hans, and sorry > for not responding earlier. > > It's not unusual for us to have topic branches for cross-subsystem or > cross-driver changes, and I think usually we try to be accommodating in > merging stuff through whichever tree it makes most sense. In fact my ack > to do just that was my first response on this series [1]. > > So I don't really know why the fuss. We'll anyway deal with any > cross-subsystem series on a case by case basis, depending on what makes > most sense, and what suits all maintainers involved. Perfect. Thanks for the clarification. I look forward to working with you guys in the future. Hans was making the case that this was impractical for DRM, due to the amount of churn you guys receive, hence the discussion. I'm very pleased that this is not the case. -- Lee Jones [李琼斯] Linaro Services Technical Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/3] mfd: intel_soc_pmic: Rename pwm_backlight pwm-lookup to pwm_pmic_backlight
On Mon, 16 Dec 2019, Hans de Goede wrote: > Hi, > > On 16-12-2019 10:30, Lee Jones wrote: > > [...] > > > > > > > > > > > > > Which use a Crystal Cove PMIC, yet the LCD is connected > > > > > > > > > > > to the SoC/LPSS > > > > > > > > > > > PWM controller (and the VBT correctly indicates this), so > > > > > > > > > > > here our old > > > > > > > > > > > heuristics fail. > > > > > > > > > > > > > > > > > > > > > > Since only the i915 driver has access to the VBT, this > > > > > > > > > > > commit renames > > > > > > > > > > > the "pwm_backlight" lookup entries for the Crystal Cove > > > > > > > > > > > PMIC's PWM > > > > > > > > > > > controller to "pwm_pmic_backlight" so that the i915 > > > > > > > > > > > driver can do a > > > > > > > > > > > pwm_get() for the right controller depending on the VBT > > > > > > > > > > > bit, instead of > > > > > > > > > > > the i915 driver relying on a "pwm_backlight" lookup > > > > > > > > > > > getting registered > > > > > > > > > > > which magically points to the right controller. > > > > > > > > > > > > > > > > > > > > > > Signed-off-by: Hans de Goede > > > > > > > > > > > --- > > > > > > > > > > > drivers/mfd/intel_soc_pmic_core.c | 2 +- > > > > > > > > > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > > > > > > > > > > > > > > > For my own reference: > > > > > > > > > >Acked-for-MFD-by: Lee Jones > > > > > > > > > > > > > > > > > > As mentioned in the cover-letter, to avoid breaking > > > > > > > > > bi-sectability > > > > > > > > > as well as to avoid breaking the intel-gfx CI we need to > > > > > > > > > merge this series > > > > > > > > > in one go through one tree. Specifically through the > > > > > > > > > drm-intel tree. > > > > > > > > > Is that ok with you ? > > > > > > > > > > > > > > > > > > If this is ok with you, then you do not have to do anything, > > > > > > > > > I will just push > > > > > > > > > the entire series to drm-intel. > > > > > > > > > drivers/mfd/intel_soc_pmic_core.c > > > > > > > > > does not see much changes so I do not expect this to lead to > > > > > > > > > any conflicts. > > > > > > > > > > > > > > > > It's fine, so long as a minimal immutable pull-request is > > > > > > > > provided. > > > > > > > > Whether it's pulled or not will depend on a number of factors, > > > > > > > > but it > > > > > > > > needs to be an option. > > > > > > > > > > > > > > The way the drm subsys works that is not really a readily > > > > > > > available > > > > > > > option. The struct definition which this patch changes a single > > > > > > > line in > > > > > > > has not been touched since 2015-06-26 so I really doubt we will > > > > > > > get a > > > > > > > conflict from this. > > > > > > > > > > > > Always with the exceptions ... > > > > > > > > > > > > OOI, why does this *have* to go through the DRM tree? > > > > > > > > > > This patch renames the name used to lookup the pwm controller from > > > > > "pwm_backlight" to "pwm_pmic_backlight" because there are 2 possible > > > > > pwm controllers which may be used, one in the SoC itself and one > > > > > in the PMIC. Which controller should be used is described in a table > > > > >
Re: [Intel-gfx] [PATCH v2 4/5] drm/i915/dsi: Move Crystal Cove PMIC panel GPIO lookup from mfd to the i915 driver
On Mon, 16 Dec 2019, Hans de Goede wrote: > Move the Crystal Cove PMIC panel GPIO lookup-table from > drivers/mfd/intel_soc_pmic_core.c to the i915 driver. > > The moved looked-up table is adding a GPIO lookup to the i915 PCI > device and the GPIO subsys allows only one lookup table per device, > > The intel_soc_pmic_core.c code only adds lookup-table entries for the > PMIC panel GPIO (as it deals only with the PMIC), but we also need to be > able to access some GPIOs on the SoC itself, which requires entries for > these GPIOs in the lookup-table. > > Since the lookup-table is attached to the i915 PCI device it really > should be part of the i915 driver, this will also allow us to extend > it with GPIOs from other sources when necessary. > > Acked-by: Linus Walleij > Reviewed-by: Andy Shevchenko > Reviewed-by: Ville Syrjälä > Signed-off-by: Hans de Goede > --- > drivers/gpu/drm/i915/display/intel_dsi_vbt.c | 23 +++- > drivers/mfd/intel_soc_pmic_core.c| 19 > 2 files changed, 22 insertions(+), 20 deletions(-) Acked-by: Lee Jones -- Lee Jones [李琼斯] Linaro Services Technical Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [CI 2/3] mfd: intel_soc_pmic: Rename pwm_backlight pwm-lookup to pwm_pmic_backlight
On Mon, 16 Dec 2019, Hans de Goede wrote: > At least Bay Trail (BYT) and Cherry Trail (CHT) devices can use 1 of 2 > different PWM controllers for controlling the LCD's backlight brightness. > > Either the one integrated into the PMIC or the one integrated into the > SoC (the 1st LPSS PWM controller). > > So far in the LPSS code on BYT we have skipped registering the LPSS PWM > controller "pwm_backlight" lookup entry when a Crystal Cove PMIC is > present, assuming that in this case the PMIC PWM controller will be used. > > On CHT we have been relying on only 1 of the 2 PWM controllers being > enabled in the DSDT at the same time; and always registered the lookup. > > So far this has been working, but the correct way to determine which PWM > controller needs to be used is by checking a bit in the VBT table and > recently I've learned about 2 different BYT devices: > Point of View MOBII TAB-P800W > Acer Switch 10 SW5-012 > > Which use a Crystal Cove PMIC, yet the LCD is connected to the SoC/LPSS > PWM controller (and the VBT correctly indicates this), so here our old > heuristics fail. > > Since only the i915 driver has access to the VBT, this commit renames > the "pwm_backlight" lookup entries for the Crystal Cove PMIC's PWM > controller to "pwm_pmic_backlight" so that the i915 driver can do a > pwm_get() for the right controller depending on the VBT bit, instead of > the i915 driver relying on a "pwm_backlight" lookup getting registered > which magically points to the right controller. > > Acked-by: Jani Nikula > Reviewed-by: Andy Shevchenko > Signed-off-by: Hans de Goede > --- > drivers/mfd/intel_soc_pmic_core.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Acked-by: Lee Jones -- Lee Jones [李琼斯] Linaro Services Technical Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 0/5] drm/i915/dsi: Control panel and backlight enable GPIOs from VBT
On Mon, 16 Dec 2019, Andy Shevchenko wrote: > On Sun, Dec 15, 2019 at 05:38:05PM +0100, Hans de Goede wrote: > > Hi All, > > > > This is a new (completely rewritten) version of my patches to make the > > i915 code control the SoC panel- and backlight-enable GPIOs on Bay Trail > > devices when the VBT indicates that the SoC should be used for backlight > > control. This fixes the panel not lighting up on various devices when > > booted with a HDMI monitor connected, in which case the firmware skips > > initializing the panel as it inits the HDMI instead. > > > > This series has been tested on; and fixes this issue on; the following > > models: > > > > Peaq C1010 > > Point of View MOBII TAB-P800W > > Point of View MOBII TAB-P1005W > > Terra Pad 1061 > > Thundersoft TST178 > > Yours Y8W81 > > > > Linus, this series starts with the already discussed pinctrl change to > > export the function to unregister a pinctrl-map. We can either merge this > > through drm-intel, or you could pick it up and then provide an immutable > > branch with it for merging into drm-intel-next. Which option do you prefer? > > > > Lee, I know you don't like this, but unfortunately this series introcudes > > some (other) changes to drivers/mfd/intel_soc_pmic_core.c. The GPIO subsys > > allows only one mapping-table per consumer, so in hindsight adding the code > > which adds the mapping for the PMIC panel-enable pin to the PMIC mfd driver > > was a mistake, as the PMIC code is a provider where as mapping-tables are > > per consumer. The 4th patch fixes this by moving the mapping-table to the > > i915 code, so that we can also add mappings for some of the pins on the SoC > > itself. Since this whole series makes change to the i915 code I plan to > > merge this mfd change to the drm-intel tree. > > FWIW, Lee, I believe there will be no (significant) changes in the driver Hans > touched. For the record it seems only Hans is touching drivers for old Intel > platforms (such as Baytrail and Cherryview). More exceptions, yay! Again, in *this* case, it's probably fine. What I want to know is; what happens when it's not fine? What happens when you or someone else starts changing MFD and DRM on more active files? Then I will have to insist on an immutable branch. So it would be better for the DRM tree to be able to handle that use-case sooner rather than later, regardless of who has the most churn. -- Lee Jones [李琼斯] Linaro Services Technical Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/3] mfd: intel_soc_pmic: Rename pwm_backlight pwm-lookup to pwm_pmic_backlight
[...]
> > > > > > > > > Which use a Crystal Cove PMIC, yet the LCD is connected to
> > > > > > > > > the SoC/LPSS
> > > > > > > > > PWM controller (and the VBT correctly indicates this), so
> > > > > > > > > here our old
> > > > > > > > > heuristics fail.
> > > > > > > > >
> > > > > > > > > Since only the i915 driver has access to the VBT, this commit
> > > > > > > > > renames
> > > > > > > > > the "pwm_backlight" lookup entries for the Crystal Cove
> > > > > > > > > PMIC's PWM
> > > > > > > > > controller to "pwm_pmic_backlight" so that the i915 driver
> > > > > > > > > can do a
> > > > > > > > > pwm_get() for the right controller depending on the VBT bit,
> > > > > > > > > instead of
> > > > > > > > > the i915 driver relying on a "pwm_backlight" lookup getting
> > > > > > > > > registered
> > > > > > > > > which magically points to the right controller.
> > > > > > > > >
> > > > > > > > > Signed-off-by: Hans de Goede
> > > > > > > > > ---
> > > > > > > > > drivers/mfd/intel_soc_pmic_core.c | 2 +-
> > > > > > > > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > > > > > > >
> > > > > > > > For my own reference:
> > > > > > > > Acked-for-MFD-by: Lee Jones
> > > > > > >
> > > > > > > As mentioned in the cover-letter, to avoid breaking bi-sectability
> > > > > > > as well as to avoid breaking the intel-gfx CI we need to merge
> > > > > > > this series
> > > > > > > in one go through one tree. Specifically through the drm-intel
> > > > > > > tree.
> > > > > > > Is that ok with you ?
> > > > > > >
> > > > > > > If this is ok with you, then you do not have to do anything, I
> > > > > > > will just push
> > > > > > > the entire series to drm-intel. drivers/mfd/intel_soc_pmic_core.c
> > > > > > > does not see much changes so I do not expect this to lead to any
> > > > > > > conflicts.
> > > > > >
> > > > > > It's fine, so long as a minimal immutable pull-request is provided.
> > > > > > Whether it's pulled or not will depend on a number of factors, but
> > > > > > it
> > > > > > needs to be an option.
> > > > >
> > > > > The way the drm subsys works that is not really a readily available
> > > > > option. The struct definition which this patch changes a single line
> > > > > in
> > > > > has not been touched since 2015-06-26 so I really doubt we will get a
> > > > > conflict from this.
> > > >
> > > > Always with the exceptions ...
> > > >
> > > > OOI, why does this *have* to go through the DRM tree?
> > >
> > > This patch renames the name used to lookup the pwm controller from
> > > "pwm_backlight" to "pwm_pmic_backlight" because there are 2 possible
> > > pwm controllers which may be used, one in the SoC itself and one
> > > in the PMIC. Which controller should be used is described in a table
> > > in the Video BIOS, so another part of this series adds this code to
> > > the i915 driver:
> > >
> > > - panel->backlight.pwm = pwm_get(dev->dev, "pwm_backlight");
> > > + /* Get the right PWM chip for DSI backlight according to VBT */
> > > + if (dev_priv->vbt.dsi.config->pwm_blc == PPS_BLC_PMIC) {
> > > + panel->backlight.pwm = pwm_get(dev->dev, "pwm_pmic_backlight");
> > > + desc = "PMIC";
> > > + } else {
> > > + panel->backlight.pwm = pwm_get(dev->dev, "pwm_soc_backlight");
> > > + desc = "SoC";
> > > + }
> > >
> > > So both not to break bisectability, but also so as to not break the
> > > extensive
> > > CI system which is used to test the i915 driver we need th
Re: [Intel-gfx] [PATCH 2/3] mfd: intel_soc_pmic: Rename pwm_backlight pwm-lookup to pwm_pmic_backlight
On Thu, 12 Dec 2019, Hans de Goede wrote: > Hi, > > On 12-12-2019 16:52, Lee Jones wrote: > > On Thu, 12 Dec 2019, Hans de Goede wrote: > > > > > Hi, > > > > > > On 12-12-2019 09:45, Lee Jones wrote: > > > > On Wed, 11 Dec 2019, Hans de Goede wrote: > > > > > > > > > Hi Lee, > > > > > > > > > > On 10-12-2019 09:51, Lee Jones wrote: > > > > > > On Tue, 19 Nov 2019, Hans de Goede wrote: > > > > > > > > > > > > > At least Bay Trail (BYT) and Cherry Trail (CHT) devices can use 1 > > > > > > > of 2 > > > > > > > different PWM controllers for controlling the LCD's backlight > > > > > > > brightness. > > > > > > > > > > > > > > Either the one integrated into the PMIC or the one integrated > > > > > > > into the > > > > > > > SoC (the 1st LPSS PWM controller). > > > > > > > > > > > > > > So far in the LPSS code on BYT we have skipped registering the > > > > > > > LPSS PWM > > > > > > > controller "pwm_backlight" lookup entry when a Crystal Cove PMIC > > > > > > > is > > > > > > > present, assuming that in this case the PMIC PWM controller will > > > > > > > be used. > > > > > > > > > > > > > > On CHT we have been relying on only 1 of the 2 PWM controllers > > > > > > > being > > > > > > > enabled in the DSDT at the same time; and always registered the > > > > > > > lookup. > > > > > > > > > > > > > > So far this has been working, but the correct way to determine > > > > > > > which PWM > > > > > > > controller needs to be used is by checking a bit in the VBT table > > > > > > > and > > > > > > > recently I've learned about 2 different BYT devices: > > > > > > > Point of View MOBII TAB-P800W > > > > > > > Acer Switch 10 SW5-012 > > > > > > > > > > > > > > Which use a Crystal Cove PMIC, yet the LCD is connected to the > > > > > > > SoC/LPSS > > > > > > > PWM controller (and the VBT correctly indicates this), so here > > > > > > > our old > > > > > > > heuristics fail. > > > > > > > > > > > > > > Since only the i915 driver has access to the VBT, this commit > > > > > > > renames > > > > > > > the "pwm_backlight" lookup entries for the Crystal Cove PMIC's PWM > > > > > > > controller to "pwm_pmic_backlight" so that the i915 driver can do > > > > > > > a > > > > > > > pwm_get() for the right controller depending on the VBT bit, > > > > > > > instead of > > > > > > > the i915 driver relying on a "pwm_backlight" lookup getting > > > > > > > registered > > > > > > > which magically points to the right controller. > > > > > > > > > > > > > > Signed-off-by: Hans de Goede > > > > > > > --- > > > > > > > drivers/mfd/intel_soc_pmic_core.c | 2 +- > > > > > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > > > > > > > For my own reference: > > > > > > Acked-for-MFD-by: Lee Jones > > > > > > > > > > As mentioned in the cover-letter, to avoid breaking bi-sectability > > > > > as well as to avoid breaking the intel-gfx CI we need to merge this > > > > > series > > > > > in one go through one tree. Specifically through the drm-intel tree. > > > > > Is that ok with you ? > > > > > > > > > > If this is ok with you, then you do not have to do anything, I will > > > > > just push > > > > > the entire series to drm-intel. drivers/mfd/intel_soc_pmic_core.c > > > > > does not see much changes so I do not expect this to lead to any > > > > > conflicts. > > > > > > > > It's fine, so long as a minimal immutable pull-request is provided. > > > > Whether it's pulled or not
Re: [Intel-gfx] [PATCH 2/3] mfd: intel_soc_pmic: Rename pwm_backlight pwm-lookup to pwm_pmic_backlight
On Thu, 12 Dec 2019, Hans de Goede wrote: > Hi, > > On 12-12-2019 09:45, Lee Jones wrote: > > On Wed, 11 Dec 2019, Hans de Goede wrote: > > > > > Hi Lee, > > > > > > On 10-12-2019 09:51, Lee Jones wrote: > > > > On Tue, 19 Nov 2019, Hans de Goede wrote: > > > > > > > > > At least Bay Trail (BYT) and Cherry Trail (CHT) devices can use 1 of 2 > > > > > different PWM controllers for controlling the LCD's backlight > > > > > brightness. > > > > > > > > > > Either the one integrated into the PMIC or the one integrated into the > > > > > SoC (the 1st LPSS PWM controller). > > > > > > > > > > So far in the LPSS code on BYT we have skipped registering the LPSS > > > > > PWM > > > > > controller "pwm_backlight" lookup entry when a Crystal Cove PMIC is > > > > > present, assuming that in this case the PMIC PWM controller will be > > > > > used. > > > > > > > > > > On CHT we have been relying on only 1 of the 2 PWM controllers being > > > > > enabled in the DSDT at the same time; and always registered the > > > > > lookup. > > > > > > > > > > So far this has been working, but the correct way to determine which > > > > > PWM > > > > > controller needs to be used is by checking a bit in the VBT table and > > > > > recently I've learned about 2 different BYT devices: > > > > > Point of View MOBII TAB-P800W > > > > > Acer Switch 10 SW5-012 > > > > > > > > > > Which use a Crystal Cove PMIC, yet the LCD is connected to the > > > > > SoC/LPSS > > > > > PWM controller (and the VBT correctly indicates this), so here our old > > > > > heuristics fail. > > > > > > > > > > Since only the i915 driver has access to the VBT, this commit renames > > > > > the "pwm_backlight" lookup entries for the Crystal Cove PMIC's PWM > > > > > controller to "pwm_pmic_backlight" so that the i915 driver can do a > > > > > pwm_get() for the right controller depending on the VBT bit, instead > > > > > of > > > > > the i915 driver relying on a "pwm_backlight" lookup getting registered > > > > > which magically points to the right controller. > > > > > > > > > > Signed-off-by: Hans de Goede > > > > > --- > > > > >drivers/mfd/intel_soc_pmic_core.c | 2 +- > > > > >1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > > > For my own reference: > > > > Acked-for-MFD-by: Lee Jones > > > > > > As mentioned in the cover-letter, to avoid breaking bi-sectability > > > as well as to avoid breaking the intel-gfx CI we need to merge this series > > > in one go through one tree. Specifically through the drm-intel tree. > > > Is that ok with you ? > > > > > > If this is ok with you, then you do not have to do anything, I will just > > > push > > > the entire series to drm-intel. drivers/mfd/intel_soc_pmic_core.c > > > does not see much changes so I do not expect this to lead to any > > > conflicts. > > > > It's fine, so long as a minimal immutable pull-request is provided. > > Whether it's pulled or not will depend on a number of factors, but it > > needs to be an option. > > The way the drm subsys works that is not really a readily available > option. The struct definition which this patch changes a single line in > has not been touched since 2015-06-26 so I really doubt we will get a > conflict from this. Always with the exceptions ... OOI, why does this *have* to go through the DRM tree? -- Lee Jones [李琼斯] Linaro Services Technical Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/3] mfd: intel_soc_pmic: Rename pwm_backlight pwm-lookup to pwm_pmic_backlight
On Wed, 11 Dec 2019, Hans de Goede wrote: > Hi Lee, > > On 10-12-2019 09:51, Lee Jones wrote: > > On Tue, 19 Nov 2019, Hans de Goede wrote: > > > > > At least Bay Trail (BYT) and Cherry Trail (CHT) devices can use 1 of 2 > > > different PWM controllers for controlling the LCD's backlight brightness. > > > > > > Either the one integrated into the PMIC or the one integrated into the > > > SoC (the 1st LPSS PWM controller). > > > > > > So far in the LPSS code on BYT we have skipped registering the LPSS PWM > > > controller "pwm_backlight" lookup entry when a Crystal Cove PMIC is > > > present, assuming that in this case the PMIC PWM controller will be used. > > > > > > On CHT we have been relying on only 1 of the 2 PWM controllers being > > > enabled in the DSDT at the same time; and always registered the lookup. > > > > > > So far this has been working, but the correct way to determine which PWM > > > controller needs to be used is by checking a bit in the VBT table and > > > recently I've learned about 2 different BYT devices: > > > Point of View MOBII TAB-P800W > > > Acer Switch 10 SW5-012 > > > > > > Which use a Crystal Cove PMIC, yet the LCD is connected to the SoC/LPSS > > > PWM controller (and the VBT correctly indicates this), so here our old > > > heuristics fail. > > > > > > Since only the i915 driver has access to the VBT, this commit renames > > > the "pwm_backlight" lookup entries for the Crystal Cove PMIC's PWM > > > controller to "pwm_pmic_backlight" so that the i915 driver can do a > > > pwm_get() for the right controller depending on the VBT bit, instead of > > > the i915 driver relying on a "pwm_backlight" lookup getting registered > > > which magically points to the right controller. > > > > > > Signed-off-by: Hans de Goede > > > --- > > > drivers/mfd/intel_soc_pmic_core.c | 2 +- > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > For my own reference: > >Acked-for-MFD-by: Lee Jones > > As mentioned in the cover-letter, to avoid breaking bi-sectability > as well as to avoid breaking the intel-gfx CI we need to merge this series > in one go through one tree. Specifically through the drm-intel tree. > Is that ok with you ? > > If this is ok with you, then you do not have to do anything, I will just push > the entire series to drm-intel. drivers/mfd/intel_soc_pmic_core.c > does not see much changes so I do not expect this to lead to any conflicts. It's fine, so long as a minimal immutable pull-request is provided. Whether it's pulled or not will depend on a number of factors, but it needs to be an option. -- Lee Jones [李琼斯] Linaro Services Technical Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/3] mfd: intel_soc_pmic: Rename pwm_backlight pwm-lookup to pwm_pmic_backlight
On Tue, 19 Nov 2019, Hans de Goede wrote: > At least Bay Trail (BYT) and Cherry Trail (CHT) devices can use 1 of 2 > different PWM controllers for controlling the LCD's backlight brightness. > > Either the one integrated into the PMIC or the one integrated into the > SoC (the 1st LPSS PWM controller). > > So far in the LPSS code on BYT we have skipped registering the LPSS PWM > controller "pwm_backlight" lookup entry when a Crystal Cove PMIC is > present, assuming that in this case the PMIC PWM controller will be used. > > On CHT we have been relying on only 1 of the 2 PWM controllers being > enabled in the DSDT at the same time; and always registered the lookup. > > So far this has been working, but the correct way to determine which PWM > controller needs to be used is by checking a bit in the VBT table and > recently I've learned about 2 different BYT devices: > Point of View MOBII TAB-P800W > Acer Switch 10 SW5-012 > > Which use a Crystal Cove PMIC, yet the LCD is connected to the SoC/LPSS > PWM controller (and the VBT correctly indicates this), so here our old > heuristics fail. > > Since only the i915 driver has access to the VBT, this commit renames > the "pwm_backlight" lookup entries for the Crystal Cove PMIC's PWM > controller to "pwm_pmic_backlight" so that the i915 driver can do a > pwm_get() for the right controller depending on the VBT bit, instead of > the i915 driver relying on a "pwm_backlight" lookup getting registered > which magically points to the right controller. > > Signed-off-by: Hans de Goede > --- > drivers/mfd/intel_soc_pmic_core.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) For my own reference: Acked-for-MFD-by: Lee Jones -- Lee Jones [李琼斯] Linaro Services Technical Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PULL] topic/remove-fbcon-notifiers for v5.3
On Tue, 18 Jun 2019, Daniel Vetter wrote: > On Tue, Jun 18, 2019 at 11:03:47AM +0100, Lee Jones wrote: > > On Tue, 18 Jun 2019, Maarten Lankhorst wrote: > > > > > Op 14-06-2019 om 11:25 schreef Maarten Lankhorst: > > > > Hi all, > > > > > > > > As discussed with Daniel V, I'm just doing the paperwork here as > > > > drm-misc maintainer. > > > > > > > > This is the topic pull request for the fbdev notifier removal. > > > > > > > > Bar, please make a final check and pull into your fbdev tree. > > > > > > > > Lee, please make a final check and pull into your backlight tree. > > > > > > > > Greg, this is just fyi, you already acked all the vt and staging > > > > patches in here > > > > to land through other trees. > > > > > > > > I'll pull this into drm-misc-next once Bart & Lee acked it. > > > > > > > > Cheers, Maarten. > > > > > > Bart, Lee, ping? > > > > Asking for an Ack on a PR is kind of odd. If you have all of the > > patch Acks you need, and you've made the PR has small as possible, > > then you should be good to go. > > Ime there's lots of ways to screw up a pull request, so asking for a "yup > looks good to me" seems reasonable. I've done that with all the topic > pulls in the past. Instead of burdening others, it's probably best to take 'no news is good news' stance. In all of the immutable branch PRs I've sent out, other than the occasional 'pulled thanks', no one has ever reviewed/ acked them before. > > My plan is to see if any of this collides with my PR to Linus. If it > > doesn't then I may not have to pull it in at all. > > For simple conflicts Linus usually prefers to resolve them himself. The > topic pull is needed if there's more stuff on top, like patches that need > to be rebased ... There are multiple uses for immutable branches. I'll pull this one if the need arises. > > > > topic/remove-fbcon-notifiers-2019-06-14-1: > > > > > > > > topic/remove-fbcon-notifiers: > > > > - remove fbdev notifier usage for fbcon, as prep work to clean up the > > > > fbcon locking > > > > - assorted locking checks in vt/console code > > > > - assorted notifier and cleanups in fbdev and backlight code > > > > > > > > The following changes since commit > > > > d1fdb6d8f6a4109a4263176c84b899076a5f8008: > > > > > > > > Linux 5.2-rc4 (2019-06-08 20:24:46 -0700) > > > > > > > > are available in the Git repository at: > > > > > > > > git://anongit.freedesktop.org/drm/drm-misc > > > > tags/topic/remove-fbcon-notifiers-2019-06-14-1 > > > > > > > > for you to fetch changes up to 1dcff4ae65185e8c0300972f6d8d39d9a9db2bda: > > > > > > > > backlight: simplify lcd notifier (2019-06-13 10:07:20 +0200) > > > > > > > > > > > > Daniel Vetter (33): > > > > dummycon: Sprinkle locking checks > > > > fbdev: locking check for fb_set_suspend > > > > vt: might_sleep() annotation for do_blank_screen > > > > vt: More locking checks > > > > fbdev/sa1100fb: Remove dead code > > > > fbdev/cyber2000: Remove struct display > > > > fbdev/aty128fb: Remove dead code > > > > fbcon: s/struct display/struct fbcon_display/ > > > > fbcon: Remove fbcon_has_exited > > > > fbcon: call fbcon_fb_(un)registered directly > > > > fbdev/sh_mobile: remove sh_mobile_lcdc_display_notify > > > > fbdev/omap: sysfs files can't disappear before the device is gone > > > > fbdev: sysfs files can't disappear before the device is gone > > > > staging/olpc: lock_fb_info can't fail > > > > fbdev/atyfb: lock_fb_info can't fail > > > > fbdev: lock_fb_info cannot fail > > > > fbcon: call fbcon_fb_bind directly > > > > fbdev: make unregister/unlink functions not fail > > > > fbdev: unify unlink_framebuffer paths > > > > fbdev/sh_mob: Remove fb notifier callback > > > > fbdev: directly call fbcon_suspended/resumed > > > > fbco
Re: [Intel-gfx] [PULL] topic/remove-fbcon-notifiers for v5.3
| 6 +- > > drivers/video/fbdev/core/fbcon.c| 313 --- > > drivers/video/fbdev/core/fbcon.h| 6 +- > > drivers/video/fbdev/core/fbmem.c| 399 > > +--- > > drivers/video/fbdev/core/fbsysfs.c | 20 +- > > drivers/video/fbdev/cyber2000fb.c | 1 - > > drivers/video/fbdev/neofb.c | 9 +- > > drivers/video/fbdev/omap2/omapfb/omapfb-sysfs.c | 21 +- > > drivers/video/fbdev/sa1100fb.c | 25 -- > > drivers/video/fbdev/savage/savagefb_driver.c| 9 +- > > drivers/video/fbdev/sh_mobile_lcdcfb.c | 132 +--- > > drivers/video/fbdev/sh_mobile_lcdcfb.h | 5 - > > include/linux/console_struct.h | 5 +- > > include/linux/fb.h | 45 +-- > > include/linux/fbcon.h | 30 ++ > > 27 files changed, 396 insertions(+), 782 deletions(-) > > -- Lee Jones [李琼斯] Linaro Services Technical Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 00/33] fbcon notifier begone v3!
On Tue, 11 Jun 2019, Daniel Thompson wrote: > On Fri, Jun 07, 2019 at 12:07:55PM +0200, Bartlomiej Zolnierkiewicz wrote: > > On 6/6/19 9:38 AM, Daniel Vetter wrote: > > > > >> - Hash out actual merge plan. > > > > > > I'd like to stuff this into drm.git somehow, I guess topic branch works > > > too. > > > > I would like to have topic branch for this patchset. > > From a backlight perspective its Lee Jones who hoovers up the patches > and worries about hiding merge conflicts from Linus. > > I'll let him follow up if needed but I suspect he'd like an immutable > branch to work from also. Yes please. Happy to either create one, or receive one. -- Lee Jones [李琼斯] Linaro Services Technical Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [GIT PULL] Immutable branch between MFD and DRM/i915, Media and Platform due for the v4.19 merge window
Enjoy! The following changes since commit ce397d215ccd07b8ae3f71db689aedb85d56ab40: Linux 4.18-rc1 (2018-06-17 08:04:49 +0900) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd.git ib-mfd-i915-media-platform-v4.19 for you to fetch changes up to cd70de2d356ee692477276bd5d6bc88c71a48733: media: platform: Add ChromeOS EC CEC driver (2018-07-13 08:44:46 +0100) Immutable branch between MFD and DRM/i915, Media and Platform due for the v4.19 merge window Neil Armstrong (6): media: cec-notifier: Get notifier by device and connector name drm/i915: hdmi: add CEC notifier to intel_hdmi mfd: cros-ec: Increase maximum mkbp event size mfd: cros-ec: Introduce CEC commands and events definitions. mfd: cros_ec_dev: Add CEC sub-device registration media: platform: Add ChromeOS EC CEC driver drivers/gpu/drm/i915/Kconfig | 1 + drivers/gpu/drm/i915/intel_display.h | 24 ++ drivers/gpu/drm/i915/intel_drv.h | 2 + drivers/gpu/drm/i915/intel_hdmi.c| 13 + drivers/media/cec/cec-notifier.c | 11 +- drivers/media/platform/Kconfig | 11 + drivers/media/platform/Makefile | 2 + drivers/media/platform/cros-ec-cec/Makefile | 1 + drivers/media/platform/cros-ec-cec/cros-ec-cec.c | 347 +++ drivers/mfd/cros_ec_dev.c| 16 ++ drivers/platform/chrome/cros_ec_proto.c | 40 ++- include/linux/mfd/cros_ec.h | 2 +- include/linux/mfd/cros_ec_commands.h | 97 +++ include/media/cec-notifier.h | 27 +- 14 files changed, 578 insertions(+), 16 deletions(-) create mode 100644 drivers/media/platform/cros-ec-cec/Makefile create mode 100644 drivers/media/platform/cros-ec-cec/cros-ec-cec.c -- Lee Jones [李琼斯] Linaro Services Technical Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v8 3/6] mfd: cros-ec: Increase maximum mkbp event size
On Wed, 04 Jul 2018, Neil Armstrong wrote: > Having a 16 byte mkbp event size makes it possible to send CEC > messages from the EC to the AP directly inside the mkbp event > instead of first doing a notification and then a read. > > Signed-off-by: Stefan Adolfsson > Signed-off-by: Neil Armstrong > Tested-by: Enric Balletbo i Serra > Acked-by: Hans Verkuil > --- > drivers/platform/chrome/cros_ec_proto.c | 40 > + > include/linux/mfd/cros_ec.h | 2 +- > include/linux/mfd/cros_ec_commands.h| 16 + > 3 files changed, 48 insertions(+), 10 deletions(-) For my own reference: Acked-for-MFD-by: Lee Jones -- Lee Jones [李琼斯] Linaro Services Technical Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v8 0/6] Add ChromeOS EC CEC Support
On Wed, 04 Jul 2018, Neil Armstrong wrote: > Hi All, > > The new Google "Fizz" Intel-based ChromeOS device is gaining CEC support > through it's Embedded Controller, to enable the Linux CEC Core to communicate > with it and get the CEC Physical Address from the correct HDMI Connector, the > following must be added/changed: > - Add the CEC sub-device registration in the ChromeOS EC MFD Driver > - Add the CEC related commands and events definitions into the EC MFD driver > - Add a way to get a CEC notifier with it's (optional) connector name > - Add the CEC notifier to the i915 HDMI driver > - Add the proper ChromeOS EC CEC Driver > > The CEC notifier with the connector name is the tricky point, since even on > Device-Tree platforms, there is no way to distinguish between multiple HDMI > connectors from the same DRM driver. The solution I implemented is pretty > simple and only adds an optional connector name to eventually distinguish > an HDMI connector notifier from another if they share the same device. > > Feel free to comment this patchset ! > > Changes since v7: > - rebased on v4.18-rc1 > - Fixed whitespace issues on patch 3 > - Added Lee's tags > > Changes since v6: > - Added stable identifier comment in intel_display.h > - Renamed to cec_notifier in intel_hdmi.c/intel_drv.h > - Added Acked-by/Reviewed-By tags > > Changes since v5: > - Small fixups on include/linux/mfd/cros_ec_commands.h > - Fixed on cros-ec-cec driver accordingly > - Added Reviewed-By tags > > Changes since v4: > - Split patch 3 to move the mkbp event size change into a separate patch > > Changes since v3 (incorrectly reported as v2): > - Renamed "Chrome OS" to "ChromeOS" > - Updated cros_ec_commands.h new structs definitions to kernel doc format > - Added Reviewed-By tags > > Changes since v2: > - Add i915 port_identifier() and use this stable name as cec_notifier conn > name > - Fixed and cleaned up the CEC commands and events handling > - Rebased the CEC sub-device registration on top of Enric's serie > - Fixed comments typo on cec driver > - Protected the DMI match only with PCI and DMI Kconfigs > > Changes since v1: > - Added cec_notifier_put to intel_hdmi > - Fixed all small reported issues on the EC CEC driver > - Moved the cec_notifier_get out of the #if .. #else .. #endif > > Changes since RFC: > - Moved CEC sub-device registration after CEC commands and events > definitions patch > - Removed get_notifier_get_byname > - Added CEC_CORE select into i915 Kconfig > - Removed CEC driver fallback if notifier is not configured on HW, added > explicit warn > - Fixed CEC core return type on error > - Moved to cros-ec-cec media platform directory > - Use bus_find_device() to find the pci i915 device instead of > get_notifier_get_byname() > - Fix Logical Address setup > - Added comment about HW support > - Removed memset of msg structures > > Neil Armstrong (6): > media: cec-notifier: Get notifier by device and connector name > drm/i915: hdmi: add CEC notifier to intel_hdmi > mfd: cros-ec: Increase maximum mkbp event size > mfd: cros-ec: Introduce CEC commands and events definitions. > mfd: cros_ec_dev: Add CEC sub-device registration > media: platform: Add ChromeOS EC CEC driver > > drivers/gpu/drm/i915/Kconfig | 1 + > drivers/gpu/drm/i915/intel_display.h | 24 ++ > drivers/gpu/drm/i915/intel_drv.h | 2 + > drivers/gpu/drm/i915/intel_hdmi.c| 13 + > drivers/media/cec/cec-notifier.c | 11 +- > drivers/media/platform/Kconfig | 11 + > drivers/media/platform/Makefile | 2 + > drivers/media/platform/cros-ec-cec/Makefile | 1 + > drivers/media/platform/cros-ec-cec/cros-ec-cec.c | 347 > +++ > drivers/mfd/cros_ec_dev.c| 16 ++ > drivers/platform/chrome/cros_ec_proto.c | 40 ++- > include/linux/mfd/cros_ec.h | 2 +- > include/linux/mfd/cros_ec_commands.h | 97 +++ > include/media/cec-notifier.h | 27 +- > 14 files changed, 578 insertions(+), 16 deletions(-) > create mode 100644 drivers/media/platform/cros-ec-cec/Makefile > create mode 100644 drivers/media/platform/cros-ec-cec/cros-ec-cec.c How would you like to handle this set? -- Lee Jones [李琼斯] Linaro Services Technical Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v7 5/6] mfd: cros_ec_dev: Add CEC sub-device registration
On Wed, 04 Jul 2018, Neil Armstrong wrote: > Hi Lee, > > On 04/07/2018 09:47, Lee Jones wrote: > > On Fri, 01 Jun 2018, Neil Armstrong wrote: > > > >> The EC can expose a CEC bus, thus add the cros-ec-cec MFD sub-device > >> when the CEC feature bit is present. > >> > >> Signed-off-by: Neil Armstrong > >> Reviewed-by: Enric Balletbo i Serra > >> Acked-by: Hans Verkuil > >> --- > >> drivers/mfd/cros_ec_dev.c | 16 > >> 1 file changed, 16 insertions(+) > > > > For my own reference: > > Acked-for-MFD-by: Lee Jones > > > > Should I keep these Acked-for-MFD-by for the v8 ? Yes please. -- Lee Jones [李琼斯] Linaro Services Technical Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v7 5/6] mfd: cros_ec_dev: Add CEC sub-device registration
On Fri, 01 Jun 2018, Neil Armstrong wrote: > The EC can expose a CEC bus, thus add the cros-ec-cec MFD sub-device > when the CEC feature bit is present. > > Signed-off-by: Neil Armstrong > Reviewed-by: Enric Balletbo i Serra > Acked-by: Hans Verkuil > --- > drivers/mfd/cros_ec_dev.c | 16 > 1 file changed, 16 insertions(+) For my own reference: Acked-for-MFD-by: Lee Jones -- Lee Jones [李琼斯] Linaro Services Technical Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v7 3/6] mfd: cros-ec: Increase maximum mkbp event size
On Mon, 18 Jun 2018, Neil Armstrong wrote:
> Hi Lee,
>
> On 18/06/2018 09:44, Lee Jones wrote:
> > On Fri, 01 Jun 2018, Neil Armstrong wrote:
> >
> >> Having a 16 byte mkbp event size makes it possible to send CEC
> >> messages from the EC to the AP directly inside the mkbp event
> >> instead of first doing a notification and then a read.
> >>
> >> Signed-off-by: Stefan Adolfsson
> >> Signed-off-by: Neil Armstrong
> >> Tested-by: Enric Balletbo i Serra
> >> ---
> >> drivers/platform/chrome/cros_ec_proto.c | 40
> >> +
> >> include/linux/mfd/cros_ec.h | 2 +-
> >> include/linux/mfd/cros_ec_commands.h| 19
> >> 3 files changed, 51 insertions(+), 10 deletions(-)
> >>
> >> diff --git a/drivers/platform/chrome/cros_ec_proto.c
> >> b/drivers/platform/chrome/cros_ec_proto.c
> >> index e7bbdf9..c4f6c44 100644
> >> --- a/drivers/platform/chrome/cros_ec_proto.c
> >> +++ b/drivers/platform/chrome/cros_ec_proto.c
> >> @@ -504,10 +504,31 @@ int cros_ec_cmd_xfer_status(struct cros_ec_device
> >> *ec_dev,
> >> }
> >> EXPORT_SYMBOL(cros_ec_cmd_xfer_status);
> >>
> >> +static int get_next_event_xfer(struct cros_ec_device *ec_dev,
> >> + struct cros_ec_command *msg,
> >> + int version, uint32_t size)
> >> +{
> >> + int ret;
> >> +
> >> + msg->version = version;
> >> + msg->command = EC_CMD_GET_NEXT_EVENT;
> >> + msg->insize = size;
> >> + msg->outsize = 0;
> >> +
> >> + ret = cros_ec_cmd_xfer(ec_dev, msg);
> >> + if (ret > 0) {
> >> + ec_dev->event_size = ret - 1;
> >> + memcpy(&ec_dev->event_data, msg->data, ec_dev->event_size);
> >> + }
> >> +
> >> + return ret;
> >> +}
> >> +
> >> static int get_next_event(struct cros_ec_device *ec_dev)
> >> {
> >>u8 buffer[sizeof(struct cros_ec_command) + sizeof(ec_dev->event_data)];
> >>struct cros_ec_command *msg = (struct cros_ec_command *)&buffer;
> >> + static int cmd_version = 1;
> >>int ret;
> >>
> >>if (ec_dev->suspended) {
> >> @@ -515,18 +536,19 @@ static int get_next_event(struct cros_ec_device
> >> *ec_dev)
> >>return -EHOSTDOWN;
> >>}
> >>
> >> - msg->version = 0;
> >> - msg->command = EC_CMD_GET_NEXT_EVENT;
> >> - msg->insize = sizeof(ec_dev->event_data);
> >> - msg->outsize = 0;
> >> + if (cmd_version == 1) {
> >> + ret = get_next_event_xfer(ec_dev, msg, cmd_version,
> >> + sizeof(struct ec_response_get_next_event_v1));
> >> + if (ret < 0 || msg->result != EC_RES_INVALID_VERSION)
> >> + return ret;
> >>
> >> - ret = cros_ec_cmd_xfer(ec_dev, msg);
> >> - if (ret > 0) {
> >> - ec_dev->event_size = ret - 1;
> >> - memcpy(&ec_dev->event_data, msg->data,
> >> - sizeof(ec_dev->event_data));
> >> + /* Fallback to version 0 for future send attempts */
> >> + cmd_version = 0;
> >>}
> >>
> >> + ret = get_next_event_xfer(ec_dev, msg, cmd_version,
> >> +sizeof(struct ec_response_get_next_event));
> >> +
> >>return ret;
> >> }
> >>
> >> diff --git a/include/linux/mfd/cros_ec.h b/include/linux/mfd/cros_ec.h
> >> index f36125e..32caef3 100644
> >> --- a/include/linux/mfd/cros_ec.h
> >> +++ b/include/linux/mfd/cros_ec.h
> >> @@ -147,7 +147,7 @@ struct cros_ec_device {
> >>bool mkbp_event_supported;
> >>struct blocking_notifier_head event_notifier;
> >>
> >> - struct ec_response_get_next_event event_data;
> >> + struct ec_response_get_next_event_v1 event_data;
> >>int event_size;
> >>u32 host_event_wake_mask;
> >> };
> >> diff --git a/include/linux/mfd/cros_ec_commands.h
> >> b/include/linux/mfd/cros_ec_commands.h
> >> index f2edd99..cc0768e 100644
> >> --- a/include/linux/mfd/cros_ec_commands.h
> >> +++ b/include/linux/mfd/cros_ec_commands.h
> >> @@ -2093,12 +2093,31 @@ union ec_response_get_next_data {
> >>u
Re: [Intel-gfx] [PATCH v7 4/6] mfd: cros-ec: Introduce CEC commands and events definitions.
On Fri, 01 Jun 2018, Neil Armstrong wrote: > The EC can expose a CEC bus, this patch adds the CEC related definitions > needed by the cros-ec-cec driver. > > Signed-off-by: Neil Armstrong > Tested-by: Enric Balletbo i Serra > Reviewed-by: Hans Verkuil > --- > include/linux/mfd/cros_ec_commands.h | 81 > > 1 file changed, 81 insertions(+) For my own reference: Acked-for-MFD-by: Lee Jones -- Lee Jones [李琼斯] Linaro Services Technical Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v7 3/6] mfd: cros-ec: Increase maximum mkbp event size
On Fri, 01 Jun 2018, Neil Armstrong wrote:
> Having a 16 byte mkbp event size makes it possible to send CEC
> messages from the EC to the AP directly inside the mkbp event
> instead of first doing a notification and then a read.
>
> Signed-off-by: Stefan Adolfsson
> Signed-off-by: Neil Armstrong
> Tested-by: Enric Balletbo i Serra
> ---
> drivers/platform/chrome/cros_ec_proto.c | 40
> +
> include/linux/mfd/cros_ec.h | 2 +-
> include/linux/mfd/cros_ec_commands.h| 19
> 3 files changed, 51 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/platform/chrome/cros_ec_proto.c
> b/drivers/platform/chrome/cros_ec_proto.c
> index e7bbdf9..c4f6c44 100644
> --- a/drivers/platform/chrome/cros_ec_proto.c
> +++ b/drivers/platform/chrome/cros_ec_proto.c
> @@ -504,10 +504,31 @@ int cros_ec_cmd_xfer_status(struct cros_ec_device
> *ec_dev,
> }
> EXPORT_SYMBOL(cros_ec_cmd_xfer_status);
>
> +static int get_next_event_xfer(struct cros_ec_device *ec_dev,
> +struct cros_ec_command *msg,
> +int version, uint32_t size)
> +{
> + int ret;
> +
> + msg->version = version;
> + msg->command = EC_CMD_GET_NEXT_EVENT;
> + msg->insize = size;
> + msg->outsize = 0;
> +
> + ret = cros_ec_cmd_xfer(ec_dev, msg);
> + if (ret > 0) {
> + ec_dev->event_size = ret - 1;
> + memcpy(&ec_dev->event_data, msg->data, ec_dev->event_size);
> + }
> +
> + return ret;
> +}
> +
> static int get_next_event(struct cros_ec_device *ec_dev)
> {
> u8 buffer[sizeof(struct cros_ec_command) + sizeof(ec_dev->event_data)];
> struct cros_ec_command *msg = (struct cros_ec_command *)&buffer;
> + static int cmd_version = 1;
> int ret;
>
> if (ec_dev->suspended) {
> @@ -515,18 +536,19 @@ static int get_next_event(struct cros_ec_device *ec_dev)
> return -EHOSTDOWN;
> }
>
> - msg->version = 0;
> - msg->command = EC_CMD_GET_NEXT_EVENT;
> - msg->insize = sizeof(ec_dev->event_data);
> - msg->outsize = 0;
> + if (cmd_version == 1) {
> + ret = get_next_event_xfer(ec_dev, msg, cmd_version,
> + sizeof(struct ec_response_get_next_event_v1));
> + if (ret < 0 || msg->result != EC_RES_INVALID_VERSION)
> + return ret;
>
> - ret = cros_ec_cmd_xfer(ec_dev, msg);
> - if (ret > 0) {
> - ec_dev->event_size = ret - 1;
> - memcpy(&ec_dev->event_data, msg->data,
> -sizeof(ec_dev->event_data));
> + /* Fallback to version 0 for future send attempts */
> + cmd_version = 0;
> }
>
> + ret = get_next_event_xfer(ec_dev, msg, cmd_version,
> + sizeof(struct ec_response_get_next_event));
> +
> return ret;
> }
>
> diff --git a/include/linux/mfd/cros_ec.h b/include/linux/mfd/cros_ec.h
> index f36125e..32caef3 100644
> --- a/include/linux/mfd/cros_ec.h
> +++ b/include/linux/mfd/cros_ec.h
> @@ -147,7 +147,7 @@ struct cros_ec_device {
> bool mkbp_event_supported;
> struct blocking_notifier_head event_notifier;
>
> - struct ec_response_get_next_event event_data;
> + struct ec_response_get_next_event_v1 event_data;
> int event_size;
> u32 host_event_wake_mask;
> };
> diff --git a/include/linux/mfd/cros_ec_commands.h
> b/include/linux/mfd/cros_ec_commands.h
> index f2edd99..cc0768e 100644
> --- a/include/linux/mfd/cros_ec_commands.h
> +++ b/include/linux/mfd/cros_ec_commands.h
> @@ -2093,12 +2093,31 @@ union ec_response_get_next_data {
> uint32_t sysrq;
> } __packed;
>
> +union ec_response_get_next_data_v1 {
> + uint8_t key_matrix[16];
> +
> + /* Unaligned */
That's funny!
> + uint32_t host_event;
> +
> + uint32_t buttons;
> + uint32_t switches;
> + uint32_t sysrq;
> + uint32_t cec_events;
> + uint8_tcec_message[16];
Since there are some whitespace alignment issues in here.
> +} __packed;
How come these guys have kerneldoc headers?
> struct ec_response_get_next_event {
> uint8_t event_type;
> /* Followed by event data if any */
> union ec_response_get_next_data data;
> } __packed;
>
> +struct ec_response_get_next_event_v1 {
> + uint8_t event_type;
> + /* Followed by event data if any */
> + union ec_response_get_next_data_v1 data;
> +} __packed;
> +
> /* Bit indices for buttons and switches.*/
> /* Buttons */
> #define EC_MKBP_POWER_BUTTON 0
--
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v7 0/6] Add ChromeOS EC CEC Support
On Fri, 08 Jun 2018, Hans Verkuil wrote: > On 08/06/18 10:17, Neil Armstrong wrote: > > On 08/06/2018 09:53, Hans Verkuil wrote: > >> On 06/01/2018 10:19 AM, Neil Armstrong wrote: > >>> Hi All, > >>> > >>> The new Google "Fizz" Intel-based ChromeOS device is gaining CEC support > >>> through it's Embedded Controller, to enable the Linux CEC Core to > >>> communicate > >>> with it and get the CEC Physical Address from the correct HDMI Connector, > >>> the > >>> following must be added/changed: > >>> - Add the CEC sub-device registration in the ChromeOS EC MFD Driver > >>> - Add the CEC related commands and events definitions into the EC MFD > >>> driver > >>> - Add a way to get a CEC notifier with it's (optional) connector name > >>> - Add the CEC notifier to the i915 HDMI driver > >>> - Add the proper ChromeOS EC CEC Driver > >>> > >>> The CEC notifier with the connector name is the tricky point, since even > >>> on > >>> Device-Tree platforms, there is no way to distinguish between multiple > >>> HDMI > >>> connectors from the same DRM driver. The solution I implemented is pretty > >>> simple and only adds an optional connector name to eventually distinguish > >>> an HDMI connector notifier from another if they share the same device. > >> > >> This looks good to me, which brings me to the next question: how to merge > >> this? > >> > >> It touches on three subsystems (media, drm, mfd), so that makes this > >> tricky. > >> > >> I think there are two options: either the whole series goes through the > >> media tree, or patches 1+2 go through drm and 3-6 through media. If there > >> is a high chance of conflicts in the mfd code, then it is also an option to > >> have patches 3-6 go through the mfd subsystem. > > > > I think patches 3-6 should go in the mfd tree, Lee is used to handle this, > > then I think the rest could go in the media tree. > > > > Lee, do you think it would be possible to have an immutable branch with > > patches 3-6 ? > > > > Could we have an immutable branch from media tree with patch 1 to be merged > > in > > the i915 tree for patch 2 ? > > > > Or patch 1+2 could me merged into the i915 tree and generate an immutable > > branch > > I think patches 1+2 can just go to the i915 tree. The i915 driver changes > often, > so going through that tree makes sense. The cec-notifier code is unlikely to > change, > and I am fine with that patch going through i915. > > > for media to merge the mfd branch + patch 7 ? > > Patch 7? I only count 6? > > If 1+2 go through drm and 3-6 go through mfd, then media isn't affected at > all. > There is chance of a conflict when this is eventually pushed to mainline for > the media Kconfig, but that's all. What are the *build* dependencies within the set? I'd be happy to send out a pull-request for either all of the patches, or just the MFD changes once I've had chance to review them. -- Lee Jones [李琼斯] Linaro Services Technical Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH V3 24/29] backlight: deprecate pci_get_bus_and_slot()
On Mon, 27 Nov 2017, Jingoo Han wrote:
> On Monday, November 27, 2017 11:58 AM, Sinan Kaya wrote:
> >
> > pci_get_bus_and_slot() is restrictive such that it assumes domain=0 as
> > where a PCI device is present. This restricts the device drivers to be
> > reused for other domain numbers.
>
> I think that this will be useful. I introduced multi domains into
> ARM-based PCIe driver. (e.g. domain 0, and domain 1) So, APIs to choose
> domain will be used later.
>
> >
> > Getting ready to remove pci_get_bus_and_slot() function in favor of
> > pci_get_domain_bus_and_slot().
> >
> > Hard-coding the domain as 0.
> >
> > Acked-by: Daniel Thompson
> > Signed-off-by: Sinan Kaya
>
> Acked-by: Jingoo Han
I can't apply this.
It looks like I was missing from the list of addressees.
Please resend v3 with all the Acks you've acquired.
> > ---
> > drivers/video/backlight/apple_bl.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/video/backlight/apple_bl.c
> > b/drivers/video/backlight/apple_bl.c
> > index d843296..6a34ab9 100644
> > --- a/drivers/video/backlight/apple_bl.c
> > +++ b/drivers/video/backlight/apple_bl.c
> > @@ -143,7 +143,7 @@ static int apple_bl_add(struct acpi_device *dev)
> > struct pci_dev *host;
> > int intensity;
> >
> > - host = pci_get_bus_and_slot(0, 0);
> > + host = pci_get_domain_bus_and_slot(0, 0, 0);
> >
> > if (!host) {
> > pr_err("unable to find PCI host\n");
>
>
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] mfd: intel_soc_pmic_core: Terminate panel control GPIO lookup table correctly
On Fri, 22 Apr 2016, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> GPIO lookup tables are supposed to be zero terminated. Let's do that
> and avoid accidentally walking off the end.
>
> Cc: Shobhit Kumar
> Cc: Samuel Ortiz
> Cc: Linus Walleij
> Cc: Alexandre Courbot
> Cc: Thierry Reding
> Cc: Lee Jones
> Cc: sta...@vger.kernel.org
> Fixes: 61dd2ca2d44e ("mfd: intel_soc_pmic_core: Add lookup table for Panel
> Control as GPIO signal")
> Signed-off-by: Ville Syrjälä
> ---
> drivers/mfd/intel_soc_pmic_core.c | 1 +
> 1 file changed, 1 insertion(+)
Applied with Linus' and Daniel's Ack.
> diff --git a/drivers/mfd/intel_soc_pmic_core.c
> b/drivers/mfd/intel_soc_pmic_core.c
> index d9e15cf7c6c8..12d6ebb4ae5d 100644
> --- a/drivers/mfd/intel_soc_pmic_core.c
> +++ b/drivers/mfd/intel_soc_pmic_core.c
> @@ -35,6 +35,7 @@ static struct gpiod_lookup_table panel_gpio_table = {
> .table = {
> /* Panel EN/DISABLE */
> GPIO_LOOKUP("gpio_crystalcove", 94, "panel", GPIO_ACTIVE_HIGH),
> + { },
> },
> };
>
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] mfd: intel_soc_pmic_core: Terminate panel control GPIO lookup table correctly
On Mon, 09 May 2016, Daniel Vetter wrote:
> On Wed, May 04, 2016 at 08:32:17AM +0100, Lee Jones wrote:
> > On Mon, 02 May 2016, Daniel Vetter wrote:
> >
> > > On Fri, Apr 29, 2016 at 11:31:44AM +0200, Linus Walleij wrote:
> > > > On Fri, Apr 22, 2016 at 9:38 PM, wrote:
> > > >
> > > > > From: Ville Syrjälä
> > > > >
> > > > > GPIO lookup tables are supposed to be zero terminated. Let's do that
> > > > > and avoid accidentally walking off the end.
> > > > >
> > > > > Cc: Shobhit Kumar
> > > > > Cc: Samuel Ortiz
> > > > > Cc: Linus Walleij
> > > > > Cc: Alexandre Courbot
> > > > > Cc: Thierry Reding
> > > > > Cc: Lee Jones
> > > > > Cc: sta...@vger.kernel.org
> > > > > Fixes: 61dd2ca2d44e ("mfd: intel_soc_pmic_core: Add lookup table for
> > > > > Panel Control as GPIO signal")
> > > > > Signed-off-by: Ville Syrjälä
> > > >
> > > > Acked-by: Linus Walleij
> > >
> > > Applied to drm-intel trees, thanks for patch, reviews&acks.
> >
> > Do what now? How can you apply a patch for a subsystem you don't have
> > responsibility for? This is bound to cause merge conflicts.
>
> Oh crap, I thought Linus' ack was for the mfd stuff and didn't bother
> double-checking with MAINTAINTERS. Should I throw it out again and you'll
> pick it up, or ok as such?
Yes please.
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] mfd: intel_soc_pmic_core: Terminate panel control GPIO lookup table correctly
On Mon, 02 May 2016, Daniel Vetter wrote:
> On Fri, Apr 29, 2016 at 11:31:44AM +0200, Linus Walleij wrote:
> > On Fri, Apr 22, 2016 at 9:38 PM, wrote:
> >
> > > From: Ville Syrjälä
> > >
> > > GPIO lookup tables are supposed to be zero terminated. Let's do that
> > > and avoid accidentally walking off the end.
> > >
> > > Cc: Shobhit Kumar
> > > Cc: Samuel Ortiz
> > > Cc: Linus Walleij
> > > Cc: Alexandre Courbot
> > > Cc: Thierry Reding
> > > Cc: Lee Jones
> > > Cc: sta...@vger.kernel.org
> > > Fixes: 61dd2ca2d44e ("mfd: intel_soc_pmic_core: Add lookup table for
> > > Panel Control as GPIO signal")
> > > Signed-off-by: Ville Syrjälä
> >
> > Acked-by: Linus Walleij
>
> Applied to drm-intel trees, thanks for patch, reviews&acks.
Do what now? How can you apply a patch for a subsystem you don't have
responsibility for? This is bound to cause merge conflicts.
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v5 03/46] backlight: lm3630a_bl: stop messing with the pwm->period field
On Wed, 13 Apr 2016, Lee Jones wrote: > On Tue, 12 Apr 2016, Thierry Reding wrote: > > > On Tue, Apr 12, 2016 at 03:16:13PM +0100, Lee Jones wrote: > > > On Tue, 12 Apr 2016, Thierry Reding wrote: > > > > > > > On Wed, Mar 30, 2016 at 10:03:26PM +0200, Boris Brezillon wrote: > > > > > pwm->period field is not supposed to be changed by PWM users. The only > > > > > ones authorized to change it are the PWM core and PWM drivers. > > > > > > > > > > Signed-off-by: Boris Brezillon > > > > > --- > > > > > drivers/video/backlight/lm3630a_bl.c | 3 +-- > > > > > 1 file changed, 1 insertion(+), 2 deletions(-) > > > > > > > > Applied, thanks. > > > > > > Applied? > > > > You didn't specifically Ack this one, but I presumed that since the > > change is essentially the same as for pwm-backlight, and this is another > > prerequisite for the remainder of the series it should go in through the > > PWM tree as well. > > If you're taking Backlight patches through a !Backlight tree, you're > going to have to send out a pull-request. There are no conflicts > currently, so I won't use it right away, but I need it in my arsenal > if they do occur. ... also, don't forget to change the subject line to make the rest of the patches in Backlight. The subject description needs to start with an uppercase char. -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v5 03/46] backlight: lm3630a_bl: stop messing with the pwm->period field
On Tue, 12 Apr 2016, Thierry Reding wrote: > On Tue, Apr 12, 2016 at 03:16:13PM +0100, Lee Jones wrote: > > On Tue, 12 Apr 2016, Thierry Reding wrote: > > > > > On Wed, Mar 30, 2016 at 10:03:26PM +0200, Boris Brezillon wrote: > > > > pwm->period field is not supposed to be changed by PWM users. The only > > > > ones authorized to change it are the PWM core and PWM drivers. > > > > > > > > Signed-off-by: Boris Brezillon > > > > --- > > > > drivers/video/backlight/lm3630a_bl.c | 3 +-- > > > > 1 file changed, 1 insertion(+), 2 deletions(-) > > > > > > Applied, thanks. > > > > Applied? > > You didn't specifically Ack this one, but I presumed that since the > change is essentially the same as for pwm-backlight, and this is another > prerequisite for the remainder of the series it should go in through the > PWM tree as well. If you're taking Backlight patches through a !Backlight tree, you're going to have to send out a pull-request. There are no conflicts currently, so I won't use it right away, but I need it in my arsenal if they do occur. -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v5 02/46] backlight: pwm_bl: remove useless call to pwm_set_period()
On Tue, 12 Apr 2016, Thierry Reding wrote: > On Wed, Mar 30, 2016 at 10:03:25PM +0200, Boris Brezillon wrote: > > The PWM period will be set when calling pwm_config. Remove this useless > > call to pwm_set_period(), which might mess up with the internal PWM state. > > > > Signed-off-by: Boris Brezillon > > Acked-by: Lee Jones > > --- > > drivers/video/backlight/pwm_bl.c | 4 +--- > > 1 file changed, 1 insertion(+), 3 deletions(-) > > Applied, thanks. Applied? -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v5 03/46] backlight: lm3630a_bl: stop messing with the pwm->period field
On Tue, 12 Apr 2016, Thierry Reding wrote: > On Wed, Mar 30, 2016 at 10:03:26PM +0200, Boris Brezillon wrote: > > pwm->period field is not supposed to be changed by PWM users. The only > > ones authorized to change it are the PWM core and PWM drivers. > > > > Signed-off-by: Boris Brezillon > > --- > > drivers/video/backlight/lm3630a_bl.c | 3 +-- > > 1 file changed, 1 insertion(+), 2 deletions(-) > > Applied, thanks. Applied? -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] mfd: Add GPIOLIB dependency if INTEL_SOC_PMIC is to be enabled
On Thu, 23 Jul 2015, Daniel Vetter wrote: > On Thu, Jul 23, 2015 at 9:38 AM, Lee Jones wrote: > > On Wed, 22 Jul 2015, Daniel Vetter wrote: > >> On Wed, Jul 22, 2015 at 02:01:44PM +0530, Shobhit Kumar wrote: > >> > This is needed as the CRC PMIC has support for Panel > >> > enable/diable as gpio which needs 'gpiod_add_lookup_table' > >> > and 'gpiod_remove_lookup_table' from gpiolib. This patch > >> > can be squashed with below commit in topic/crc-pmic branch > >> > > >> > commit 61dd2ca2d44e493b050adbbb75bc50db11c367dd > >> > Author: Shobhit Kumar > >> > Date: Fri Jun 26 14:32:05 2015 +0530 > >> > > >> > mfd: intel_soc_pmic_core: Add lookup table for Panel Control as GPIO > >> > signal > >> > > >> > On some Intel SoC platforms, the panel enable/disable signals > >> > are controlled by CRC PMIC. Add those control as a new GPIO in a > >> > lookup table for gpio-crystalcove chip during CRC driver load > >> > > >> > Cc: Lee Jones > >> > Cc: Linus Walleij > >> > Signed-off-by: Shobhit Kumar > >> > >> Applied, thanks. > > > > You can't just apply changes made to other subsystems willy-nilly. > > > > You should wait for an Ack, despite the triviality of the patch, even > > if it's just out of courtesy. > > Sorry about that, figured getting rid of the compile fail asap is > better. Should I revert it again and update the pull request? It's fine. Just please bear it in mind for the future. -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] mfd: Add GPIOLIB dependency if INTEL_SOC_PMIC is to be enabled
On Wed, 22 Jul 2015, Daniel Vetter wrote: > On Wed, Jul 22, 2015 at 02:01:44PM +0530, Shobhit Kumar wrote: > > This is needed as the CRC PMIC has support for Panel > > enable/diable as gpio which needs 'gpiod_add_lookup_table' > > and 'gpiod_remove_lookup_table' from gpiolib. This patch > > can be squashed with below commit in topic/crc-pmic branch > > > > commit 61dd2ca2d44e493b050adbbb75bc50db11c367dd > > Author: Shobhit Kumar > > Date: Fri Jun 26 14:32:05 2015 +0530 > > > > mfd: intel_soc_pmic_core: Add lookup table for Panel Control as GPIO > > signal > > > > On some Intel SoC platforms, the panel enable/disable signals > > are controlled by CRC PMIC. Add those control as a new GPIO in a > > lookup table for gpio-crystalcove chip during CRC driver load > > > > Cc: Lee Jones > > Cc: Linus Walleij > > Signed-off-by: Shobhit Kumar > > Applied, thanks. You can't just apply changes made to other subsystems willy-nilly. You should wait for an Ack, despite the triviality of the patch, even if it's just out of courtesy. > > --- > > drivers/mfd/Kconfig | 1 + > > 1 file changed, 1 insertion(+) > > > > diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig > > index 6538159..379a420 100644 > > --- a/drivers/mfd/Kconfig > > +++ b/drivers/mfd/Kconfig > > @@ -318,6 +318,7 @@ config LPC_SCH > > > > config INTEL_SOC_PMIC > > bool "Support for Intel Atom SoC PMIC" > > + depends on GPIOLIB > > depends on I2C=y > > select MFD_CORE > > select REGMAP_I2C > -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [v3 1/7] gpiolib: Add support for removing registered consumer lookup table
On Fri, 26 Jun 2015, Shobhit Kumar wrote:
> In case we unload and load a driver module again that is registering a
> lookup table, without this it will result in multiple entries. Provide
> an option to remove the lookup table on driver unload
>
> Cc: Samuel Ortiz
> Cc: Linus Walleij
> Cc: Alexandre Courbot
> Cc: Thierry Reding
> Reviewed-by: Alexandre Courbot
> Reviewed-by: Linus Walleij
> Tested-by: Ville Syrjälä
> Signed-off-by: Shobhit Kumar
> ---
> v2: Ccing maintainers
> v3: Correct the subject line (Lee jones)
Acked-by: Lee Jones
> drivers/gpio/gpiolib.c | 13 +
> include/linux/gpio/machine.h | 1 +
> 2 files changed, 14 insertions(+)
>
> diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
> index 957ede5..9d3ea4e 100644
> --- a/drivers/gpio/gpiolib.c
> +++ b/drivers/gpio/gpiolib.c
> @@ -1675,6 +1675,19 @@ void gpiod_add_lookup_table(struct gpiod_lookup_table
> *table)
> mutex_unlock(&gpio_lookup_lock);
> }
>
> +/**
> + * gpiod_remove_lookup_table() - unregister GPIO device consumers
> + * @table: table of consumers to unregister
> + */
> +void gpiod_remove_lookup_table(struct gpiod_lookup_table *table)
> +{
> + mutex_lock(&gpio_lookup_lock);
> +
> + list_del(&table->list);
> +
> + mutex_unlock(&gpio_lookup_lock);
> +}
> +
> static struct gpio_desc *of_find_gpio(struct device *dev, const char *con_id,
> unsigned int idx,
> enum gpio_lookup_flags *flags)
> diff --git a/include/linux/gpio/machine.h b/include/linux/gpio/machine.h
> index e270614..c0d712d 100644
> --- a/include/linux/gpio/machine.h
> +++ b/include/linux/gpio/machine.h
> @@ -57,5 +57,6 @@ struct gpiod_lookup_table {
> }
>
> void gpiod_add_lookup_table(struct gpiod_lookup_table *table);
> +void gpiod_remove_lookup_table(struct gpiod_lookup_table *table);
>
> #endif /* __LINUX_GPIO_MACHINE_H */
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [v2 4/7] mfd: intel_soc_pmic_core: ADD PWM lookup table for CRC PMIC based PWM
On Mon, 22 Jun 2015, Daniel Vetter wrote: > On Mon, Jun 22, 2015 at 04:33:22PM +0530, Varka Bhadram wrote: > > Hi Shobhit Kumar, > > > > On 06/22/2015 04:24 PM, Shobhit Kumar wrote: > > > > >On some BYT PLatform the PWM is controlled using CRC PMIC. Add a lookup > > >entry for the same to be used by the consumer (Intel GFX) > > > > > >v2: Remove the lookup table on driver unload (Thierry) > > > > > >v3: Correct the subject line (Lee jones) > > > > This part should only describe what this is about.. > > > > Don't put this patch change history over here. > > Include this change history after > > ... > > Signed-off-by: Author > > --- > > > > >CC: Samuel Ortiz > > >Cc: Linus Walleij > > >Cc: Alexandre Courbot > > >Cc: Thierry Reding > > >Acked-by: Lee Jones > > >Signed-off-by: Shobhit Kumar > > >--- > > > > Here you add this change history so that after applying this > > will not be the part of your commit description. > > > > This comment is applicable for all of your patches. > > It's honestly a per-maintainer thing and hard to tell who wants what ... > Personally I do want to include the patch changelog in the commit message. The patch change-log should go below the '---'. There are very few (weird ;) ) Maintainers who like to see them in the commit log. -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/8] gpiolib: Add support for removing registered consumer lookup table
On Tue, 05 May 2015, Daniel Vetter wrote:
> On Tue, May 05, 2015 at 11:45:05AM +0100, Lee Jones wrote:
> > This is not how we submit subsequent patch-sets.
>
> It is unfortunately how we handle patches on dri-devel&intel-gfx to be
> able to cope with massive mail load. If everyone who submits to intel-gfx
> would always resend the entire series for minor updates of som patches
> we'd completely drown in the resulting flood.
For one or two simple fix-ups in the set perhaps, but when submitting
the entire set it needs to be threaded as a separate block, rather
than seeing current and superseded patches inter-woven. This
submission is already a rat's nest and I'm struggling to see which
patches are which. I'm really not looking forward to v3 and v4!
Attaching one version to another is a good way to keep control if you
really are over-whelmed. For your use-case I would expect to see the
following, which is achieved using --in-reply-to:
[PATCH 0/2] Here is what I did...
[PATCH 1/2] Clean up and tests
[PATCH 2/2] Implementation
[PATCH v2 0/3] Here is a reroll
[PATCH v2 1/3] Clean up
[PATCH v2 2/3] New tests
[PATCH v2 3/3] Implementation
The version numbers also need to be present and aren't in this
re-submission.
> > Please submit them as a whole, seperately from the first submission
> > and with versioning information i.e. [PATCH v2 X/Y] Stuff ...
> >
> > > In case we unload and load a driver module again that is registering a
> > > lookup table, without this it will result in multiple entries. Provide
> > > an option to remove the lookup table on driver unload
> > >
> > > v2: Ccing maintainers
> > > v3: Correct the subject line (Lee jones)
> >
> > Change logs should go underneth the '---' and above the diffstat found
> > below.
>
> Again just style differences between subsystems, I generally want to have
> those above the ---.
For all commits? Then I'm guessing your Git history is all but
unreadable. In the kernel, unless the changelog holds valuable
historic information which influance key design decisions, we put the
patch changelog *below* the '---'.
Please read Documentation/SubmittingPatches:
"14) The canonical patch format
[...]
The "---" marker line serves the essential purpose of marking
for patch handling tools where the changelog message ends.
[...]
Other comments relevant only to the moment or the maintainer,
not suitable for the permanent changelog, should also go here.
A good example of such comments might be *"patch changelogs"*
which describe what has changed between the v1 and v2 version
of the patch."
> > > Cc: Samuel Ortiz
> > > Cc: Linus Walleij
> > > Cc: Alexandre Courbot
> > > Cc: Thierry Reding
> > > Reviewed-by: Alexandre Courbot
> > > Signed-off-by: Shobhit Kumar
> > > ---
> > > drivers/gpio/gpiolib.c | 13 +
> > > include/linux/gpio/machine.h | 1 +
> > > 2 files changed, 14 insertions(+)
> > >
> > > diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
> > > index 59eaa23..2420af9 100644
> > > --- a/drivers/gpio/gpiolib.c
> > > +++ b/drivers/gpio/gpiolib.c
> > > @@ -1658,6 +1658,19 @@ void gpiod_add_lookup_table(struct
> > > gpiod_lookup_table *table)
> > > mutex_unlock(&gpio_lookup_lock);
> > > }
> > >
> > > +/**
> > > + * gpiod_remove_lookup_table() - unregister GPIO device consumers
> > > + * @table: table of consumers to unregister
> > > + */
> > > +void gpiod_remove_lookup_table(struct gpiod_lookup_table *table)
> > > +{
> > > + mutex_lock(&gpio_lookup_lock);
> > > +
> > > + list_del(&table->list);
> > > +
> > > + mutex_unlock(&gpio_lookup_lock);
> > > +}
> > > +
> > > static struct gpio_desc *of_find_gpio(struct device *dev, const char
> > > *con_id,
> > > unsigned int idx,
> > > enum gpio_lookup_flags *flags)
> > > diff --git a/include/linux/gpio/machine.h b/include/linux/gpio/machine.h
> > > index e270614..c0d712d 100644
> > > --- a/include/linux/gpio/machine.h
> > > +++ b/include/linux/gpio/machine.h
> > > @@ -57,5 +57,6 @@ struct gpiod_lookup_table {
> > > }
> > >
> > > void gpiod_add_lookup_table(struct gpiod_lookup_table *table);
> > > +void gpiod_remove_lookup_table(struct gpiod_lookup_table *table);
> > >
> > > #endif /* __LINUX_GPIO_MACHINE_H */
> >
>
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/8] gpiolib: Add support for removing registered consumer lookup table
This is not how we submit subsequent patch-sets.
Please submit them as a whole, seperately from the first submission
and with versioning information i.e. [PATCH v2 X/Y] Stuff ...
> In case we unload and load a driver module again that is registering a
> lookup table, without this it will result in multiple entries. Provide
> an option to remove the lookup table on driver unload
>
> v2: Ccing maintainers
> v3: Correct the subject line (Lee jones)
Change logs should go underneth the '---' and above the diffstat found
below.
> Cc: Samuel Ortiz
> Cc: Linus Walleij
> Cc: Alexandre Courbot
> Cc: Thierry Reding
> Reviewed-by: Alexandre Courbot
> Signed-off-by: Shobhit Kumar
> ---
> drivers/gpio/gpiolib.c | 13 +
> include/linux/gpio/machine.h | 1 +
> 2 files changed, 14 insertions(+)
>
> diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
> index 59eaa23..2420af9 100644
> --- a/drivers/gpio/gpiolib.c
> +++ b/drivers/gpio/gpiolib.c
> @@ -1658,6 +1658,19 @@ void gpiod_add_lookup_table(struct gpiod_lookup_table
> *table)
> mutex_unlock(&gpio_lookup_lock);
> }
>
> +/**
> + * gpiod_remove_lookup_table() - unregister GPIO device consumers
> + * @table: table of consumers to unregister
> + */
> +void gpiod_remove_lookup_table(struct gpiod_lookup_table *table)
> +{
> + mutex_lock(&gpio_lookup_lock);
> +
> + list_del(&table->list);
> +
> + mutex_unlock(&gpio_lookup_lock);
> +}
> +
> static struct gpio_desc *of_find_gpio(struct device *dev, const char *con_id,
> unsigned int idx,
> enum gpio_lookup_flags *flags)
> diff --git a/include/linux/gpio/machine.h b/include/linux/gpio/machine.h
> index e270614..c0d712d 100644
> --- a/include/linux/gpio/machine.h
> +++ b/include/linux/gpio/machine.h
> @@ -57,5 +57,6 @@ struct gpiod_lookup_table {
> }
>
> void gpiod_add_lookup_table(struct gpiod_lookup_table *table);
> +void gpiod_remove_lookup_table(struct gpiod_lookup_table *table);
>
> #endif /* __LINUX_GPIO_MACHINE_H */
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 5/8] drivers/mfd: ADD PWM lookup table for CRC PMIC based PWM
On Tue, 05 May 2015, Shobhit Kumar wrote:
> On 04/29/2015 07:54 PM, Lee Jones wrote:
> > On Wed, 29 Apr 2015, Shobhit Kumar wrote:
> >
> >> On some BYT PLatform the PWM is controlled using CRC PMIC. Add a lookup
> >> entry for the same to be used by the consumer (Intel GFX)
> >>
> >> v2: Remove the lookup table on driver unload (Thierry)
> >>
> >> CC: Samuel Ortiz
> >> Cc: Linus Walleij
> >> Cc: Alexandre Courbot
> >> Cc: Thierry Reding
> >> Signed-off-by: Shobhit Kumar
> >> ---
> >> drivers/mfd/intel_soc_pmic_core.c | 12
> >> 1 file changed, 12 insertions(+)
> >
> > How do you expect this set to be managed?
>
> There are some dependencies on the look up table remove functionality in
> earlier patches, so I think 3/8 can go in only after 1/8. Similarly 5/8
> can go only after 2/8. Rest all can be independent.
Taking patches 'in order' is tough to coordinate and takes a very long
time. The best thing to do is have all of the patches taken in via a
single tree at the same time.
> > Acked-by: Lee Jones
> >
> >> diff --git a/drivers/mfd/intel_soc_pmic_core.c
> >> b/drivers/mfd/intel_soc_pmic_core.c
> >> index f3d918e..a00ddd9 100644
> >> --- a/drivers/mfd/intel_soc_pmic_core.c
> >> +++ b/drivers/mfd/intel_soc_pmic_core.c
> >> @@ -25,6 +25,7 @@
> >> #include
> >> #include
> >> #include
> >> +#include
> >> #include "intel_soc_pmic_core.h"
> >>
> >> /* Lookup table for the Panel Enable/Disable line as GPIO signals */
> >> @@ -37,6 +38,11 @@ static struct gpiod_lookup_table panel_gpio_table = {
> >>},
> >> };
> >>
> >> +/* PWM consumed by the Intel GFX */
> >> +static struct pwm_lookup crc_pwm_lookup[] = {
> >> + PWM_LOOKUP("crystal_cove_pwm", 0, ":00:02.0", "pwm_backlight", 0,
> >> PWM_POLARITY_NORMAL),
> >> +};
> >> +
> >> static int intel_soc_pmic_find_gpio_irq(struct device *dev)
> >> {
> >>struct gpio_desc *desc;
> >> @@ -99,6 +105,9 @@ static int intel_soc_pmic_i2c_probe(struct i2c_client
> >> *i2c,
> >>/* Add lookup table binding for Panel Control to the GPIO Chip */
> >>gpiod_add_lookup_table(&panel_gpio_table);
> >>
> >> + /* Add lookup table for crc-pwm */
> >> + pwm_add_table(crc_pwm_lookup, ARRAY_SIZE(crc_pwm_lookup));
> >> +
> >>ret = mfd_add_devices(dev, -1, config->cell_dev,
> >> config->n_cell_devs, NULL, 0,
> >> regmap_irq_get_domain(pmic->irq_chip_data));
> >> @@ -121,6 +130,9 @@ static int intel_soc_pmic_i2c_remove(struct i2c_client
> >> *i2c)
> >>/* Remove lookup table for Panel Control from the GPIO Chip */
> >>gpiod_remove_lookup_table(&panel_gpio_table);
> >>
> >> + /* remove crc-pwm lookup table */
> >> + pwm_remove_table(crc_pwm_lookup, ARRAY_SIZE(crc_pwm_lookup));
> >> +
> >>mfd_remove_devices(&i2c->dev);
> >>
> >>return 0;
> >
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 4/8] drivers/mfd: Add PWM cell device for Crystalcove PMIC
On Wed, 29 Apr 2015, Shobhit Kumar wrote:
> Needed for PWM control suuported by the PMIC
>
> CC: Samuel Ortiz
> Cc: Linus Walleij
> Cc: Alexandre Courbot
> Cc: Thierry Reding
> Signed-off-by: Shobhit Kumar
> ---
> drivers/mfd/intel_soc_pmic_crc.c | 3 +++
> 1 file changed, 3 insertions(+)
For my own reference:
Acked-by: Lee Jones
> diff --git a/drivers/mfd/intel_soc_pmic_crc.c
> b/drivers/mfd/intel_soc_pmic_crc.c
> index 4cc1b32..8839e25 100644
> --- a/drivers/mfd/intel_soc_pmic_crc.c
> +++ b/drivers/mfd/intel_soc_pmic_crc.c
> @@ -109,6 +109,9 @@ static struct mfd_cell crystal_cove_dev[] = {
> {
> .name = "crystal_cove_pmic",
> },
> + {
> + .name = "crystal_cove_pwm",
> + },
> };
>
> static const struct regmap_config crystal_cove_regmap_config = {
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/8] drivers/mfd: Add lookup table for Panel Control as GPIO signal
On Wed, 29 Apr 2015, Shobhit Kumar wrote:
> On some Intel SoC platforms, the panel enable/disable signals are
> controlled by CRC PMIC. Add those control as a new GPIO in a lookup
> table for gpio-crystalcove chip during CRC driver load
>
> v2: Make the lookup table static (Thierry)
> Remove the lookup table during driver remove (Thierry)
>
> CC: Samuel Ortiz
> Cc: Linus Walleij
> Cc: Alexandre Courbot
> Cc: Thierry Reding
> Signed-off-by: Shobhit Kumar
> ---
> drivers/mfd/intel_soc_pmic_core.c | 17 +
> 1 file changed, 17 insertions(+)
I have no idea what this stuff is, but it looks plausible.
For my own reference:
Acked-by: Lee Jones
> diff --git a/drivers/mfd/intel_soc_pmic_core.c
> b/drivers/mfd/intel_soc_pmic_core.c
> index 7b50b6b..f3d918e 100644
> --- a/drivers/mfd/intel_soc_pmic_core.c
> +++ b/drivers/mfd/intel_soc_pmic_core.c
> @@ -24,8 +24,19 @@
> #include
> #include
> #include
> +#include
> #include "intel_soc_pmic_core.h"
>
> +/* Lookup table for the Panel Enable/Disable line as GPIO signals */
> +static struct gpiod_lookup_table panel_gpio_table = {
> + /* Intel GFX is consumer */
> + .dev_id = ":00:02.0",
> + .table = {
> + /* Panel EN/DISABLE */
> + GPIO_LOOKUP("gpio_crystalcove", 94, "panel", GPIO_ACTIVE_HIGH),
> + },
> +};
> +
> static int intel_soc_pmic_find_gpio_irq(struct device *dev)
> {
> struct gpio_desc *desc;
> @@ -85,6 +96,9 @@ static int intel_soc_pmic_i2c_probe(struct i2c_client *i2c,
> if (ret)
> dev_warn(dev, "Can't enable IRQ as wake source: %d\n", ret);
>
> + /* Add lookup table binding for Panel Control to the GPIO Chip */
> + gpiod_add_lookup_table(&panel_gpio_table);
> +
> ret = mfd_add_devices(dev, -1, config->cell_dev,
> config->n_cell_devs, NULL, 0,
> regmap_irq_get_domain(pmic->irq_chip_data));
> @@ -104,6 +118,9 @@ static int intel_soc_pmic_i2c_remove(struct i2c_client
> *i2c)
>
> regmap_del_irq_chip(pmic->irq, pmic->irq_chip_data);
>
> + /* Remove lookup table for Panel Control from the GPIO Chip */
> + gpiod_remove_lookup_table(&panel_gpio_table);
> +
> mfd_remove_devices(&i2c->dev);
>
> return 0;
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 5/8] drivers/mfd: ADD PWM lookup table for CRC PMIC based PWM
On Wed, 29 Apr 2015, Shobhit Kumar wrote:
> On some BYT PLatform the PWM is controlled using CRC PMIC. Add a lookup
> entry for the same to be used by the consumer (Intel GFX)
>
> v2: Remove the lookup table on driver unload (Thierry)
>
> CC: Samuel Ortiz
> Cc: Linus Walleij
> Cc: Alexandre Courbot
> Cc: Thierry Reding
> Signed-off-by: Shobhit Kumar
> ---
> drivers/mfd/intel_soc_pmic_core.c | 12
> 1 file changed, 12 insertions(+)
How do you expect this set to be managed?
Acked-by: Lee Jones
> diff --git a/drivers/mfd/intel_soc_pmic_core.c
> b/drivers/mfd/intel_soc_pmic_core.c
> index f3d918e..a00ddd9 100644
> --- a/drivers/mfd/intel_soc_pmic_core.c
> +++ b/drivers/mfd/intel_soc_pmic_core.c
> @@ -25,6 +25,7 @@
> #include
> #include
> #include
> +#include
> #include "intel_soc_pmic_core.h"
>
> /* Lookup table for the Panel Enable/Disable line as GPIO signals */
> @@ -37,6 +38,11 @@ static struct gpiod_lookup_table panel_gpio_table = {
> },
> };
>
> +/* PWM consumed by the Intel GFX */
> +static struct pwm_lookup crc_pwm_lookup[] = {
> + PWM_LOOKUP("crystal_cove_pwm", 0, ":00:02.0", "pwm_backlight", 0,
> PWM_POLARITY_NORMAL),
> +};
> +
> static int intel_soc_pmic_find_gpio_irq(struct device *dev)
> {
> struct gpio_desc *desc;
> @@ -99,6 +105,9 @@ static int intel_soc_pmic_i2c_probe(struct i2c_client *i2c,
> /* Add lookup table binding for Panel Control to the GPIO Chip */
> gpiod_add_lookup_table(&panel_gpio_table);
>
> + /* Add lookup table for crc-pwm */
> + pwm_add_table(crc_pwm_lookup, ARRAY_SIZE(crc_pwm_lookup));
> +
> ret = mfd_add_devices(dev, -1, config->cell_dev,
> config->n_cell_devs, NULL, 0,
> regmap_irq_get_domain(pmic->irq_chip_data));
> @@ -121,6 +130,9 @@ static int intel_soc_pmic_i2c_remove(struct i2c_client
> *i2c)
> /* Remove lookup table for Panel Control from the GPIO Chip */
> gpiod_remove_lookup_table(&panel_gpio_table);
>
> + /* remove crc-pwm lookup table */
> + pwm_remove_table(crc_pwm_lookup, ARRAY_SIZE(crc_pwm_lookup));
> +
> mfd_remove_devices(&i2c->dev);
>
> return 0;
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/8] drivers/mfd: Add lookup table for Panel Control as GPIO signal
By the way, your subject lines are messed up.
They should adhere to the conventions laid down by the Maintainers.
`git log --oneline -- drivers/`
> On some Intel SoC platforms, the panel enable/disable signals are
> controlled by CRC PMIC. Add those control as a new GPIO in a lookup
> table for gpio-crystalcove chip during CRC driver load
>
> v2: Make the lookup table static (Thierry)
> Remove the lookup table during driver remove (Thierry)
>
> CC: Samuel Ortiz
> Cc: Linus Walleij
> Cc: Alexandre Courbot
> Cc: Thierry Reding
> Signed-off-by: Shobhit Kumar
> ---
> drivers/mfd/intel_soc_pmic_core.c | 17 +
> 1 file changed, 17 insertions(+)
>
> diff --git a/drivers/mfd/intel_soc_pmic_core.c
> b/drivers/mfd/intel_soc_pmic_core.c
> index 7b50b6b..f3d918e 100644
> --- a/drivers/mfd/intel_soc_pmic_core.c
> +++ b/drivers/mfd/intel_soc_pmic_core.c
> @@ -24,8 +24,19 @@
> #include
> #include
> #include
> +#include
> #include "intel_soc_pmic_core.h"
>
> +/* Lookup table for the Panel Enable/Disable line as GPIO signals */
> +static struct gpiod_lookup_table panel_gpio_table = {
> + /* Intel GFX is consumer */
> + .dev_id = ":00:02.0",
> + .table = {
> + /* Panel EN/DISABLE */
> + GPIO_LOOKUP("gpio_crystalcove", 94, "panel", GPIO_ACTIVE_HIGH),
> + },
> +};
> +
> static int intel_soc_pmic_find_gpio_irq(struct device *dev)
> {
> struct gpio_desc *desc;
> @@ -85,6 +96,9 @@ static int intel_soc_pmic_i2c_probe(struct i2c_client *i2c,
> if (ret)
> dev_warn(dev, "Can't enable IRQ as wake source: %d\n", ret);
>
> + /* Add lookup table binding for Panel Control to the GPIO Chip */
> + gpiod_add_lookup_table(&panel_gpio_table);
> +
> ret = mfd_add_devices(dev, -1, config->cell_dev,
> config->n_cell_devs, NULL, 0,
> regmap_irq_get_domain(pmic->irq_chip_data));
> @@ -104,6 +118,9 @@ static int intel_soc_pmic_i2c_remove(struct i2c_client
> *i2c)
>
> regmap_del_irq_chip(pmic->irq, pmic->irq_chip_data);
>
> + /* Remove lookup table for Panel Control from the GPIO Chip */
> + gpiod_remove_lookup_table(&panel_gpio_table);
> +
> mfd_remove_devices(&i2c->dev);
>
> return 0;
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
