On Wed, Feb 3, 2021 at 6:37 PM Kai-Heng Feng
wrote:
>
> Hi Furquan,
>
> On Wed, Jan 13, 2021 at 10:31 PM Dmitry Osipenko wrote:
> [snipped]
> > Thank you all for addressing this problem!
>
> Are you still working on the alternate solution?
Yes, it is in my pipeline, but I have been distracted
On Tue, Jan 12, 2021 at 5:09 AM Greg Kroah-Hartman
wrote:
>
> On Tue, Jan 12, 2021 at 01:45:25PM +0100, Rafael J. Wysocki wrote:
> > On Tue, Jan 12, 2021 at 10:55 AM Dmitry Osipenko wrote:
> > >
> > > 02.12.2020 00:30, Furquan Shaikh пишет:
> > > >
On Tue, Dec 1, 2020 at 1:30 PM Furquan Shaikh wrote:
>
> When the system is powered off or rebooted, devices are not detached
> from their PM domain. This results in ACPI PM not being invoked and
> hence PowerResouce _OFF method not being invoked for any of the
> devices. Because
that no other transactions are initiated to any other
device on the same bus after the bank switch command is sent.
Signed-off-by: Furquan Shaikh
---
v2: Added comment in raydium_i2c_{send|read} about why regmap infrastructure
cannot be used for this driver as it splits bank switch and i2c read
On Wed, Nov 25, 2020 at 10:29 AM Furquan Shaikh wrote:
>
> On Wed, Nov 25, 2020 at 9:51 AM Rafael J. Wysocki wrote:
> >
> > On Wed, Nov 25, 2020 at 6:43 PM Furquan Shaikh wrote:
> > >
> > > On Wed, Nov 25, 2020 at 8:39 AM Rafael J. Wysocki
> > >
. This action is basically
analogous to ->remove() from driver model perspective. Detaching the
device from its PM domain ensures that the ACPI PM gets a chance to
turn off the power resources for the device thus complying with its
power sequencing requirements.
Signed-off-by: Furquan Shaikh
---
driv
On Mon, Nov 30, 2020 at 11:06 PM Dmitry Torokhov
wrote:
>
> On Mon, Nov 30, 2020 at 10:54:46PM -0800, Furquan Shaikh wrote:
> > Hello Dmitry,
> >
> > On Mon, Nov 30, 2020 at 10:28 PM Dmitry Torokhov
> > wrote:
> > >
> > > Hi Furquan,
> > >
Hello Dmitry,
On Mon, Nov 30, 2020 at 10:28 PM Dmitry Torokhov
wrote:
>
> Hi Furquan,
>
> On Mon, Nov 30, 2020 at 10:00:50PM -0800, Furquan Shaikh wrote:
> > Raydium device does not like splitting of tx transactions into
> > multiple messages - one for the
that no other transactions are initiated to any other
device on the same bus after the bank switch command is sent.
Signed-off-by: Furquan Shaikh
---
drivers/input/touchscreen/raydium_i2c_ts.c | 120 ++---
1 file changed, 82 insertions(+), 38 deletions(-)
diff --git a/drivers
On Wed, Nov 25, 2020 at 9:51 AM Rafael J. Wysocki wrote:
>
> On Wed, Nov 25, 2020 at 6:43 PM Furquan Shaikh wrote:
> >
> > On Wed, Nov 25, 2020 at 8:39 AM Rafael J. Wysocki wrote:
> > >
> > > On Thu, Nov 12, 2020 at 8:19 PM Furquan Shaikh wrote:
> &g
On Wed, Nov 25, 2020 at 8:39 AM Rafael J. Wysocki wrote:
>
> On Thu, Nov 12, 2020 at 8:19 PM Furquan Shaikh wrote:
> >
> > On x86 Chromebooks, we have observed this issue for a long time now -
> > when the system is powered off or rebooted, ACPI PM is not invo
On Thu, Nov 12, 2020 at 11:19 AM Furquan Shaikh wrote:
>
> On x86 Chromebooks, we have observed this issue for a long time now -
> when the system is powered off or rebooted, ACPI PM is not invoked and
> this results in PowerResource _OFF methods not being invoked for any
>
On x86 Chromebooks, we have observed this issue for a long time now -
when the system is powered off or rebooted, ACPI PM is not invoked and
this results in PowerResource _OFF methods not being invoked for any
of the devices. The _OFF methods are invoked correctly in case of
suspend-to-idle (S0ix)
with kmem_cache_*.
In addition to that, all the code for managing the dma_pool for GSMI
platform device is dropped.
Signed-off-by: Furquan Shaikh
Reviewed-by: Ard Biesheuvel
---
Changelog since v2:
- Dropped the check to ensure allocation done by kmem_cache_alloc is
below the 4GiB boundary since DMA32 memory
with kmem_cache_*.
In addition to that, all the code for managing the dma_pool for GSMI
platform device is dropped.
Signed-off-by: Furquan Shaikh
---
Changelog since v1:
- Switched to using SLAB cache with SLAB_CACHE_DMA32.
- Added comment to code and commit message explaining the reason for
using DMA32
On Wed, Oct 21, 2020 at 2:36 AM Ard Biesheuvel wrote:
>
> On Wed, 21 Oct 2020 at 10:51, Greg Kroah-Hartman
> wrote:
> >
> > On Wed, Oct 21, 2020 at 12:37:52AM -0700, Furquan Shaikh wrote:
> > > On Tue, Oct 20, 2020 at 11:37 PM Ard Biesheuvel wrote:
> > >
On Tue, Oct 20, 2020 at 11:37 PM Ard Biesheuvel wrote:
>
> On Wed, 21 Oct 2020 at 07:18, Greg Kroah-Hartman
> wrote:
> >
> > On Tue, Oct 20, 2020 at 10:01:41PM -0700, Furquan Shaikh wrote:
> > > GSMI driver uses dma_pool_* API functions for buffer alloca
to ensure that the
page allocation is done in the DMA32 zone. All the buffer allocation
requests for gsmi_buf are then satisfed using this pre-allocated page
for the device.
In addition to that, all the code for managing the dma_pool for GSMI
platform device is dropped.
Signed-off-by: Furquan Shaikh
Hi Dmitry,
On Tue, Sep 8, 2020 at 5:44 PM Dmitry Torokhov
wrote:
>
> Hi Furquan,
>
> On Thu, Aug 20, 2020 at 07:40:06PM -0700, Furquan Shaikh wrote:
> > On an AMD chromebook, where the same I2C bus is shared by both Raydium
> > touchscreen and a trackpad device, it is ob
*` functions are refactored to use this new
helper function.
Verified with the patch across multiple reboots (>100) that the
information reported by the Raydium touchscreen device during probe
is correct.
Signed-off-by: Furquan Shaikh
---
v2: Added a new helper function raydium_i2c_xfer so that al
by
`amdgpu_acpi_get_backlight_caps()` as well. This change initializes
this local `amdgpu_dm_backlight_caps` object to 0.
Signed-off-by: Furquan Shaikh
---
v2: Switched to using memset for initialization of object.
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 2 ++
1 file changed, 2 insertions
by
`amdgpu_acpi_get_backlight_caps()` as well. This change initializes
this local `amdgpu_dm_backlight_caps` object to 0.
Signed-off-by: Furquan Shaikh
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/display
Hello Dmitry,
On Tue, Aug 18, 2020 at 5:08 PM Dmitry Torokhov
wrote:
>
> Hi Furquan,
>
> On Tue, Aug 18, 2020 at 04:42:15PM -0700, Furquan Shaikh wrote:
> > On an AMD chromebook, where the same I2C bus is shared by both Raydium
> > touchscreen and a trackpa
ect filled by it.
Signed-off-by: Furquan Shaikh
---
drivers/acpi/acpi_apd.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/acpi/acpi_apd.c b/drivers/acpi/acpi_apd.c
index 4c348377a39d..806b8ce05624 100644
--- a/drivers/acpi/acpi_apd.c
+++ b/drivers/acpi/acpi_apd.c
@@ -
creen
device is correct. Verified with the patch across multiple
reboots (>100) that the information reported by the Raydium
touchscreen device during probe is correct.
Signed-off-by: Furquan Shaikh
---
drivers/input/touchscreen/raydium_i2c_ts.c | 102 -
1 file changed
.
With this change, it was verified that pen-insert gpio key behavior is
correct in both S0 and for wakeup from S3.
Signed-off-by: Furquan Shaikh
---
drivers/pinctrl/pinctrl-amd.c | 11 +--
1 file changed, 1 insertion(+), 10 deletions(-)
diff --git a/drivers/pinctrl/pinctrl-amd.c b/drivers
On Fri, May 31, 2019 at 3:13 AM Rafael J. Wysocki wrote:
>
> On Wednesday, April 24, 2019 1:39:04 AM CEST Furquan Shaikh wrote:
> > During boot-up, ACPI bus scan enables all power resources
> > so that respective device drivers can talk to their device. This causes
On Thu, Jun 13, 2019 at 1:24 PM Rafael J. Wysocki wrote:
>
> On Thursday, May 16, 2019 9:36:16 PM CEST Furquan Shaikh wrote:
> > This change clears GPE status for wake-up devices before enabling that
> > GPE. This is required to ensure that stale GPE status does
> > not r
status is already set, enabling GPE for the wakeup device
results in generating a SCI which is handled by acpi_ev_detect_gpe
ultimately calling wakeup_source_activate that increments wakeup
events, and thus aborting the suspend attempt.
Signed-off-by: Furquan Shaikh
---
drivers/acpi/device_pm.c
On Sun, May 5, 2019 at 11:45 PM Mika Westerberg
wrote:
>
> On Fri, May 03, 2019 at 04:35:02PM -0700, Furquan Shaikh wrote:
> > Thanks for reporting the issue and apologize for the breakage. When I
> > pushed the patch, my understanding was that the device drivers do not
>
On Tue, Apr 23, 2019 at 4:39 PM Furquan Shaikh wrote:
>
> During boot-up, ACPI bus scan enables all power resources so that
> respective device drivers can talk to their device. This causes acpi
> ref_count for the power resource to be incremented to 1. When system
> su
On Thu, May 2, 2019 at 4:48 AM Greg Kroah-Hartman
wrote:
>
> On Tue, Apr 30, 2019 at 11:37:48AM +0200, Rafael J. Wysocki wrote:
> > On Tue, Apr 30, 2019 at 11:00 AM Mika Westerberg
> > wrote:
> > >
> > > +Rafael, Furquan and linux-acpi
> > >
> > > (The original thread is here
> > >
this call, their
refcount should be greater than 1. Thus, they won't be turned off.
2. If wake capable devices are not enabled yet when this call is made,
they would eventually get turned on by call to
acpi_enable_wakeup_devices.
Signed-off-by: Furquan Shaikh
---
drivers/acpi/power.c | 47
On Thu, Mar 28, 2019 at 1:57 AM Rafael J. Wysocki wrote:
>
> On Thu, Mar 28, 2019 at 1:46 AM Furquan Shaikh wrote:
> >
> > On Wed, Mar 27, 2019 at 5:24 AM Rafael J. Wysocki wrote:
> > >
> > > On Thu, Mar 21, 2019 at 3:16 AM Furquan Shaikh wrote:
> > &
On Wed, Mar 27, 2019 at 5:24 AM Rafael J. Wysocki wrote:
>
> On Thu, Mar 21, 2019 at 3:16 AM Furquan Shaikh wrote:
> >
> > On Wed, Mar 20, 2019 at 5:11 PM Rafael J. Wysocki wrote:
> > >
> > > On Wed, Mar 20, 2019 at 11:34 PM Furquan Shaikh
> > &g
On Wed, Mar 20, 2019 at 5:11 PM Rafael J. Wysocki wrote:
>
> On Wed, Mar 20, 2019 at 11:34 PM Furquan Shaikh wrote:
> >
> > Commit 18996f2db918 ("ACPICA: Events: Stop unconditionally
> > clearing ACPI IRQs during suspend/resume") was added to stop
Adding authors of the original commit whom I failed to copy in the
original patch.
On Wed, Mar 20, 2019 at 4:34 PM Furquan Shaikh wrote:
>
> Commit 18996f2db918 ("ACPICA: Events: Stop unconditionally
> clearing ACPI IRQs during suspend/resume") was added to stop clearing
>
t is being enabled so that any stale events
are cleared out.
Signed-off-by: Furquan Shaikh
---
drivers/acpi/acpica/evgpe.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/acpi/acpica/evgpe.c b/drivers/acpi/acpica/evgpe.c
index 62d3aa74277b4..61455ab42fc87 10
Hello Lee,
Gentle ping. Do you see any issues with the following change?
Thanks,
Furquan
On Sun, Jul 23, 2017 at 11:02 PM, Furquan Shaikh <furq...@google.com> wrote:
>
> Commit 274e43edcda6f ("mfd: intel-lpss: Do not put device in reset
> state on suspend") change
Hello Lee,
Gentle ping. Do you see any issues with the following change?
Thanks,
Furquan
On Sun, Jul 23, 2017 at 11:02 PM, Furquan Shaikh wrote:
>
> Commit 274e43edcda6f ("mfd: intel-lpss: Do not put device in reset
> state on suspend") changed the behavior on suspend
2C controller is disabled and put into reset.
2. Power to I2C device is cut off.
3. #2 results in the I2C lines being pulled low.
On resume:
1. Power to I2C device is enabled.
2. #2 results in the I2C lines being pulled high.
3. I2C controller is enabled and taken out of reset.
Signed-off-by: Furquan
2C controller is disabled and put into reset.
2. Power to I2C device is cut off.
3. #2 results in the I2C lines being pulled low.
On resume:
1. Power to I2C device is enabled.
2. #2 results in the I2C lines being pulled high.
3. I2C controller is enabled and taken out of reset.
Signed-off-by: F
On Wed, Jan 25, 2017 at 4:55 AM, Rafael J. Wysocki <raf...@kernel.org> wrote:
>
> On Wed, Jan 25, 2017 at 1:49 PM, Mark Brown <broo...@kernel.org> wrote:
> > On Tue, Jan 24, 2017 at 04:06:34PM -0800, Furquan Shaikh wrote:
> >
> >> Since regulator proper
On Wed, Jan 25, 2017 at 4:55 AM, Rafael J. Wysocki wrote:
>
> On Wed, Jan 25, 2017 at 1:49 PM, Mark Brown wrote:
> > On Tue, Jan 24, 2017 at 04:06:34PM -0800, Furquan Shaikh wrote:
> >
> >> Since regulator properties remain the same across OF and ACPI
> >>
):
ACPI / property: have acpi_get_next_subnode take fwnode_handle
device property: introduce fwnode_for_each_child()
device property: introduce fwnode_get_named_child_node()
Furquan Shaikh (4):
drivers/regulator: Rename of_map_mode to map_mode in regulator desc
device property: Export
From: Dmitry Torokhov <d...@chromium.org>
In preparation to introducing fwnode_for_each_chil() iterator we need
acpi_get_next_subnode take fwnode_handle argument instead of dev.
Signed-off-by: Dmitry Torokhov <d...@chromium.org>
Signed-off-by: Furquan Shaikh <furq...@chromium.or
From: Dmitry Torokhov
In preparation to introducing fwnode_for_each_chil() iterator we need
acpi_get_next_subnode take fwnode_handle argument instead of dev.
Signed-off-by: Dmitry Torokhov
Signed-off-by: Furquan Shaikh
---
drivers/acpi/property.c | 8 +---
drivers/base/property.c | 2
):
ACPI / property: have acpi_get_next_subnode take fwnode_handle
device property: introduce fwnode_for_each_child()
device property: introduce fwnode_get_named_child_node()
Furquan Shaikh (4):
drivers/regulator: Rename of_map_mode to map_mode in regulator desc
device property: Export
From: Dmitry Torokhov <d...@chromium.org>
Generic code, that wishes to work with ACPI, device tree, and pset
properties needs iterator that can work with fwnode_handle.
Signed-off-by: Dmitry Torokhov <d...@chromium.org>
Signed-off-by: Furquan Shaikh <furq...@chromium.org>
Sometimes (as the case with fixed regulator) we only want to look up,
but not necessarily reserve right away, GPIO. gpiod_lookup() and
gpiod_lookup_by_index() allow us doing just that.
Signed-off-by: Dmitry Torokhov <d...@chromium.org>
Signed-off-by: Furquan Shaikh <furq...@chr
From: Dmitry Torokhov
Generic code, that wishes to work with ACPI, device tree, and pset
properties needs iterator that can work with fwnode_handle.
Signed-off-by: Dmitry Torokhov
Signed-off-by: Furquan Shaikh
---
drivers/base/property.c | 33 +++--
include/linux
Sometimes (as the case with fixed regulator) we only want to look up,
but not necessarily reserve right away, GPIO. gpiod_lookup() and
gpiod_lookup_by_index() allow us doing just that.
Signed-off-by: Dmitry Torokhov
Signed-off-by: Furquan Shaikh
---
drivers/gpio/gpiolib.c| 75
From: Dmitry Torokhov <d...@chromium.org>
Generic code that works with ACPI, device tree, and pset properties may
want to fetch named child node of fwnode_handle.
Signed-off-by: Dmitry Torokhov <d...@chromium.org>
Signed-off-by: Furquan Shaikh <furq...@chromium.org>
---
drive
Export dev_fwnode so that it can be used by other drivers like regulator.
Signed-off-by: Furquan Shaikh <furq...@chromium.org>
---
drivers/base/property.c | 3 ++-
include/linux/property.h | 1 +
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/base/property.c b/d
From: Dmitry Torokhov
Generic code that works with ACPI, device tree, and pset properties may
want to fetch named child node of fwnode_handle.
Signed-off-by: Dmitry Torokhov
Signed-off-by: Furquan Shaikh
---
drivers/base/property.c | 45 +
include
Export dev_fwnode so that it can be used by other drivers like regulator.
Signed-off-by: Furquan Shaikh
---
drivers/base/property.c | 3 ++-
include/linux/property.h | 1 +
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/base/property.c b/drivers/base/property.c
index
for obtaining the regulation
constraints from device tree/ACPI node. Update fixed regulator driver
to use this newly added routine.
Signed-off-by: Furquan Shaikh <furq...@chromium.org>
---
drivers/regulator/Makefile | 2 +-
drivers/regulator/fixed.c
for obtaining the regulation
constraints from device tree/ACPI node. Update fixed regulator driver
to use this newly added routine.
Signed-off-by: Furquan Shaikh
---
drivers/regulator/Makefile | 2 +-
drivers/regulator/fixed.c | 100 +++
drivers/regulator
-by: Furquan Shaikh <furq...@chromium.org>
---
drivers/regulator/max77802-regulator.c | 12 ++--
drivers/regulator/of_regulator.c| 8
drivers/regulator/qcom_spmi-regulator.c | 2 +-
drivers/regulator/twl-regulator.c | 6 +++---
drivers/regulator/twl6030-regulator.c
-by: Furquan Shaikh
---
drivers/regulator/max77802-regulator.c | 12 ++--
drivers/regulator/of_regulator.c| 8
drivers/regulator/qcom_spmi-regulator.c | 2 +-
drivers/regulator/twl-regulator.c | 6 +++---
drivers/regulator/twl6030-regulator.c | 2 +-
include/linux
guarantee that.
Signed-off-by: Furquan Shaikh
---
fs/pstore/ram_core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/pstore/ram_core.c b/fs/pstore/ram_core.c
index 9d7b9a8..cfbc5e4 100644
--- a/fs/pstore/ram_core.c
+++ b/fs/pstore/ram_core.c
@@ -299,7 +299,7 @@ static void
guarantee that.
Signed-off-by: Furquan Shaikh furq...@google.com
---
fs/pstore/ram_core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/pstore/ram_core.c b/fs/pstore/ram_core.c
index 9d7b9a8..cfbc5e4 100644
--- a/fs/pstore/ram_core.c
+++ b/fs/pstore/ram_core.c
@@ -299,7
Enables getting correct mode clock when reading pipe config
This patch has been tested successfully on top of drm-intel-nightly tree
Signed-off-by: Furquan Shaikh
---
drivers/gpu/drm/i915/i915_reg.h | 6
drivers/gpu/drm/i915/intel_ddi.c | 70
We need to round up the values since the comparison in drm_mode_equal might
fail if division
results in fractional part
Signed-off-by: Furquan Shaikh
---
drivers/gpu/drm/i915/intel_display.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915
Enables getting correct mode clock when reading pipe config
This patch has been tested successfully on top of drm-intel-nightly tree
Signed-off-by: Furquan Shaikh furq...@google.com
---
drivers/gpu/drm/i915/i915_reg.h | 6
drivers/gpu/drm/i915/intel_ddi.c | 70
We need to round up the values since the comparison in drm_mode_equal might
fail if division
results in fractional part
Signed-off-by: Furquan Shaikh furq...@google.com
---
drivers/gpu/drm/i915/intel_display.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu
Enables getting correct mode clock when reading pipe config
Signed-off-by: Furquan Shaikh
---
drivers/gpu/drm/i915/intel_ddi.c | 8
drivers/gpu/drm/i915/intel_display.c | 9 -
2 files changed, 16 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b
Enables getting correct mode clock when reading pipe config
Signed-off-by: Furquan Shaikh furq...@google.com
---
drivers/gpu/drm/i915/intel_ddi.c | 8
drivers/gpu/drm/i915/intel_display.c | 9 -
2 files changed, 16 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm
68 matches
Mail list logo
