Hi Heiko,
On 10/31/2017 07:01 AM, Heiko Stuebner wrote:
As I was just looking at the edp dts change in patch1 again, does this
series also contain a fix for the issue below [0] ?
I'm still seeing this on 4.14-rc6 with the most recent drm tree merged in.
i saw that too, it should due to our psr
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 patches
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 upstr
Hi Marek,
Thanks for your reply.
On 01/11/2018 05:40 PM, Marek Szyprowski wrote:
Hi Jeffy,
On 2018-01-11 09:22, Jeffy Chen wrote:
With the probe-deferral mechanism, early initialisation hooks are no
longer needed.
Suggested-by: Robin Murphy
Signed-off-by: Jeffy Chen
---
drivers/iommu/ar
Hi Robin,
thanks for your reply.
On 01/11/2018 11:47 PM, Robin Murphy wrote:
+for (i = 0; i < iommu->num_irq; i++) {
+ret = devm_request_irq(iommu->dev, iommu->irq[i], rk_iommu_irq,
+ IRQF_SHARED, dev_name(dev), iommu);
Why aren't we simply requesting the IR
Hi Robin,
Thnaks for your reply.
On 01/11/2018 08:24 PM, Robin Murphy wrote:
Hi Jeffy,
On 11/01/18 11:14, JeffyChen wrote:
Hi Marek,
Thanks for your reply.
On 01/11/2018 05:40 PM, Marek Szyprowski wrote:
Hi Jeffy,
On 2018-01-11 09:22, Jeffy Chen wrote:
With the probe-deferral mechanism
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: Non
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
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
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
+ block
Hi Tomasz,
On 01/17/2018 03:16 PM, Tomasz Figa wrote:
>>
>>This lacks consistency. of_irq_count() is used for counting, but
>>platform_get_irq() is used for getting. Either platform_ or of_ API
>>should be used for both and I'd lean for platform_, since it's more
>>general.
>
>hmmm, right, i wa
On 01/17/2018 03:30 PM, Tomasz Figa wrote:
>but it's possible the probe failed after calling iommu_device_set_fwnode, so
>i'll try to add some checks here, and maybe adjust probe() to prevent it
>too.
I think iommu_device_set_fwnode() is not enough for of_iommu_xlate()
to find the IOMMU. The IOM
Hi Tomasz,
On 01/17/2018 03:38 PM, Tomasz Figa wrote:
>>Don't we need to check here (and in _shutdown() too) if we have a
>>domain attached?
>
>hmmm, right, the startup might been called by resume, so should check
>iommu->domain here.
>
>but the shutdown would be called at the end of detach or
Hi Tomasz,
On 01/17/2018 03:52 PM, JeffyChen wrote:
Hi Tomasz,
On 01/17/2018 03:38 PM, Tomasz Figa wrote:
>>Don't we need to check here (and in _shutdown() too) if we have a
>>domain attached?
>
>hmmm, right, the startup might been called by resume, so should ch
Hi Robin,
On 01/17/2018 08:18 PM, Robin Murphy wrote:
@@ -91,7 +92,6 @@ struct rk_iommu {
void __iomem **bases;
int num_mmu;
int *irq;
Nit: irq seems to be redundant now as well.
oops, will fix it.
-int num_irq;
bool reset_disabled;
struct iommu_device io
Hi Robin,
On 01/17/2018 08:31 PM, Robin Murphy wrote:
On 16/01/18 13:25, Jeffy Chen wrote:
IOMMU drivers are supposed to call this function instead of manually
creating a group in their .add_device callback. This behavior is not
strictly required by ARM DMA mapping implementation, but ARM64 alr
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
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
drivers/iommu/rockchip-
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 can
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 rk_iommu_prob
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 100
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(&rk_domain->iommus_loc
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
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, a
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
>Chan
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 han
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 di
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 : IRQF_TRIGGE
+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 val
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?
That
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 coll
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
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 insertion
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
>
> arch/arm/mach-rockchip
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
name("scm_con
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 unnecessary,
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 d
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
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 the
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, wh
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 really
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
'
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
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
>cases.
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 drm_co
bind/unbind.
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 E
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:
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_
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
Acked-
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:
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/ rockchip_
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
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
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
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 Che
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 may
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,
>
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 +08
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 t
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
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 ala
Hi Martin,
Thanks for your reply.
On 12/29/2017 08:04 PM, Martin Kepplinger wrote:
On 2017-12-29 11:36, Jeffy Chen wrote:
Set current email address to replace previous employers email addresses.
Signed-off-by: Jeffy Chen
---
.mailmap | 1 +
1 file changed, 1 insertion(+)
diff --git a/.m
Hi Rafael,
Thanks for your reply :)
On 12/26/2017 08:11 AM, Rafael J. Wysocki wrote:
>+
>+ dn = pci_device_to_OF_node(ppdev);
>+ if (!dn)
>+ return 0;
>+
>+ irq = of_irq_get_byname(dn, "wakeup");
Why is this a property of the bridge and not of the device itself?
That is suggest
Hi Rob,
Thanks for your reply.
On 12/27/2017 07:56 AM, Rob Herring wrote:
>
> drivers/of/of_pci_irq.c | 49 +++
Please move this to drivers/pci/of.c (or perhaps create pci/of_irq.c).
> drivers/pci/Makefile | 1 +
> drivers/pci/pci-driver.c | 10 +++
> d
Hi Rafael and Rob,
Thanks for your reply.
On 12/27/2017 08:43 AM, Rafael J. Wysocki wrote:
On Wednesday, December 27, 2017 12:35:52 AM CET Rob Herring wrote:
>On Tue, Dec 26, 2017 at 10:36:42AM +0800, Jeffy Chen wrote:
> >We are going to handle PCIe WAKE# pin for PCI devices in the pci core,
65 matches
Mail list logo