Re: [PATCH] mfd: syscon: Fix syscon name for device tree

Hi Tony, On 01/08/2019 08:15 AM, Tony Lindgren wrote: * Tony Lindgren [190108 00:06]: I'm now seeing the following error on omap5 during boot: (NULL device *): Failed to create dummy-scm_conf@0 debugfs directory This log means failed to init regmap debugfs with device(NULL) and

Re: [RESEND PATCH] pinctrl: rockchip: Disable interrupt when changing it's capability

Hi Doug, Thanks for your reply :) On 05/09/2018 01:18 PM, Doug Anderson wrote: > > >right, so we now have 2 cases: rockchip_irq_demux/ rockchip_irq_set_type > >if i'm right about the spurious irq(only happen when set rising for a high >gpio, or set falling for a low gpio), then: > >1/

Re: [RESEND PATCH] pinctrl: rockchip: Disable interrupt when changing it's capability

Hi Doug, Thanks for your reply :) On 05/09/2018 01:18 PM, Doug Anderson wrote: > > >right, so we now have 2 cases: rockchip_irq_demux/ rockchip_irq_set_type > >if i'm right about the spurious irq(only happen when set rising for a high >gpio, or set falling for a low gpio), then: > >1/

Re: [RESEND PATCH] pinctrl: rockchip: Disable interrupt when changing it's capability

Hi Doug, On 05/09/2018 03:46 AM, Doug Anderson wrote: One note is that in the case Brian points at (where we need to simulate EDGE_BOTH by swapping edges) we purposely ignored the TRM and we needed to do that to avoid losing interrupts. For details, see commit 53b1bfc76df2 ("pinctrl: rockchip:

Re: [RESEND PATCH] pinctrl: rockchip: Disable interrupt when changing it's capability

Hi Doug, On 05/09/2018 03:46 AM, Doug Anderson wrote: One note is that in the case Brian points at (where we need to simulate EDGE_BOTH by swapping edges) we purposely ignored the TRM and we needed to do that to avoid losing interrupts. For details, see commit 53b1bfc76df2 ("pinctrl: rockchip:

Re: [RESEND PATCH] pinctrl: rockchip: Disable interrupt when changing it's capability

Hi Brian, On 05/08/2018 10:31 AM, JeffyChen wrote: Hi Brian, On 05/08/2018 09:56 AM, Brian Norris wrote: On Tue, May 08, 2018 at 09:36:24AM +0800, Jeffy Chen wrote: On 05/08/2018 06:15 AM, Brian Norris wrote: On the other hand...this also implies there may be a race condition there, where

Re: [RESEND PATCH] pinctrl: rockchip: Disable interrupt when changing it's capability

Hi Brian, On 05/08/2018 10:31 AM, JeffyChen wrote: Hi Brian, On 05/08/2018 09:56 AM, Brian Norris wrote: On Tue, May 08, 2018 at 09:36:24AM +0800, Jeffy Chen wrote: On 05/08/2018 06:15 AM, Brian Norris wrote: On the other hand...this also implies there may be a race condition there, where

Re: [RESEND PATCH] pinctrl: rockchip: Disable interrupt when changing it's capability

Hi Brian, On 05/08/2018 09:56 AM, Brian Norris wrote: On Tue, May 08, 2018 at 09:36:24AM +0800, Jeffy Chen wrote: On 05/08/2018 06:15 AM, Brian Norris wrote: On the other hand...this also implies there may be a race condition there, where we might lose an interrupt if there is an edge between

Re: [RESEND PATCH] pinctrl: rockchip: Disable interrupt when changing it's capability

Hi Brian, On 05/08/2018 09:56 AM, Brian Norris wrote: On Tue, May 08, 2018 at 09:36:24AM +0800, Jeffy Chen wrote: On 05/08/2018 06:15 AM, Brian Norris wrote: On the other hand...this also implies there may be a race condition there, where we might lose an interrupt if there is an edge between

Re: [RESEND PATCH] pinctrl: rockchip: Disable interrupt when changing it's capability

Hi Brian, On 05/08/2018 06:15 AM, Brian Norris wrote: + Doug Hi Jeffy, On Thu, May 03, 2018 at 02:55:53PM +0800, Jeffy Chen wrote: We saw spurious irq when changing irq's trigger type, for example setting gpio-keys's wakeup irq trigger type. And according to the TRM: "Programming the GPIO

Re: [RESEND PATCH] pinctrl: rockchip: Disable interrupt when changing it's capability

Hi Brian, On 05/08/2018 06:15 AM, Brian Norris wrote: + Doug Hi Jeffy, On Thu, May 03, 2018 at 02:55:53PM +0800, Jeffy Chen wrote: We saw spurious irq when changing irq's trigger type, for example setting gpio-keys's wakeup irq trigger type. And according to the TRM: "Programming the GPIO

Re: [regression, bisected] rockchip rk3399 video output breakage

Hi Jokab, Thanks for your reply. On 04/24/2018 09:11 PM, Jakob Unterwurzacher wrote: On 24.04.18 14:37, JeffyChen wrote: right, i think it's a known issue, as the iommu failed to get clks: [1.525153] rk_iommu ff8f3f00.iommu: Failed to get clk 'iface': -2 [1.525316] rk_iommu: probe

Re: [regression, bisected] rockchip rk3399 video output breakage

Hi Jokab, Thanks for your reply. On 04/24/2018 09:11 PM, Jakob Unterwurzacher wrote: On 24.04.18 14:37, JeffyChen wrote: right, i think it's a known issue, as the iommu failed to get clks: [1.525153] rk_iommu ff8f3f00.iommu: Failed to get clk 'iface': -2 [1.525316] rk_iommu: probe

Re: [regression, bisected] rockchip rk3399 video output breakage

Hi Jakob, Thanks for your message. On 04/24/2018 08:19 PM, Jakob Unterwurzacher wrote: Full dmesg: https://gist.github.com/jakob-tsd/33cf395e355bf9bb6956c36438d999e7 I have bisected the "master bind failed" down to: commit 9176a303d971dc0fb35469c531c0d263667d2277 Author: Jeffy Chen

Re: [regression, bisected] rockchip rk3399 video output breakage

Hi Jakob, Thanks for your message. On 04/24/2018 08:19 PM, Jakob Unterwurzacher wrote: Full dmesg: https://gist.github.com/jakob-tsd/33cf395e355bf9bb6956c36438d999e7 I have bisected the "master bind failed" down to: commit 9176a303d971dc0fb35469c531c0d263667d2277 Author: Jeffy Chen Date:

Re: [PATCH v8 11/14] iommu/rockchip: Use OF_IOMMU to attach devices automatically

Hi Daniel, Thanks for your reply. On 04/04/2018 12:11 AM, Daniel Kurtz wrote: Hi Jeffy, Sorry for delayed response. On Mon, Mar 26, 2018 at 1:58 AM JeffyChen <jeffy.c...@rock-chips.com> wrote: Hi Daniel, Thanks for your reply. On 03/26/2018 02:31 PM, Daniel Kurtz wrote: +

Re: [PATCH v8 11/14] iommu/rockchip: Use OF_IOMMU to attach devices automatically

Hi Daniel, Thanks for your reply. On 04/04/2018 12:11 AM, Daniel Kurtz wrote: Hi Jeffy, Sorry for delayed response. On Mon, Mar 26, 2018 at 1:58 AM JeffyChen wrote: Hi Daniel, Thanks for your reply. On 03/26/2018 02:31 PM, Daniel Kurtz wrote: +struct rk_iommudata { + struct

Re: [PATCH] iommu: rockchip: fix building without CONFIG_OF

Hi Amd, Thanks for your patch. On 04/04/2018 06:23 PM, Arnd Bergmann wrote: We get a build error when compiling the iommu driver without CONFIG_OF: drivers/iommu/rockchip-iommu.c: In function 'rk_iommu_of_xlate': drivers/iommu/rockchip-iommu.c:1101:2: error: implicit declaration of function

Re: [PATCH] iommu: rockchip: fix building without CONFIG_OF

Hi Amd, Thanks for your patch. On 04/04/2018 06:23 PM, Arnd Bergmann wrote: We get a build error when compiling the iommu driver without CONFIG_OF: drivers/iommu/rockchip-iommu.c: In function 'rk_iommu_of_xlate': drivers/iommu/rockchip-iommu.c:1101:2: error: implicit declaration of function

Re: [PATCH v5 3/4] clk: lpc32xx: Set name of regmap_config

Hi Vladimir, On 03/19/2018 05:57 AM, Vladimir Zapolskiy wrote: > static struct regmap_config lpc32xx_scb_regmap_config = { >+ .name = "lpc32xx-scb", please rename it to "scb", LPC32xx SoC name is already known from the context. When it's done, feel free to add to the next version my

Re: [PATCH v5 3/4] clk: lpc32xx: Set name of regmap_config

Hi Vladimir, On 03/19/2018 05:57 AM, Vladimir Zapolskiy wrote: > static struct regmap_config lpc32xx_scb_regmap_config = { >+ .name = "lpc32xx-scb", please rename it to "scb", LPC32xx SoC name is already known from the context. When it's done, feel free to add to the next version my

Re: [PATCH v5 1/3] Input: gpio-keys - add support for wakeup event action

Hi Dmitry, Thanks for your reply. On 03/11/2018 02:15 AM, Dmitry Torokhov wrote:>> +static int gpio_keys_enable_wakeup(struct gpio_button_data *bdata) > These new helpers need to be __maybe_unused in case we compile on system > without suspend support. > > I also wanted a bit more of error

Re: [PATCH v5 1/3] Input: gpio-keys - add support for wakeup event action

Hi Dmitry, Thanks for your reply. On 03/11/2018 02:15 AM, Dmitry Torokhov wrote:>> +static int gpio_keys_enable_wakeup(struct gpio_button_data *bdata) > These new helpers need to be __maybe_unused in case we compile on system > without suspend support. > > I also wanted a bit more of error

Re: [RESEND PATCH v4 1/4] mfd: syscon: Set name of regmap_config

Hi Lee, On 03/12/2018 05:12 PM, Lee Jones wrote: On Fri, 09 Mar 2018, Jeffy Chen wrote: >We are now allowing to register debugfs without a valid device, and not >having a valid name will end up using "dummy*" to create debugfs dir. > >Signed-off-by: Jeffy Chen >---

Re: [RESEND PATCH v4 1/4] mfd: syscon: Set name of regmap_config

Hi Lee, On 03/12/2018 05:12 PM, Lee Jones wrote: On Fri, 09 Mar 2018, Jeffy Chen wrote: >We are now allowing to register debugfs without a valid device, and not >having a valid name will end up using "dummy*" to create debugfs dir. > >Signed-off-by: Jeffy Chen >--- > >Changes in v4: None

Re: [PATCH v4 0/4] Set name of regmap_config

Hi Lee, Thanks for your reply. On 03/09/2018 04:16 PM, Lee Jones wrote: > >Jeffy Chen (4): > mfd: syscon: Set name of regmap_config > rtc: at91sam9: Set name of regmap_config > clk: lpc32xx: Set name of regmap_config > ARM: rockchip: Set name of regmap_config > >

Re: [PATCH v4 0/4] Set name of regmap_config

Hi Lee, Thanks for your reply. On 03/09/2018 04:16 PM, Lee Jones wrote: > >Jeffy Chen (4): > mfd: syscon: Set name of regmap_config > rtc: at91sam9: Set name of regmap_config > clk: lpc32xx: Set name of regmap_config > ARM: rockchip: Set name of regmap_config > >

Re: [PATCH v3 2/4] rtc: at91sam9: Pass pdev->dev to regmap_init_mmio()

Hi Alexandre, On 03/09/2018 04:49 AM, Alexandre Belloni wrote: On 08/03/2018 at 18:21:52 +0800, Jeffy Chen wrote: Otherwise it would use "dummy*" to create regmap debugfs dir. Signed-off-by: Jeffy Chen --- Changes in v3: None drivers/rtc/rtc-at91sam9.c | 2 +-

Re: [PATCH v3 2/4] rtc: at91sam9: Pass pdev->dev to regmap_init_mmio()

Hi Alexandre, On 03/09/2018 04:49 AM, Alexandre Belloni wrote: On 08/03/2018 at 18:21:52 +0800, Jeffy Chen wrote: Otherwise it would use "dummy*" to create regmap debugfs dir. Signed-off-by: Jeffy Chen --- Changes in v3: None drivers/rtc/rtc-at91sam9.c | 2 +- 1 file changed, 1

Re: [PATCH v4 1/3] Input: gpio-keys - add support for wakeup event action

Hi Andy, Thanks for your reply. On 03/07/2018 07:57 PM, Andy Shevchenko wrote: On Tue, Mar 6, 2018 at 9:44 AM, Jeffy Chen wrote: Add support for specifying event actions to trigger wakeup when using the gpio-keys input device as a wakeup source. This would allow

Re: [PATCH v4 1/3] Input: gpio-keys - add support for wakeup event action

Hi Andy, Thanks for your reply. On 03/07/2018 07:57 PM, Andy Shevchenko wrote: On Tue, Mar 6, 2018 at 9:44 AM, Jeffy Chen wrote: Add support for specifying event actions to trigger wakeup when using the gpio-keys input device as a wakeup source. This would allow the device to configure when

Re: [PATCH v2 2/3] regmap: debugfs: Fix kmemleak in regmap_debugfs_init

Hi Mark, Thanks for your reply. On 03/06/2018 08:59 PM, Mark Brown wrote: On Tue, Mar 06, 2018 at 07:04:02PM +0800, Jeffy Chen wrote: Use map->debugfs_name to store allocated debugfs name, so it would be freed in regmap_debugfs_exit(). I'm missing patch 1 in this series and I think this

Re: [PATCH v2 2/3] regmap: debugfs: Fix kmemleak in regmap_debugfs_init

Hi Mark, Thanks for your reply. On 03/06/2018 08:59 PM, Mark Brown wrote: On Tue, Mar 06, 2018 at 07:04:02PM +0800, Jeffy Chen wrote: Use map->debugfs_name to store allocated debugfs name, so it would be freed in regmap_debugfs_exit(). I'm missing patch 1 in this series and I think this

Re: [PATCH v2 1/3] mfd: syscon: Set name of regmap_config

Hi Mark, On 03/07/2018 06:20 PM, Mark Brown wrote: On Tue, Mar 06, 2018 at 10:58:26PM +0800, JeffyChen wrote: even this is already fixed by a430ab205d29 ("regmap: debugfs: Disambiguate dummy debugfs file name") but maybe we can still have this for a better debugfs name?

Re: [PATCH v2 1/3] mfd: syscon: Set name of regmap_config

Hi Mark, On 03/07/2018 06:20 PM, Mark Brown wrote: On Tue, Mar 06, 2018 at 10:58:26PM +0800, JeffyChen wrote: even this is already fixed by a430ab205d29 ("regmap: debugfs: Disambiguate dummy debugfs file name") but maybe we can still have this for a better debugfs name?

Re: [PATCH v2 1/3] mfd: syscon: Set name of regmap_config

+CC Mark. even this is already fixed by a430ab205d29 ("regmap: debugfs: Disambiguate dummy debugfs file name") but maybe we can still have this for a better debugfs name? On 03/06/2018 07:04 PM, Jeffy Chen wrote: We are now allowing to register debugfs for syscon regmap, and not having a

Re: [PATCH v2 1/3] mfd: syscon: Set name of regmap_config

+CC Mark. even this is already fixed by a430ab205d29 ("regmap: debugfs: Disambiguate dummy debugfs file name") but maybe we can still have this for a better debugfs name? On 03/06/2018 07:04 PM, Jeffy Chen wrote: We are now allowing to register debugfs for syscon regmap, and not having a

Re: [PATCH v3 1/3] Input: gpio-keys - add support for wakeup event action

Hi Dmitry, Thanks for your review. On 03/06/2018 08:30 AM, Dmitry Torokhov wrote: >+ switch (button->wakeup_event_action) { >+ case EV_ACT_ASSERTED: >+ bdata->wakeup_trigger_type = active_low ? >+ IRQF_TRIGGER_FALLING :

Re: [PATCH v3 1/3] Input: gpio-keys - add support for wakeup event action

Hi Dmitry, Thanks for your review. On 03/06/2018 08:30 AM, Dmitry Torokhov wrote: >+ switch (button->wakeup_event_action) { >+ case EV_ACT_ASSERTED: >+ bdata->wakeup_trigger_type = active_low ? >+ IRQF_TRIGGER_FALLING :

Re: [RESEND PATCH v6 09/14] dt-bindings: iommu/rockchip: Add clock property

Hi Rob, Thanks for your reply. On 03/06/2018 10:27 AM, Rob Herring wrote: On Thu, Mar 01, 2018 at 06:18:32PM +0800, Jeffy Chen wrote: Add clock property, since we are going to control clocks in rockchip iommu driver. Signed-off-by: Jeffy Chen --- Changes in v6:

Re: [RESEND PATCH v6 09/14] dt-bindings: iommu/rockchip: Add clock property

Hi Rob, Thanks for your reply. On 03/06/2018 10:27 AM, Rob Herring wrote: On Thu, Mar 01, 2018 at 06:18:32PM +0800, Jeffy Chen wrote: Add clock property, since we are going to control clocks in rockchip iommu driver. Signed-off-by: Jeffy Chen --- Changes in v6: None Really? There was a

Re: [PATCH v9 5/5] drm/bridge/synopsys: dw-hdmi: Add missing bridge detach

ind. but i found a kmemleak issue(dma_mask not freed) in dw-hdmi when testing that, will send patch soon. On 03/03/2018 08:20 AM, JeffyChen wrote: Hi Laurent, On 03/03/2018 05:49 AM, Laurent Pinchart wrote: Hi Enric, Thank you for the patch. On Friday, 2 March 2018 19:57:57 EET Enric Balle

Re: [PATCH v9 5/5] drm/bridge/synopsys: dw-hdmi: Add missing bridge detach

ind. but i found a kmemleak issue(dma_mask not freed) in dw-hdmi when testing that, will send patch soon. On 03/03/2018 08:20 AM, JeffyChen wrote: Hi Laurent, On 03/03/2018 05:49 AM, Laurent Pinchart wrote: Hi Enric, Thank you for the patch. On Friday, 2 March 2018 19:57:57 EET Enric Balle

Re: [PATCH v9 5/5] drm/bridge/synopsys: dw-hdmi: Add missing bridge detach

Hi Laurent, On 03/03/2018 05:49 AM, Laurent Pinchart wrote: Hi Enric, Thank you for the patch. On Friday, 2 March 2018 19:57:57 EET Enric Balletbo i Serra wrote: From: Jeffy Chen We inited connector in attach(), so need a detach() to cleanup. Do we ? The

Re: [PATCH v9 5/5] drm/bridge/synopsys: dw-hdmi: Add missing bridge detach

Hi Laurent, On 03/03/2018 05:49 AM, Laurent Pinchart wrote: Hi Enric, Thank you for the patch. On Friday, 2 March 2018 19:57:57 EET Enric Balletbo i Serra wrote: From: Jeffy Chen We inited connector in attach(), so need a detach() to cleanup. Do we ? The dw-hdmi driver already sets

Re: [PATCH v2 1/3] Input: gpio-keys - add support for wakeup event action

Hi Brain, Thanks for your reply. On 03/02/2018 10:32 AM, Brian Norris wrote: > >What about the 'else' case? Shouldn't we try to handle that? >i think the else case is for irq key, which would generate down and up >events in one irq, so it would use the same trigger type for all these 3

Re: [PATCH v2 1/3] Input: gpio-keys - add support for wakeup event action

Hi Brain, Thanks for your reply. On 03/02/2018 10:32 AM, Brian Norris wrote: > >What about the 'else' case? Shouldn't we try to handle that? >i think the else case is for irq key, which would generate down and up >events in one irq, so it would use the same trigger type for all these 3

Re: [RESEND PATCH v6 14/14] iommu/rockchip: Support sharing IOMMU between masters

Hi Robin, On 03/01/2018 07:03 PM, Robin Murphy wrote: +static struct iommu_group *rk_iommu_device_group(struct device *dev) +{ +struct rk_iommu *iommu; + +iommu = rk_iommu_from_dev(dev); + +return iommu->group; Oops, seems I overlooked this in my previous review - it should

Re: [RESEND PATCH v6 14/14] iommu/rockchip: Support sharing IOMMU between masters

Hi Robin, On 03/01/2018 07:03 PM, Robin Murphy wrote: +static struct iommu_group *rk_iommu_device_group(struct device *dev) +{ +struct rk_iommu *iommu; + +iommu = rk_iommu_from_dev(dev); + +return iommu->group; Oops, seems I overlooked this in my previous review - it should

Re: [PATCH] soc: rockchip: power-domain: remove PM clocks

Hi Geert, Thanks for your reply. On 03/01/2018 04:33 PM, Geert Uytterhoeven wrote: >so maybe we can: >1/ let the device(dts) or driver decide which clock is PM clk, and add it >using*pm_clk_add* APIs (even of_pm_clk_add_clks() if all clocks are pm clk) > >2/ add support for critical PM clk,

Re: [PATCH] soc: rockchip: power-domain: remove PM clocks

Hi Geert, Thanks for your reply. On 03/01/2018 04:33 PM, Geert Uytterhoeven wrote: >so maybe we can: >1/ let the device(dts) or driver decide which clock is PM clk, and add it >using*pm_clk_add* APIs (even of_pm_clk_add_clks() if all clocks are pm clk) > >2/ add support for critical PM clk,

Re: [PATCH] soc: rockchip: power-domain: remove PM clocks

Hi guys, if i'm reading the code right, the PM clk means: 1/ the clocks which would be enabled while power on 2/ these clocks are optional, it's ok if anything wrong with them 3/ controlled by pm_domain(or USE_PM_CLK_RUNTIME_OPS & pm_clk_add_notifier) and currently we're adding all clocks of

Re: [PATCH] soc: rockchip: power-domain: remove PM clocks

Hi guys, if i'm reading the code right, the PM clk means: 1/ the clocks which would be enabled while power on 2/ these clocks are optional, it's ok if anything wrong with them 3/ controlled by pm_domain(or USE_PM_CLK_RUNTIME_OPS & pm_clk_add_notifier) and currently we're adding all clocks of

Re: [PATCH v5 08/13] iommu/rockchip: Control clocks needed to access the IOMMU

Hi Robin, Thanks for your reply. On 02/28/2018 11:06 PM, Robin Murphy wrote: On 28/02/18 13:00, JeffyChen wrote: Hi Robin, Thanks for your reply. On 02/28/2018 12:59 AM, Robin Murphy wrote: the rockchip IOMMU is part of the master block in hardware, so it needs to control the master's

Re: [PATCH v5 08/13] iommu/rockchip: Control clocks needed to access the IOMMU

Hi Robin, Thanks for your reply. On 02/28/2018 11:06 PM, Robin Murphy wrote: On 28/02/18 13:00, JeffyChen wrote: Hi Robin, Thanks for your reply. On 02/28/2018 12:59 AM, Robin Murphy wrote: the rockchip IOMMU is part of the master block in hardware, so it needs to control the master's

Re: [PATCH v5 08/13] iommu/rockchip: Control clocks needed to access the IOMMU

Hi Robin, Thanks for your reply. On 02/28/2018 12:59 AM, Robin Murphy wrote: the rockchip IOMMU is part of the master block in hardware, so it needs to control the master's power domain and some of the master's clocks when access it's registers. and the number of clocks needed here, might be

Re: [PATCH v5 08/13] iommu/rockchip: Control clocks needed to access the IOMMU

Hi Robin, Thanks for your reply. On 02/28/2018 12:59 AM, Robin Murphy wrote: the rockchip IOMMU is part of the master block in hardware, so it needs to control the master's power domain and some of the master's clocks when access it's registers. and the number of clocks needed here, might be

Re: [PATCH] soc: rockchip: power-domain: remove PM clocks

Hi Geert, Thanks for you reply. On 02/28/2018 08:17 PM, Geert Uytterhoeven wrote: Hi Jeffy, On Wed, Feb 28, 2018 at 12:11 PM, Jeffy Chen wrote: Currently we are adding all of the attached devices' clocks as pm clocks and enable them when powering on the power

Re: [PATCH] soc: rockchip: power-domain: remove PM clocks

Hi Geert, Thanks for you reply. On 02/28/2018 08:17 PM, Geert Uytterhoeven wrote: Hi Jeffy, On Wed, Feb 28, 2018 at 12:11 PM, Jeffy Chen wrote: Currently we are adding all of the attached devices' clocks as pm clocks and enable them when powering on the power domain. This seems

Re: [PATCH] rtc: cros-ec: return -ETIME when refused to set alarms in the past

Hi Brian, Thanks for your reply. On 02/27/2018 02:37 AM, Brian Norris wrote: >+ /* Don't set an alarm in the past. */ >+ if ((u32)alarm_time <= current_time) >+ return -ETIME; >+ >if (!alrm->enabled) { >/* > * If the alarm is being disabled, send an

Re: [PATCH] rtc: cros-ec: return -ETIME when refused to set alarms in the past

Hi Brian, Thanks for your reply. On 02/27/2018 02:37 AM, Brian Norris wrote: >+ /* Don't set an alarm in the past. */ >+ if ((u32)alarm_time <= current_time) >+ return -ETIME; >+ >if (!alrm->enabled) { >/* > * If the alarm is being disabled, send an

Re: [PATCH v3] rtc: cros-ec: return -ETIME when refused to set alarms in the past

Hi guys, On 02/27/2018 10:47 AM, Jeffy Chen wrote: /* Don't set an alarm in the past. */ if ((u32)alarm_time < current_time) Oops, i'm a idiot, forgot to use '<='... will resend it. - alarm_offset = EC_RTC_ALARM_CLEAR; - else

Re: [PATCH v3] rtc: cros-ec: return -ETIME when refused to set alarms in the past

Hi guys, On 02/27/2018 10:47 AM, Jeffy Chen wrote: /* Don't set an alarm in the past. */ if ((u32)alarm_time < current_time) Oops, i'm a idiot, forgot to use '<='... will resend it. - alarm_offset = EC_RTC_ALARM_CLEAR; - else

Re: [PATCH v4 08/13] iommu/rockchip: Control clocks needed to access the IOMMU

Hi guys, On 01/25/2018 06:24 PM, JeffyChen wrote: On 01/25/2018 05:42 PM, Randy Li wrote: confirmed with Simon, there might be some iommus don't have a pd, and We use the pd to control the NIU node(not on upstream), without a pd or fake pd, none of the platform would work. after talked

Re: [PATCH v4 08/13] iommu/rockchip: Control clocks needed to access the IOMMU

Hi guys, On 01/25/2018 06:24 PM, JeffyChen wrote: On 01/25/2018 05:42 PM, Randy Li wrote: confirmed with Simon, there might be some iommus don't have a pd, and We use the pd to control the NIU node(not on upstream), without a pd or fake pd, none of the platform would work. after talked

Re: [PATCH v2 1/3] Input: gpio-keys - add support for wakeup event action

Hi Enric, Thanks for your reply. On 02/14/2018 06:25 AM, Enric Balletbo Serra wrote: Hi, 2018-02-13 19:25 GMT+01:00 Brian Norris : Hi Enric, On Tue, Feb 13, 2018 at 11:40:44AM +0100, Enric Balletbo i Serra wrote: On 12/02/18 23:13, Brian Norris wrote: On Sat, Feb

Re: [PATCH v2 1/3] Input: gpio-keys - add support for wakeup event action

Hi Enric, Thanks for your reply. On 02/14/2018 06:25 AM, Enric Balletbo Serra wrote: Hi, 2018-02-13 19:25 GMT+01:00 Brian Norris : Hi Enric, On Tue, Feb 13, 2018 at 11:40:44AM +0100, Enric Balletbo i Serra wrote: On 12/02/18 23:13, Brian Norris wrote: On Sat, Feb 10, 2018 at 07:09:05PM

Re: [PATCH v2 1/3] Input: gpio-keys - add support for wakeup event action

Hi Brian, Thanks for your reply. On 02/13/2018 06:13 AM, Brian Norris wrote: > >if (bdata->gpiod) { >+ int active_low = gpiod_is_active_low(bdata->gpiod); >+ >if (button->debounce_interval) { >error = gpiod_set_debounce(bdata->gpiod, >

Re: [PATCH v2 1/3] Input: gpio-keys - add support for wakeup event action

Hi Brian, Thanks for your reply. On 02/13/2018 06:13 AM, Brian Norris wrote: > >if (bdata->gpiod) { >+ int active_low = gpiod_is_active_low(bdata->gpiod); >+ >if (button->debounce_interval) { >error = gpiod_set_debounce(bdata->gpiod, >

Re: [PATCH v2 0/3] gpio-keys: Add support for specifying wakeup event action

Hi Heiko, Thanks for your reply :) On 02/14/2018 09:39 PM, Heiko Stübner wrote: Hi Jeffy, Am Samstag, 10. Februar 2018, 12:09:04 CET schrieb Jeffy Chen: On chromebook kevin, we are using gpio-keys for pen insert event. But we only want it to wakeup the system when ejecting the pen. So we

Re: [PATCH v2 0/3] gpio-keys: Add support for specifying wakeup event action

Hi Heiko, Thanks for your reply :) On 02/14/2018 09:39 PM, Heiko Stübner wrote: Hi Jeffy, Am Samstag, 10. Februar 2018, 12:09:04 CET schrieb Jeffy Chen: On chromebook kevin, we are using gpio-keys for pen insert event. But we only want it to wakeup the system when ejecting the pen. So we

Re: [PATCH 2/3] Input: gpio-keys - allow setting wakeup interrupt trigger type in DT

Hi Brian, Thanks for your reply. On 02/10/2018 07:42 AM, Brian Norris wrote: Hi Jeffy, On Fri, Feb 09, 2018 at 07:55:09PM +0800, Jeffy Chen wrote: Allow specifying a different interrupt trigger type for wakeup when using the gpio-keys input device as a wakeup source. Signed-off-by: Jeffy

Re: [PATCH 2/3] Input: gpio-keys - allow setting wakeup interrupt trigger type in DT

Hi Brian, Thanks for your reply. On 02/10/2018 07:42 AM, Brian Norris wrote: Hi Jeffy, On Fri, Feb 09, 2018 at 07:55:09PM +0800, Jeffy Chen wrote: Allow specifying a different interrupt trigger type for wakeup when using the gpio-keys input device as a wakeup source. Signed-off-by: Jeffy

Re: [PATCH v5 08/13] iommu/rockchip: Control clocks needed to access the IOMMU

Hi Robin, Thanks for your reply. On 01/24/2018 09:49 PM, Robin Murphy wrote: +Optional properties: +- clocks : A list of master clocks requires for the IOMMU to be accessible s/requires/required/ ok + by the host CPU. The number of clocks depends on the master +

Re: [PATCH v5 08/13] iommu/rockchip: Control clocks needed to access the IOMMU

Hi Robin, Thanks for your reply. On 01/24/2018 09:49 PM, Robin Murphy wrote: +Optional properties: +- clocks : A list of master clocks requires for the IOMMU to be accessible s/requires/required/ ok + by the host CPU. The number of clocks depends on the master +

Re: [PATCH v4 08/13] iommu/rockchip: Control clocks needed to access the IOMMU

On 01/25/2018 05:42 PM, Randy Li wrote: confirmed with Simon, there might be some iommus don't have a pd, and We use the pd to control the NIU node(not on upstream), without a pd or fake pd, none of the platform would work. after talked offline, it's possible to have iommu without pd in

Re: [PATCH v4 08/13] iommu/rockchip: Control clocks needed to access the IOMMU

On 01/25/2018 05:42 PM, Randy Li wrote: confirmed with Simon, there might be some iommus don't have a pd, and We use the pd to control the NIU node(not on upstream), without a pd or fake pd, none of the platform would work. after talked offline, it's possible to have iommu without pd in

Re: [PATCH v7 00/10] rockchip: kevin: Enable edp display

Hi Thierry, Thanks for posting these :) Hi Archit, Thanks for your reply. On 01/10/2018 05:46 PM, Archit Taneja wrote: I don't know if the rest of the rockchip patches in the series depend on the 4 bridge patches. If they do, the rockchip maintainer can queue both rockchip and bridge

Re: [PATCH v7 00/10] rockchip: kevin: Enable edp display

Hi Thierry, Thanks for posting these :) Hi Archit, Thanks for your reply. On 01/10/2018 05:46 PM, Archit Taneja wrote: I don't know if the rest of the rockchip patches in the series depend on the 4 bridge patches. If they do, the rockchip maintainer can queue both rockchip and bridge

Re: [PATCH v4 08/13] iommu/rockchip: Control clocks needed to access the IOMMU

Hi Randy, On 01/22/2018 10:15 AM, JeffyChen wrote: Hi Randy, On 01/22/2018 09:18 AM, Randy Li wrote: Also the power domain driver could manage the clocks as well, I would suggest to use pm_runtime_*. actually the clocks required by pm domain may not be the same as what we want to control

Re: [PATCH v4 08/13] iommu/rockchip: Control clocks needed to access the IOMMU

Hi Randy, On 01/22/2018 10:15 AM, JeffyChen wrote: Hi Randy, On 01/22/2018 09:18 AM, Randy Li wrote: Also the power domain driver could manage the clocks as well, I would suggest to use pm_runtime_*. actually the clocks required by pm domain may not be the same as what we want to control

Re: [PATCH v4 08/13] iommu/rockchip: Control clocks needed to access the IOMMU

Hi Randy, On 01/22/2018 09:18 AM, Randy Li wrote: Also the power domain driver could manage the clocks as well, I would suggest to use pm_runtime_*. actually the clocks required by pm domain may not be the same as what we want to control here, there might be some clocks only be needed when

Re: [PATCH v4 08/13] iommu/rockchip: Control clocks needed to access the IOMMU

Hi Randy, On 01/22/2018 09:18 AM, Randy Li wrote: Also the power domain driver could manage the clocks as well, I would suggest to use pm_runtime_*. actually the clocks required by pm domain may not be the same as what we want to control here, there might be some clocks only be needed when

Re: [PATCH v4 07/13] ARM: dts: rockchip: add clocks in vop iommu nodes

Hi Tomasz, Thanks for your reply. On 01/19/2018 11:23 AM, Tomasz Figa wrote: On Thu, Jan 18, 2018 at 8:52 PM, Jeffy Chen wrote: Add clocks in vop iommu nodes, since we are going to control clocks in rockchip iommu driver. Signed-off-by: Jeffy Chen

Re: [PATCH v4 07/13] ARM: dts: rockchip: add clocks in vop iommu nodes

Hi Tomasz, Thanks for your reply. On 01/19/2018 11:23 AM, Tomasz Figa wrote: On Thu, Jan 18, 2018 at 8:52 PM, Jeffy Chen wrote: Add clocks in vop iommu nodes, since we are going to control clocks in rockchip iommu driver. Signed-off-by: Jeffy Chen --- Changes in v4: None Changes in v3:

Re: [PATCH] iommu/of: Only do IOMMU lookup for available ones

Hi Will, Thanks for your reply. On 01/18/2018 10:41 PM, Will Deacon wrote: > >Makes sense to me, but I'd like to have an OK from Robin or Will (added >to Cc) before applying this. I don't think this patch makes a lot of sense in isolation: the SMMU drivers themselves will likely still probe,

Re: [PATCH] iommu/of: Only do IOMMU lookup for available ones

Hi Will, Thanks for your reply. On 01/18/2018 10:41 PM, Will Deacon wrote: > >Makes sense to me, but I'd like to have an OK from Robin or Will (added >to Cc) before applying this. I don't think this patch makes a lot of sense in isolation: the SMMU drivers themselves will likely still probe,

Re: [PATCH v4 08/13] iommu/rockchip: Control clocks needed to access the IOMMU

Hi Robin, On 01/18/2018 08:27 PM, Robin Murphy wrote: Is it worth using the clk_bulk_*() APIs for this? At a glance, most of the code being added here appears to duplicate what those functions already do (but I'm no clk API expert, for sure). right, i think it's doable, the clk_bulk APIs are

Re: [PATCH v4 08/13] iommu/rockchip: Control clocks needed to access the IOMMU

Hi Robin, On 01/18/2018 08:27 PM, Robin Murphy wrote: Is it worth using the clk_bulk_*() APIs for this? At a glance, most of the code being added here appears to duplicate what those functions already do (but I'm no clk API expert, for sure). right, i think it's doable, the clk_bulk APIs are

Re: [PATCH v4 04/13] iommu/rockchip: Fix error handling in attach

Hi Robin, On 01/18/2018 09:23 PM, Robin Murphy wrote: @@ -837,7 +837,7 @@ static int rk_iommu_attach_device(struct iommu_domain *domain, ret = rk_iommu_enable_paging(iommu); if (ret) -return ret; +goto err_disable_stall; spin_lock_irqsave(_domain->iommus_lock,

Re: [PATCH v4 04/13] iommu/rockchip: Fix error handling in attach

Hi Robin, On 01/18/2018 09:23 PM, Robin Murphy wrote: @@ -837,7 +837,7 @@ static int rk_iommu_attach_device(struct iommu_domain *domain, ret = rk_iommu_enable_paging(iommu); if (ret) -return ret; +goto err_disable_stall; spin_lock_irqsave(_domain->iommus_lock,

Re: [PATCH v4 05/13] iommu/rockchip: Use iopoll helpers to wait for hardware

Hi Robin, On 01/18/2018 09:09 PM, Robin Murphy wrote: -#define FORCE_RESET_TIMEOUT100/* ms */ +#define FORCE_RESET_TIMEOUT10/* us */ +#define POLL_TIMEOUT1000/* us */ Nit: the callsites look a bit odd with the combination of POLL_TIMEOUT and the magic number

Re: [PATCH v4 05/13] iommu/rockchip: Use iopoll helpers to wait for hardware

Hi Robin, On 01/18/2018 09:09 PM, Robin Murphy wrote: -#define FORCE_RESET_TIMEOUT100/* ms */ +#define FORCE_RESET_TIMEOUT10/* us */ +#define POLL_TIMEOUT1000/* us */ Nit: the callsites look a bit odd with the combination of POLL_TIMEOUT and the magic number

Re: [PATCH v4 00/13] iommu/rockchip: Use OF_IOMMU

Hi Joerg, Thanks for your reply. On 01/18/2018 08:44 PM, Joerg Roedel wrote: On Thu, Jan 18, 2018 at 07:52:38PM +0800, Jeffy Chen wrote: Jeffy Chen (9): iommu/rockchip: Prohibit unbind and remove iommu/rockchip: Fix error handling in probe iommu/rockchip: Request irqs in

Re: [PATCH v4 00/13] iommu/rockchip: Use OF_IOMMU

Hi Joerg, Thanks for your reply. On 01/18/2018 08:44 PM, Joerg Roedel wrote: On Thu, Jan 18, 2018 at 07:52:38PM +0800, Jeffy Chen wrote: Jeffy Chen (9): iommu/rockchip: Prohibit unbind and remove iommu/rockchip: Fix error handling in probe iommu/rockchip: Request irqs in

Re: [PATCH v3 01/12] iommu/rockchip: Prohibiat unbind and remove

Hi Tomasz, Thanks for your reply. and just found i forgot to add iommu clocks for other rockchip platforms(rk3399 already has that)...will also do that in the next version. On 01/18/2018 12:17 PM, Tomasz Figa wrote: On Thu, Jan 18, 2018 at 12:25 AM, Jeffy Chen

Re: [PATCH v3 01/12] iommu/rockchip: Prohibiat unbind and remove

Hi Tomasz, Thanks for your reply. and just found i forgot to add iommu clocks for other rockchip platforms(rk3399 already has that)...will also do that in the next version. On 01/18/2018 12:17 PM, Tomasz Figa wrote: On Thu, Jan 18, 2018 at 12:25 AM, Jeffy Chen wrote: Removal the IOMMUs

Re: [PATCH v2 13/13] iommu/rockchip: Support sharing IOMMU between masters

Hi Robin, On 01/17/2018 09:00 PM, Robin Murphy wrote: On 16/01/18 13:25, Jeffy Chen wrote: There would be some masters sharing the same IOMMU device. Put them in the same iommu group and share the same iommu domain. Signed-off-by: Jeffy Chen --- Changes in v2:

Re: [PATCH v2 13/13] iommu/rockchip: Support sharing IOMMU between masters

Hi Robin, On 01/17/2018 09:00 PM, Robin Murphy wrote: On 16/01/18 13:25, Jeffy Chen wrote: There would be some masters sharing the same IOMMU device. Put them in the same iommu group and share the same iommu domain. Signed-off-by: Jeffy Chen --- Changes in v2: None

Re: [PATCH v2 09/13] iommu/rockchip: Use iommu_group_get_for_dev() for add_device

On 01/17/2018 08:47 PM, JeffyChen wrote: +static struct iommu_group *rk_iommu_device_group(struct device *dev) +{ +struct iommu_group *group; +int ret; + +group = iommu_group_get(dev); +if (!group) { This check is pointless - if dev->iommu_group were non-NULL you wouldn't h

  1   2   >