* [PATCH 5/5] ARM: dts: dra7xx: Add stdout-path property
From: Lokesh Vutla @ 2017-01-17 4:03 UTC (permalink / raw)
To: Tony Lindgren, Linux OMAP Mailing List
Cc: Device Tree Mailing List, Rob Herring, Tero Kristo, Sekhar Nori,
Vignesh R, Nishanth Menon, Lokesh Vutla
In-Reply-To: <20170117040336.21700-1-lokeshvutla-l0cyMroinI0@public.gmane.org>
Add stdout-path property in /chosen node so that earlycon can be
used by just adding earlycon in bootargs.
Tested-by: Vignesh R <vigneshr-l0cyMroinI0@public.gmane.org>
Signed-off-by: Lokesh Vutla <lokeshvutla-l0cyMroinI0@public.gmane.org>
---
arch/arm/boot/dts/dra7-evm.dts | 4 ++++
arch/arm/boot/dts/dra72-evm-common.dtsi | 4 ++++
2 files changed, 8 insertions(+)
diff --git a/arch/arm/boot/dts/dra7-evm.dts b/arch/arm/boot/dts/dra7-evm.dts
index 132f2be10889..b3923c049edb 100644
--- a/arch/arm/boot/dts/dra7-evm.dts
+++ b/arch/arm/boot/dts/dra7-evm.dts
@@ -21,6 +21,10 @@
reg = <0x0 0x80000000 0x0 0x60000000>; /* 1536 MB */
};
+ chosen {
+ stdout-path = &uart1;
+ };
+
evm_3v3_sd: fixedregulator-sd {
compatible = "regulator-fixed";
regulator-name = "evm_3v3_sd";
diff --git a/arch/arm/boot/dts/dra72-evm-common.dtsi b/arch/arm/boot/dts/dra72-evm-common.dtsi
index e50fbeea96e0..45b62138cbde 100644
--- a/arch/arm/boot/dts/dra72-evm-common.dtsi
+++ b/arch/arm/boot/dts/dra72-evm-common.dtsi
@@ -18,6 +18,10 @@
display0 = &hdmi0;
};
+ chosen {
+ stdout-path = &uart1;
+ };
+
evm_12v0: fixedregulator-evm12v0 {
/* main supply */
compatible = "regulator-fixed";
--
2.11.0
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* RE: [PATCH 1/2] dt-bindings: document renesas-ostm timer
From: Chris Brandt @ 2017-01-17 4:16 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Rob Herring, Mark Rutland, Simon Horman, Magnus Damm,
Russell King, Daniel Lezcano, Thomas Gleixner, Geert Uytterhoeven,
devicetree@vger.kernel.org, Linux-Renesas
In-Reply-To: <CAMuHMdVC2BV6=jT1CZ+X92=_th-cEc0=hsiyRYxU5qMLoMVPMw@mail.gmail.com>
Hi Geert,
On Monday, January 16, 2017, Geert Uytterhoeven wrote:
> > Do you think it would be better if a driver instance only does 1
> > thing: Either 'clocksource' or 'clock event'??
> > Then, I would make 2 ostm nodes and pass in the mode I would like it
> operate in?
> >
> > For example:
> >
> > &ostm0 {
> > mode = "clocksource";
> > status = "okay";
> > };
> >
> > &ostm1 {
> > mode = "clock-event";
> > status = "okay";
> > };
>
> Again, that's software policy, not hardware description.
>
> As they're independent channels, it doesn't matter which one is used for
> which function, right?
Correct.
> You could use the first probed channel for the most important function
> (clocksource?), and the second one for the other function (clockevent).
> So there's no need for specifying this in DT.
>
> Does that make sense?
That works for me. I'll modify the driver and retest. Thanks for the idea!
Chris
^ permalink raw reply
* RE: [PATCH] ARM: dts: r7s72100: fix sdhi clock define
From: Chris Brandt @ 2017-01-17 4:27 UTC (permalink / raw)
To: Wolfram Sang, Geert Uytterhoeven
Cc: Simon Horman, Magnus Damm, Rob Herring, Mark Rutland,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Linux-Renesas,
Wolfram Sang
In-Reply-To: <20170116114023.GA3029@katana>
Hi Wolfram and Geert,
On Monday, January 16, 2017, Wolfram Sang:
> > > and then in the code do:
> > >
> > > struct *cd_clk;
> > > cd_clk = devm_clk_get(&pdev->dev, "cd");
> > > if (cd_clk) {
> > > clk_prepare_enable(cd_clk);
> > > }
> > >
> > > (this simple 1-line fix patch is getting a lot more complicated)
> >
> > Disclaimer: I don't know how/if the SDHI core manages clocks, and may
> > interfere. Adding Wolfram.
>
> Thanks for the heads up.
>
> We have special callbacks for en-/disabling clocks:
> sh_mobile_sdhi_clk_enable() and sh_mobile_sdhi_clk_disable().
>
> I think those functions should get the above if-blocks (without curly
> braces) to ensure we always have consistent 00 or 11 settings.
Well....
I was going to try and cheat and in the probe, enable both the core
and card-detect clocks, but, not save the card-detect clock pointer.
Basically, once it is turned on, it is never turned off (since it was intended
to be used for low power operation anyway).
The reason is that would then keep me from having to modify the existing
functions sh_mobile_sdhi_clk_enable/disable.
Is anyone going to have an issue if I turn the card-detect clock on but never
turn it off???? That was the patch that I was going to test out and submit.
Chris
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v11 05/12] drm/mediatek: add BLS component
From: CK Hu @ 2017-01-17 5:07 UTC (permalink / raw)
To: YT Shen
Cc: Mark Rutland, devicetree, srv_heupstream, emil.l.velikov,
linux-kernel, dri-devel, Rob Herring, linux-mediatek,
Matthias Brugger, yingjoe.chen, linux-arm-kernel
In-Reply-To: <1484117473-46644-6-git-send-email-yt.shen@mediatek.com>
Hi, YT:
On Wed, 2017-01-11 at 14:51 +0800, YT Shen wrote:
> Add BLS component for PWM + GAMMA function
>
> Signed-off-by: YT Shen <yt.shen@mediatek.com>
Acked-by: CK Hu <ck.hu@mediatek.com>
> ---
> drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 5 ++++-
> drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h | 2 ++
> 2 files changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> index 3ff788c..f6e853a 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> @@ -255,6 +255,7 @@ static void mtk_gamma_set(struct mtk_ddp_comp *comp,
> [MTK_DISP_PWM] = "pwm",
> [MTK_DISP_MUTEX] = "mutex",
> [MTK_DISP_OD] = "od",
> + [MTK_DISP_BLS] = "bls",
> };
>
> struct mtk_ddp_comp_match {
> @@ -265,6 +266,7 @@ struct mtk_ddp_comp_match {
>
> static const struct mtk_ddp_comp_match mtk_ddp_matches[DDP_COMPONENT_ID_MAX] = {
> [DDP_COMPONENT_AAL] = { MTK_DISP_AAL, 0, &ddp_aal },
> + [DDP_COMPONENT_BLS] = { MTK_DISP_BLS, 0, NULL },
> [DDP_COMPONENT_COLOR0] = { MTK_DISP_COLOR, 0, &ddp_color },
> [DDP_COMPONENT_COLOR1] = { MTK_DISP_COLOR, 1, &ddp_color },
> [DDP_COMPONENT_DPI0] = { MTK_DPI, 0, NULL },
> @@ -336,7 +338,8 @@ int mtk_ddp_comp_init(struct device *dev, struct device_node *node,
> comp->id = comp_id;
> comp->funcs = funcs ?: mtk_ddp_matches[comp_id].funcs;
>
> - if (comp_id == DDP_COMPONENT_DPI0 ||
> + if (comp_id == DDP_COMPONENT_BLS ||
> + comp_id == DDP_COMPONENT_DPI0 ||
> comp_id == DDP_COMPONENT_DSI0 ||
> comp_id == DDP_COMPONENT_PWM0) {
> comp->regs = NULL;
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
> index 22a33ee..0828cf8 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
> @@ -36,11 +36,13 @@ enum mtk_ddp_comp_type {
> MTK_DISP_PWM,
> MTK_DISP_MUTEX,
> MTK_DISP_OD,
> + MTK_DISP_BLS,
> MTK_DDP_COMP_TYPE_MAX,
> };
>
> enum mtk_ddp_comp_id {
> DDP_COMPONENT_AAL,
> + DDP_COMPONENT_BLS,
> DDP_COMPONENT_COLOR0,
> DDP_COMPONENT_COLOR1,
> DDP_COMPONENT_DPI0,
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [PATCH v11 06/12] drm/mediatek: update display module connections
From: CK Hu @ 2017-01-17 5:19 UTC (permalink / raw)
To: YT Shen
Cc: Mark Rutland, devicetree, srv_heupstream, emil.l.velikov,
linux-kernel, dri-devel, Rob Herring, linux-mediatek,
Matthias Brugger, yingjoe.chen, linux-arm-kernel
In-Reply-To: <1484117473-46644-7-git-send-email-yt.shen@mediatek.com>
Hi, YT:
On Wed, 2017-01-11 at 14:51 +0800, YT Shen wrote:
> update connections for OVL, RDMA, BLS, DSI
>
> Signed-off-by: YT Shen <yt.shen@mediatek.com>
Acked-by: CK Hu <ck.hu@mediatek.com>
> ---
> drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 25 +++++++++++++++++++++++++
> 1 file changed, 25 insertions(+)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> index b77d456..a9b209c 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> @@ -32,6 +32,10 @@
> #define DISP_REG_CONFIG_DISP_RDMA1_MOUT_EN 0x0c8
> #define DISP_REG_CONFIG_MMSYS_CG_CON0 0x100
>
> +#define DISP_REG_CONFIG_DISP_OVL_MOUT_EN 0x030
> +#define DISP_REG_CONFIG_OUT_SEL 0x04c
> +#define DISP_REG_CONFIG_DSI_SEL 0x050
> +
> #define DISP_REG_MUTEX_EN(n) (0x20 + 0x20 * (n))
> #define DISP_REG_MUTEX(n) (0x24 + 0x20 * (n))
> #define DISP_REG_MUTEX_RST(n) (0x28 + 0x20 * (n))
> @@ -71,6 +75,10 @@
> #define DPI0_SEL_IN_RDMA1 0x1
> #define COLOR1_SEL_IN_OVL1 0x1
>
> +#define OVL_MOUT_EN_RDMA 0x1
> +#define BLS_TO_DSI_RDMA1_TO_DPI1 0x8
> +#define DSI_SEL_IN_BLS 0x0
> +
> struct mtk_disp_mutex {
> int id;
> bool claimed;
> @@ -111,6 +119,9 @@ static unsigned int mtk_ddp_mout_en(enum mtk_ddp_comp_id cur,
> if (cur == DDP_COMPONENT_OVL0 && next == DDP_COMPONENT_COLOR0) {
> *addr = DISP_REG_CONFIG_DISP_OVL0_MOUT_EN;
> value = OVL0_MOUT_EN_COLOR0;
> + } else if (cur == DDP_COMPONENT_OVL0 && next == DDP_COMPONENT_RDMA0) {
> + *addr = DISP_REG_CONFIG_DISP_OVL_MOUT_EN;
> + value = OVL_MOUT_EN_RDMA;
> } else if (cur == DDP_COMPONENT_OD && next == DDP_COMPONENT_RDMA0) {
> *addr = DISP_REG_CONFIG_DISP_OD_MOUT_EN;
> value = OD_MOUT_EN_RDMA0;
> @@ -148,6 +159,9 @@ static unsigned int mtk_ddp_sel_in(enum mtk_ddp_comp_id cur,
> } else if (cur == DDP_COMPONENT_OVL1 && next == DDP_COMPONENT_COLOR1) {
> *addr = DISP_REG_CONFIG_DISP_COLOR1_SEL_IN;
> value = COLOR1_SEL_IN_OVL1;
> + } else if (cur == DDP_COMPONENT_BLS && next == DDP_COMPONENT_DSI0) {
> + *addr = DISP_REG_CONFIG_DSI_SEL;
> + value = DSI_SEL_IN_BLS;
> } else {
> value = 0;
> }
> @@ -155,6 +169,15 @@ static unsigned int mtk_ddp_sel_in(enum mtk_ddp_comp_id cur,
> return value;
> }
>
> +static void mtk_ddp_sout_sel(void __iomem *config_regs,
> + enum mtk_ddp_comp_id cur,
> + enum mtk_ddp_comp_id next)
> +{
> + if (cur == DDP_COMPONENT_BLS && next == DDP_COMPONENT_DSI0)
> + writel_relaxed(BLS_TO_DSI_RDMA1_TO_DPI1,
> + config_regs + DISP_REG_CONFIG_OUT_SEL);
> +}
> +
> void mtk_ddp_add_comp_to_path(void __iomem *config_regs,
> enum mtk_ddp_comp_id cur,
> enum mtk_ddp_comp_id next)
> @@ -167,6 +190,8 @@ void mtk_ddp_add_comp_to_path(void __iomem *config_regs,
> writel_relaxed(reg, config_regs + addr);
> }
>
> + mtk_ddp_sout_sel(config_regs, cur, next);
> +
> value = mtk_ddp_sel_in(cur, next, &addr);
> if (value) {
> reg = readl_relaxed(config_regs + addr) | value;
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [PATCH] pcie: ti: Provide patch to force GEN1 PCIe operation
From: Kishon Vijay Abraham I @ 2017-01-17 5:35 UTC (permalink / raw)
To: Joao Pinto, Lukasz Majewski,
jingoohan1-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
Cc: Bjorn Helgaas, Rob Herring, Mark Rutland,
linux-omap-u79uwXL29TY76Z2rM5mHXA,
linux-pci-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <76d18446-78c9-87f2-22ad-f7ea38771285-HKixBCOQz3hWk0Htik3J/w@public.gmane.org>
Hi Joao,
On Monday 16 January 2017 10:31 PM, Joao Pinto wrote:
>
> Hi,
>
> Às 10:13 AM de 1/16/2017, Kishon Vijay Abraham I escreveu:
>> + Joao, Jingoo
>>
>> Hi,
>>
>> On Monday 16 January 2017 03:01 PM, Lukasz Majewski wrote:
>>> Hi Kishon,
>>>
>>>> Hi Łukasz,
>>>>
>>>> On Monday 16 January 2017 12:19 PM, Lukasz Majewski wrote:
>>>>> Hi Kishon,
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> On Sunday 15 January 2017 06:49 PM, Lukasz Majewski wrote:
>>>>>>> Some devices (due to e.g. bad PCIe signal integrity) require to
>>>>>>> run with forced GEN1 speed on PCIe bus.
>>>>>>>
>>>>>>> This patch changes the speed explicitly on dra7 based devices when
>>>>>>> proper device tree attribute is defined for the PCIe controller.
>>>>>>>
>>>>>>> Signed-off-by: Lukasz Majewski <lukma-ynQEQJNshbs@public.gmane.org>
>>>>>>
>>>>>> Bjorn has already queued a patch to do the same thing
>>>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__git.kernel.org_cgit_linux_kernel_git_helgaas_pci.git_log_-3Fh-3Dpci_host-2Ddra7xx&d=DwIDaQ&c=DPL6_X_6JkXFx7AXWqB0tg&r=s2fO0hii0OGNOv9qQy_HRXy-xAJUD1NNoEcc3io_kx0&m=zD82T5n4WcL7Ga-NSY2NI7KE75xQ99hN-mW2yX46wQk&s=E8zk1CbKxGH-f3fw_WpXxFU-A8BLkgA8NusCaxk1SvA&e=
>>>>>
>>>>> It seems like Bjorn only modifies CAP registers.
>>>>
>>>> The patch also modifies the LNKCTL2 register.
>>>>>
>>>>> He also needs to change register with 0x080C offset to actually
>>>>> ( PCIECTRL_PL_WIDTH_SPEED_CTL )
>>>>
>>>> This bit is used to initiate speed change (after the link is
>>>> initialized in GEN1). Resetting the bit (like what you have done
>>>> here) prevents speed change.
>>>
>>> This is strange, but e2e advised me to do things as I did in the patch
>>> to _force_ GEN1 operation on PCIe2 port [1] (AM5728)
>>>
>>> Link:
>>> [1] https://urldefense.proofpoint.com/v2/url?u=https-3A__e2e.ti.com_support_arm_sitara-5Farm_f_791_t_566421&d=DwIDaQ&c=DPL6_X_6JkXFx7AXWqB0tg&r=s2fO0hii0OGNOv9qQy_HRXy-xAJUD1NNoEcc3io_kx0&m=zD82T5n4WcL7Ga-NSY2NI7KE75xQ99hN-mW2yX46wQk&s=uXLwglyRYqKpwp1JSxkOWmKpQ2wjfhgofpm8DCfquNw&e=
>>>
>>> Both patches modify 0x5180 007C register to set GEN1 capability
>>> (PCI_EXP_LNKCAP_SLS_2_5GB)
>>>
>>> The problem is with second register (in your patch):
>>>
>>> From SPRUHZ6G TRM:
>>>
>>> PCIECTRL_EP_DBICS_LNK_CAS_2 (0x5180 00A0)
>>> - TRGT_LINK_SPEED (Reset 0x1) - "Target Link Speed" - no more
>>> description in TRM
>>>
>>> It is set to PCI_EXP_LNKCAP_SLS_2_5GB = 0x1, which is the same as
>>> default /reset value.
>>
>> The default value is 0x2 (or else none of the cards would have enumerated in GEN2)
>>>
>>>
>>> Could you clarify which way to _force_ PCIe GEN1 operation is correct?
>>> Mine shows differences in lspci output (as posted in [1]).
>>
>> You'll see the difference even with the patch in Bjorn's tree ;-)
>>
>> I think these are 2 different approaches to keep the link at GEN1. Joao or
>> Jingoo, do you have any suggestion here?
>
> I studied the Databook, and both approaches seem to be right, dependently of the
> Core configuration and setup.
>
> The standard manual speed change sequence is:
> a) Write to PCIE_CAP_TARGET_LINK_SPEED (indicating desired speed)
> b) Clear "Directed Speed Change"
> c) Set "Directed Speed Change"
>
> If "Directed Speed Change" is set (DEFAULT_GEN2_SPEED_CHANGE is the default
> value), it will execute LTSSM to initiate speed change to Gen2 or Gen3, after
> link is started in Gen1, and then the bit is automatically cleared.
>
> Lukasz is reseting this bit, in order to avoid the LTSSM to be executed, which
> is correct. There is another way to prevent this automatic speed change, which
> is to set GEN1 speed before link up which might be difficult in some setups, so
> Kishon's also right.
Just for my understanding, why do you think this will be difficult in some setups?
>
> In my opinion Lukasz approach would be the one that might be more universal and
> more "secure".
IMHO setting link control in the standard PCIe header space should be more
universal. I'm not sure about the secure part though.
Thanks
Kishon
>
> Joao
>
>
>>
>>>
>>>>
>>>> IMO the better way is to set the LNKCTL2 to GEN1 instead of hacking
>>>> the IP register.
>>>
>>> From the original patch description:
>>>
>>> "Add support to force Root Complex to work in GEN1 mode if so desired,
>>> but don't force GEN1 mode on any board just yet."
>>>
>>> Are there any (floating around) patches allowing forcing GEN1 operation
>>> on any board (I would like to reuse/port them to my current solution)?
>>
>> For setting to GEN1 mode, "max-link-speed" should be set to 1 in dt with the
>> patch in Bjorn's tree.
>>
>> Thanks
>> Kishon
>>
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH v7 0/3] Add touch key driver support for TM2
From: Jaechul Lee @ 2017-01-17 5:54 UTC (permalink / raw)
To: Dmitry Torokhov, Rob Herring, Mark Rutland, Catalin Marinas,
Will Deacon, Kukjin Kim, Krzysztof Kozlowski,
Javier Martinez Canillas
Cc: Jaechul Lee, Andi Shyti, Chanwoo Choi,
beomho.seo-Sze3O3UU22JBDgjK7y7TUQ,
galaxyra-Re5JQEeQqe8AvxtiuMwx3w,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-input-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-samsung-soc-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <CGME20170117055443epcas1p40b08d361f8f95090ad7b4d855a5bfad4@epcas1p4.samsung.com>
Hi,
This patch is last three patch from https://lkml.org/lkml/2017/1/6/277.
because 1 and 2 patches have already been merged by Krzysztof.
This patchset adds support for the tm2 touchkey device.
The driver has been ported from Tizen Kernel, originally written
by Beomho. I ported it to the latest mainline Kernel.
Best Regard,
Jaechul
Changes in v7
- added Chanwoo's reviewed and tested.
- fixed reviews from Dmitry.
Changes in v6:
- changed compatible name from samsaung to cypress.
- updated commit tags.
- removed first two patches from the original patchset.
Changes in v5:
- patch 1: removed a spurious regulator-always-off inherited from
a different patch. Thanks Krzysztof.
- patch 2: fixed a slip on the model, thanks Javier (this patch
confuses me quite a lot, this was all right some patches ago
and re appeared on this one).
- patch 2: removed 'regulator' label and used the original ldo3x
labels. Krzysztof: it looks better indeed.
- added Javier's reviews and Krzysztof's acks on the related
patches.
Changes in v4:
- patch 1 has been rebased on top of 7c294e002641 (arm64: dts:
exynos: Remove unsupported regulator-always-off property from
TM2E)
- patch 2 has been generated with -B50% diff option using git
2.11
Changes in v3:
- Changed the commit ordering, the tm2-touchkey related patches
are the last 3.
- Added Chanwoo's patch which fixes the wrong voltage of ldo23
and ldo25.
- Andi (patch 3) moves the ldo31 and ldo38 in the tm2 and tm2e
files as they have different values.
Changes in v2:
- fixed reviews from Javier, Dmitry
- refactored power enable/disable functions.
- reordered signed-offs in patch 2, while patch 4 is left as it
was as Andi copy pasted the node to the new tm2.dts file
- added Jarvier's (patch 1,2,4) and Krzysztof's (patch 4)
reviews
and Rob's Ack
- patch 3 diff has been generated with -B50%
Jaechul Lee (3):
input: Add support for the tm2 touchkey device driver
input: tm2-touchkey: Add touchkey driver support for TM2
arm64: dts: exynos: Add tm2 touchkey node
.../bindings/input/cypress,tm2-touchkey.txt | 27 ++
arch/arm64/boot/dts/exynos/exynos5433-tm2.dts | 13 +
drivers/input/keyboard/Kconfig | 11 +
drivers/input/keyboard/Makefile | 1 +
drivers/input/keyboard/tm2-touchkey.c | 287 +++++++++++++++++++++
5 files changed, 339 insertions(+)
create mode 100644 Documentation/devicetree/bindings/input/cypress,tm2-touchkey.txt
create mode 100644 drivers/input/keyboard/tm2-touchkey.c
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH v7 1/3] input: Add support for the tm2 touchkey device driver
From: Jaechul Lee @ 2017-01-17 5:54 UTC (permalink / raw)
To: Dmitry Torokhov, Rob Herring, Mark Rutland, Catalin Marinas,
Will Deacon, Kukjin Kim, Krzysztof Kozlowski,
Javier Martinez Canillas
Cc: Jaechul Lee, Andi Shyti, Chanwoo Choi,
beomho.seo-Sze3O3UU22JBDgjK7y7TUQ,
galaxyra-Re5JQEeQqe8AvxtiuMwx3w,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-input-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-samsung-soc-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1484632479-3111-1-git-send-email-jcsing.lee-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
This patch adds the binding description of the tm2 touchkey
device driver.
Signed-off-by: Jaechul Lee <jcsing.lee-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
Reviewed-by: Javier Martinez Canillas <javier-JPH+aEBZ4P+UEJcrhfAQsw@public.gmane.org>
Reviewed-by: Andi Shyti <andi.shyti-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
Reviewed-by: Chanwoo Choi <cw00.choi-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Acked-by: Krzysztof Kozlowski <krzk-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
---
.../bindings/input/cypress,tm2-touchkey.txt | 27 ++++++++++++++++++++++
1 file changed, 27 insertions(+)
create mode 100644 Documentation/devicetree/bindings/input/cypress,tm2-touchkey.txt
diff --git a/Documentation/devicetree/bindings/input/cypress,tm2-touchkey.txt b/Documentation/devicetree/bindings/input/cypress,tm2-touchkey.txt
new file mode 100644
index 0000000..635f62c
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/cypress,tm2-touchkey.txt
@@ -0,0 +1,27 @@
+Samsung tm2-touchkey
+
+Required properties:
+- compatible: must be "cypress,tm2-touchkey"
+- reg: I2C address of the chip.
+- interrupt-parent: a phandle for the interrupt controller (see interrupt
+ binding[0]).
+- interrupts: interrupt to which the chip is connected (see interrupt
+ binding[0]).
+- vcc-supply : internal regulator output. 1.8V
+- vdd-supply : power supply for IC 3.3V
+
+[0]: Documentation/devicetree/bindings/interrupt-controller/interrupts.txt
+
+Example:
+ &i2c0 {
+ /* ... */
+
+ touchkey@20 {
+ compatible = "cypress,tm2-touchkey";
+ reg = <0x20>;
+ interrupt-parent = <&gpa3>;
+ interrupts = <2 IRQ_TYPE_EDGE_FALLING>;
+ vcc-supply=<&ldo32_reg>;
+ vdd-supply=<&ldo33_reg>;
+ };
+ };
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH v7 2/3] input: tm2-touchkey: Add touchkey driver support for TM2
From: Jaechul Lee @ 2017-01-17 5:54 UTC (permalink / raw)
To: Dmitry Torokhov, Rob Herring, Mark Rutland, Catalin Marinas,
Will Deacon, Kukjin Kim, Krzysztof Kozlowski,
Javier Martinez Canillas
Cc: Jaechul Lee, Andi Shyti, Chanwoo Choi, beomho.seo, galaxyra,
linux-arm-kernel, linux-input, devicetree, linux-kernel,
linux-samsung-soc
In-Reply-To: <1484632479-3111-1-git-send-email-jcsing.lee@samsung.com>
This patch adds support for the TM2 touch key and led
functionality.
The driver interfaces with userspace through an input device and
reports KEY_PHONE and KEY_BACK event types. LED brightness can be
controlled by "/sys/class/leds/tm2-touchkey/brightness".
Signed-off-by: Beomho Seo <beomho.seo@samsung.com>
Signed-off-by: Jaechul Lee <jcsing.lee@samsung.com>
Reviewed-by: Javier Martinez Canillas <javier@osg.samsung.com>
Reviewed-by: Andi Shyti <andi.shyti@samsung.com>
Reviewed-by: Chanwoo Choi <cw00.choi@samsung.com>
Tested-by: Chanwoo Choi <cw00.choi@samsung.com>
Acked-by: Krzysztof Kozlowski <krzk@kernel.org>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
---
drivers/input/keyboard/Kconfig | 11 ++
drivers/input/keyboard/Makefile | 1 +
drivers/input/keyboard/tm2-touchkey.c | 286 ++++++++++++++++++++++++++++++++++
3 files changed, 298 insertions(+)
create mode 100644 drivers/input/keyboard/tm2-touchkey.c
diff --git a/drivers/input/keyboard/Kconfig b/drivers/input/keyboard/Kconfig
index cbd75cf..97acd65 100644
--- a/drivers/input/keyboard/Kconfig
+++ b/drivers/input/keyboard/Kconfig
@@ -666,6 +666,17 @@ config KEYBOARD_TC3589X
To compile this driver as a module, choose M here: the
module will be called tc3589x-keypad.
+config KEYBOARD_TM2_TOUCHKEY
+ tristate "TM2 touchkey support"
+ depends on I2C
+ depends on LEDS_CLASS
+ help
+ Say Y here to enable device driver for tm2-touchkey with
+ LED control for the Exynos5433 TM2 board.
+
+ To compile this driver as a module, choose M here.
+ module will be called tm2-touchkey.
+
config KEYBOARD_TWL4030
tristate "TI TWL4030/TWL5030/TPS659x0 keypad support"
depends on TWL4030_CORE
diff --git a/drivers/input/keyboard/Makefile b/drivers/input/keyboard/Makefile
index d9f4cfc..7d9acff 100644
--- a/drivers/input/keyboard/Makefile
+++ b/drivers/input/keyboard/Makefile
@@ -61,6 +61,7 @@ obj-$(CONFIG_KEYBOARD_SUN4I_LRADC) += sun4i-lradc-keys.o
obj-$(CONFIG_KEYBOARD_SUNKBD) += sunkbd.o
obj-$(CONFIG_KEYBOARD_TC3589X) += tc3589x-keypad.o
obj-$(CONFIG_KEYBOARD_TEGRA) += tegra-kbc.o
+obj-$(CONFIG_KEYBOARD_TM2_TOUCHKEY) += tm2-touchkey.o
obj-$(CONFIG_KEYBOARD_TWL4030) += twl4030_keypad.o
obj-$(CONFIG_KEYBOARD_XTKBD) += xtkbd.o
obj-$(CONFIG_KEYBOARD_W90P910) += w90p910_keypad.o
diff --git a/drivers/input/keyboard/tm2-touchkey.c b/drivers/input/keyboard/tm2-touchkey.c
new file mode 100644
index 0000000..916e2f3
--- /dev/null
+++ b/drivers/input/keyboard/tm2-touchkey.c
@@ -0,0 +1,286 @@
+/*
+ * TM2 touchkey device driver
+ *
+ * Copyright 2005 Phil Blundell
+ * Copyright 2016 Samsung Electronics Co., Ltd.
+ *
+ * Author: Beomho Seo <beomho.seo@samsung.com>
+ * Author: Jaechul Lee <jcsing.lee@samsung.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include <linux/bitops.h>
+#include <linux/delay.h>
+#include <linux/device.h>
+#include <linux/i2c.h>
+#include <linux/input.h>
+#include <linux/interrupt.h>
+#include <linux/irq.h>
+#include <linux/leds.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/pm.h>
+#include <linux/regulator/consumer.h>
+
+#define TM2_TOUCHKEY_DEV_NAME "tm2-touchkey"
+#define TM2_TOUCHKEY_KEYCODE_REG 0x03
+#define TM2_TOUCHKEY_BASE_REG 0x00
+#define TM2_TOUCHKEY_CMD_LED_ON 0x10
+#define TM2_TOUCHKEY_CMD_LED_OFF 0x20
+#define TM2_TOUCHKEY_BIT_PRESS_EV BIT(3)
+#define TM2_TOUCHKEY_BIT_KEYCODE GENMASK(2, 0)
+#define TM2_TOUCHKEY_LED_VOLTAGE_MIN 2500000
+#define TM2_TOUCHKEY_LED_VOLTAGE_MAX 3300000
+
+enum {
+ TM2_TOUCHKEY_KEY_MENU = 0x1,
+ TM2_TOUCHKEY_KEY_BACK,
+};
+
+struct tm2_touchkey_data {
+ struct i2c_client *client;
+ struct input_dev *input_dev;
+ struct led_classdev led_dev;
+ struct regulator *vdd;
+ struct regulator_bulk_data regulators[2];
+};
+
+static void tm2_touchkey_led_brightness_set(struct led_classdev *led_dev,
+ enum led_brightness brightness)
+{
+ struct tm2_touchkey_data *touchkey =
+ container_of(led_dev, struct tm2_touchkey_data, led_dev);
+ u32 volt;
+ u8 data;
+
+ if (brightness == LED_OFF) {
+ volt = TM2_TOUCHKEY_LED_VOLTAGE_MIN;
+ data = TM2_TOUCHKEY_CMD_LED_OFF;
+ } else {
+ volt = TM2_TOUCHKEY_LED_VOLTAGE_MAX;
+ data = TM2_TOUCHKEY_CMD_LED_ON;
+ }
+
+ regulator_set_voltage(touchkey->vdd, volt, volt);
+ i2c_smbus_write_byte_data(touchkey->client,
+ TM2_TOUCHKEY_BASE_REG, data);
+}
+
+static int tm2_touchkey_power_enable(struct tm2_touchkey_data *touchkey)
+{
+ int error;
+
+ error = regulator_bulk_enable(ARRAY_SIZE(touchkey->regulators),
+ touchkey->regulators);
+ if (error)
+ return error;
+
+ /* waiting for device initialization, at least 150ms */
+ msleep(150);
+
+ return 0;
+}
+
+static void tm2_touchkey_power_disable(void *data)
+{
+ struct tm2_touchkey_data *touchkey = data;
+
+ regulator_bulk_disable(ARRAY_SIZE(touchkey->regulators),
+ touchkey->regulators);
+}
+
+static irqreturn_t tm2_touchkey_irq_handler(int irq, void *devid)
+{
+ struct tm2_touchkey_data *touchkey = devid;
+ int data;
+ int key;
+
+ data = i2c_smbus_read_byte_data(touchkey->client,
+ TM2_TOUCHKEY_KEYCODE_REG);
+ if (data < 0) {
+ dev_err(&touchkey->client->dev,
+ "failed to read i2c data: %d\n", data);
+ goto out;
+ }
+
+ switch (data & TM2_TOUCHKEY_BIT_KEYCODE) {
+ case TM2_TOUCHKEY_KEY_MENU:
+ key = KEY_PHONE;
+ break;
+
+ case TM2_TOUCHKEY_KEY_BACK:
+ key = KEY_BACK;
+ break;
+
+ default:
+ dev_warn(&touchkey->client->dev,
+ "unhandled keycode, data %#02x\n", data);
+ goto out;
+ }
+
+ if (data & TM2_TOUCHKEY_BIT_PRESS_EV) {
+ input_report_key(touchkey->input_dev, KEY_PHONE, 0);
+ input_report_key(touchkey->input_dev, KEY_BACK, 0);
+ } else {
+ input_report_key(touchkey->input_dev, key, 1);
+ }
+
+ input_sync(touchkey->input_dev);
+
+out:
+ return IRQ_HANDLED;
+}
+
+static int tm2_touchkey_probe(struct i2c_client *client,
+ const struct i2c_device_id *id)
+{
+ struct tm2_touchkey_data *touchkey;
+ int error;
+
+ if (!i2c_check_functionality(client->adapter,
+ I2C_FUNC_SMBUS_BYTE | I2C_FUNC_SMBUS_BYTE_DATA)) {
+ dev_err(&client->dev, "incompatible I2C adapter\n");
+ return -EIO;
+ }
+
+ touchkey = devm_kzalloc(&client->dev, sizeof(*touchkey), GFP_KERNEL);
+ if (!touchkey)
+ return -ENOMEM;
+
+ touchkey->client = client;
+ i2c_set_clientdata(client, touchkey);
+
+ touchkey->regulators[0].supply = "vcc";
+ touchkey->regulators[1].supply = "vdd";
+ error = devm_regulator_bulk_get(&client->dev,
+ ARRAY_SIZE(touchkey->regulators),
+ touchkey->regulators);
+ if (error) {
+ dev_err(&client->dev, "failed to get regulators: %d\n", error);
+ return error;
+ }
+
+ /* Save VDD for easy access */
+ touchkey->vdd = touchkey->regulators[1].consumer;
+
+ error = tm2_touchkey_power_enable(touchkey);
+ if (error) {
+ dev_err(&client->dev, "failed to power up device: %d\n", error);
+ return error;
+ }
+
+ error = devm_add_action_or_reset(&client->dev,
+ tm2_touchkey_power_disable, touchkey);
+ if (error) {
+ dev_err(&client->dev,
+ "failed to install poweroff handler: %d\n", error);
+ return error;
+ }
+
+ /* input device */
+ touchkey->input_dev = devm_input_allocate_device(&client->dev);
+ if (!touchkey->input_dev) {
+ dev_err(&client->dev, "failed to allocate input device\n");
+ return -ENOMEM;
+ }
+
+ touchkey->input_dev->name = TM2_TOUCHKEY_DEV_NAME;
+ touchkey->input_dev->id.bustype = BUS_I2C;
+
+ input_set_capability(touchkey->input_dev, EV_KEY, KEY_PHONE);
+ input_set_capability(touchkey->input_dev, EV_KEY, KEY_BACK);
+
+ input_set_drvdata(touchkey->input_dev, touchkey);
+
+ error = input_register_device(touchkey->input_dev);
+ if (error) {
+ dev_err(&client->dev,
+ "failed to register input device: %d\n", error);
+ return error;
+ }
+
+ error = devm_request_threaded_irq(&client->dev, client->irq,
+ NULL, tm2_touchkey_irq_handler,
+ IRQF_ONESHOT,
+ TM2_TOUCHKEY_DEV_NAME, touchkey);
+ if (error) {
+ dev_err(&client->dev,
+ "failed to request threaded irq: %d\n", error);
+ return error;
+ }
+
+ /* led device */
+ touchkey->led_dev.name = TM2_TOUCHKEY_DEV_NAME;
+ touchkey->led_dev.brightness = LED_FULL;
+ touchkey->led_dev.max_brightness = LED_FULL;
+ touchkey->led_dev.brightness_set = tm2_touchkey_led_brightness_set;
+
+ error = devm_led_classdev_register(&client->dev, &touchkey->led_dev);
+ if (error) {
+ dev_err(&client->dev,
+ "failed to register touchkey led: %d\n", error);
+ return error;
+ }
+
+ return 0;
+}
+
+static int __maybe_unused tm2_touchkey_suspend(struct device *dev)
+{
+ struct i2c_client *client = to_i2c_client(dev);
+ struct tm2_touchkey_data *touchkey = i2c_get_clientdata(client);
+
+ disable_irq(client->irq);
+ tm2_touchkey_power_disable(touchkey);
+
+ return 0;
+}
+
+static int __maybe_unused tm2_touchkey_resume(struct device *dev)
+{
+ struct i2c_client *client = to_i2c_client(dev);
+ struct tm2_touchkey_data *touchkey = i2c_get_clientdata(client);
+ int ret;
+
+ enable_irq(client->irq);
+
+ ret = tm2_touchkey_power_enable(touchkey);
+ if (ret)
+ dev_err(dev, "failed to enable power: %d\n", ret);
+
+ return ret;
+}
+
+static SIMPLE_DEV_PM_OPS(tm2_touchkey_pm_ops,
+ tm2_touchkey_suspend, tm2_touchkey_resume);
+
+static const struct i2c_device_id tm2_touchkey_id_table[] = {
+ { TM2_TOUCHKEY_DEV_NAME, 0 },
+ { },
+};
+MODULE_DEVICE_TABLE(i2c, tm2_touchkey_id_table);
+
+static const struct of_device_id tm2_touchkey_of_match[] = {
+ { .compatible = "cypress,tm2-touchkey", },
+ { },
+};
+MODULE_DEVICE_TABLE(of, tm2_touchkey_of_match);
+
+static struct i2c_driver tm2_touchkey_driver = {
+ .driver = {
+ .name = TM2_TOUCHKEY_DEV_NAME,
+ .pm = &tm2_touchkey_pm_ops,
+ .of_match_table = of_match_ptr(tm2_touchkey_of_match),
+ },
+ .probe = tm2_touchkey_probe,
+ .id_table = tm2_touchkey_id_table,
+};
+module_i2c_driver(tm2_touchkey_driver);
+
+MODULE_AUTHOR("Beomho Seo <beomho.seo@samsung.com>");
+MODULE_AUTHOR("Jaechul Lee <jcsing.lee@samsung.com>");
+MODULE_DESCRIPTION("Samsung touchkey driver");
+MODULE_LICENSE("GPL v2");
--
2.7.4
^ permalink raw reply related
* [PATCH v7 3/3] arm64: dts: exynos: Add tm2 touchkey node
From: Jaechul Lee @ 2017-01-17 5:54 UTC (permalink / raw)
To: Dmitry Torokhov, Rob Herring, Mark Rutland, Catalin Marinas,
Will Deacon, Kukjin Kim, Krzysztof Kozlowski,
Javier Martinez Canillas
Cc: Jaechul Lee, Andi Shyti, Chanwoo Choi, beomho.seo, galaxyra,
linux-arm-kernel, linux-input, devicetree, linux-kernel,
linux-samsung-soc
In-Reply-To: <1484632479-3111-1-git-send-email-jcsing.lee@samsung.com>
Add DT node support for TM2 touchkey device.
Signed-off-by: Beomho Seo <beomho.seo@samsung.com>
Signed-off-by: Jaechul Lee <jcsing.lee@samsung.com>
Signed-off-by: Andi Shyti <andi.shyti@samsung.com>
Reviewed-by: Javier Martinez Canillas <javier@osg.samsung.com>
---
arch/arm64/boot/dts/exynos/exynos5433-tm2.dts | 13 +++++++++++++
1 file changed, 13 insertions(+)
diff --git a/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts b/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
index 2449266..ddba2f8 100644
--- a/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
+++ b/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
@@ -18,6 +18,19 @@
compatible = "samsung,tm2", "samsung,exynos5433";
};
+&hsi2c_9 {
+ status = "okay";
+
+ touchkey@20 {
+ compatible = "cypress,tm2-touchkey";
+ reg = <0x20>;
+ interrupt-parent = <&gpa3>;
+ interrupts = <2 IRQ_TYPE_EDGE_FALLING>;
+ vcc-supply = <&ldo32_reg>;
+ vdd-supply = <&ldo33_reg>;
+ };
+};
+
&ldo31_reg {
regulator-name = "TSP_VDD_1.85V_AP";
regulator-min-microvolt = <1850000>;
--
2.7.4
^ permalink raw reply related
* Re: [PATCH v4] ARM64: dts: meson-gx: Add reserved memory zone and usable memory range
From: Olof Johansson @ 2017-01-17 6:07 UTC (permalink / raw)
To: Neil Armstrong
Cc: Andreas Färber, Kevin Hilman, devicetree@vger.kernel.org,
xypron.glpk, linux-kernel@vger.kernel.org, Carlo Caione,
linux-amlogic, linux-arm-kernel@lists.infradead.org
In-Reply-To: <7fcb8d94-840a-de2c-f43b-9123ccc65514@baylibre.com>
On Mon, Jan 16, 2017 at 2:39 AM, Neil Armstrong <narmstrong@baylibre.com> wrote:
> On 01/15/2017 03:43 PM, Andreas Färber wrote:
>> Am 13.01.2017 um 21:03 schrieb Kevin Hilman:
>>> Neil Armstrong <narmstrong@baylibre.com> writes:
>>>
>>>> The Amlogic Meson GXBB/GXL/GXM secure monitor uses part of the memory space,
>>>> this patch adds this reserved zone and redefines the usable memory range.
>>>>
>>>> The memory node is also moved from the dtsi files into the proper dts files
>>>> to handle variants memory sizes.
>>>>
>>>> This patch also fixes the memory sizes for the following platforms :
>>>> - gxl-s905x-p212 : 1GiB instead of 2GiB, a proper 2GiB dts should be pushed
>>>> - gxm-s912-q201 : 1GiB instead of 2GiB, a proper 2GiB dts should be pushed
>>>> - gxl-s905d-p231 : 1GiB instead of 2GiB, a proper 2GiB dts should be pushed
>>>> - gxl-nexbox-a95x : 1GiB instead of 2GiB, a proper 2GiB dts should be pushed
>>>>
>>>> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
>>>
>>> Queued for v4.10-rc.
>>
>> What is the motivation for this change? I have a local U-Boot patch to
>> detect the amount of memory available as done downstream, but U-Boot
>> only updates the reg property that you seem to be abandoning here...
>>
>> So for devices that come in multiple RAM configurations - like R-Box Pro
>> - this would require separate .dts files now! This looks very wrong to
>> me, especially since I am not aware of other platforms doing the same.
>> Instead, there's memory reservations for top and bottom done in U-Boot
>> for reg, plus reserved-memory nodes for anything in the middle.
>>
>> Another thing to consider is that uEFI boot (bootefi) handles memory
>> reservation differently yet again, on the bootloader level. I have had
>> that working fine on Odroid-C2 and Vega S95.
>>
>> So if there's no bug this is fixing (none mentioned in commit message) I
>> strongly object to this patch.
>>
>> Regards,
>> Andreas
>>
>
> Hi Andreas,
>
> Like I replied of my RFT patch :
> I really disagree about relying on any work or properties added by any bootloader here, Amlogic SoCs has
> a lot of u-boot versions in the field, and the Odroid-C2 is part of this.
>
> Even if Odroid-c2 is in mainline U-Boot or not, the mainline Linux kernel should work using
> any U-boot version even with the one provided by Amlogic on their openlinux distribution channel.
>
> Handling multiple RAM configuration is another story, and the Arm-Soc and DT maintainers should give us
> their advices.
Is there a way to detect what firmware is running and marking off
memory from early kernel init instead? That'll take care of the
concerns about memory size variance as well.
> Actually there is a severe bug fixed here that cause a huge crash if such memory is not reserved while
> running stock u-boot version on various shipped products and Amlogic's own development boards.
>
> The bug is easily triggered by running :
> # stress --vm 4 --vm-bytes 128M --timeout 10s &
> [ 46.937975] Bad mode in Error handler detected on CPU1, code 0xbf000000 -- SError
> ...
> [ 47.058536] Internal error: Attempting to execute userspace memory: 8600000f [#3] PREEMPT SMP
> ...
>
> Note this is a fix targeted for 4.10 to make the system stable and various users reported some severe
> crash now the system has more drivers and read-world use-cases are running on Amlogic SoCs.
>
> Please feel free to push whatever changes that makes this memory reservation more coherent for 4.11,
> and respect the behavior of already shipped u-boot version and mainline U-Boot, UEFI, whatever...
Technically we're not in regression territory here, since the platform
is obviously still in bringup and these aren't bugs that have been
introduced in this release. So I think we can take a little while to
sort out if there's a solution that, even if not ideal, at least is on
the path towards the proper fix and not away from it -- which this
seems to be.
-Olof
^ permalink raw reply
* [PATCH] ahci: qoriq: added ls2088a platforms support
From: yuantian.tang @ 2017-01-17 6:12 UTC (permalink / raw)
To: tj
Cc: robh+dt, mark.rutland, linux-ide, devicetree, linux-kernel,
linux-arm-kernel, Tang Yuantian, Tang Yuantian
From: Tang Yuantian <Yuantian.Tang@nxp.com>
Ls2088a is new introduced arm-based soc with sata support with
following features:
1. Complies with the serial ATA 3.0 specification and the AHCI 1.3.1
specification
2. Contains a high-speed descriptor-based DMA controller
3. Supports the following:
a. Speeds of 1.5 Gb/s (first-generation SATA), 3 Gb/s
(second-generation SATA), and 6 Gb/s (third-generation SATA)
b. FIS-based switching
c. Native command queuing (NCQ) commands
d. Port multiplier operation
e. Asynchronous notification
f. SATA BIST mode
Signed-off-by: Tang Yuantian <yuantian.tang@nxp.com>
---
Documentation/devicetree/bindings/ata/ahci-fsl-qoriq.txt | 2 +-
drivers/ata/ahci_qoriq.c | 9 +++++++++
2 files changed, 10 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/ata/ahci-fsl-qoriq.txt b/Documentation/devicetree/bindings/ata/ahci-fsl-qoriq.txt
index fc33ca0..ed87c6f 100644
--- a/Documentation/devicetree/bindings/ata/ahci-fsl-qoriq.txt
+++ b/Documentation/devicetree/bindings/ata/ahci-fsl-qoriq.txt
@@ -3,7 +3,7 @@ Binding for Freescale QorIQ AHCI SATA Controller
Required properties:
- reg: Physical base address and size of the controller's register area.
- compatible: Compatibility string. Must be 'fsl,<chip>-ahci', where
- chip could be ls1021a, ls1043a, ls1046a, ls2080a etc.
+ chip could be ls1021a, ls1043a, ls1046a, ls2080a, ls2088a etc.
- clocks: Input clock specifier. Refer to common clock bindings.
- interrupts: Interrupt specifier. Refer to interrupt binding.
diff --git a/drivers/ata/ahci_qoriq.c b/drivers/ata/ahci_qoriq.c
index 66eb4b5..912fe32 100644
--- a/drivers/ata/ahci_qoriq.c
+++ b/drivers/ata/ahci_qoriq.c
@@ -53,6 +53,7 @@ enum ahci_qoriq_type {
AHCI_LS1043A,
AHCI_LS2080A,
AHCI_LS1046A,
+ AHCI_LS2088A,
};
struct ahci_qoriq_priv {
@@ -67,6 +68,7 @@ static const struct of_device_id ahci_qoriq_of_match[] = {
{ .compatible = "fsl,ls1043a-ahci", .data = (void *)AHCI_LS1043A},
{ .compatible = "fsl,ls2080a-ahci", .data = (void *)AHCI_LS2080A},
{ .compatible = "fsl,ls1046a-ahci", .data = (void *)AHCI_LS1046A},
+ { .compatible = "fsl,ls2088a-ahci", .data = (void *)AHCI_LS2088A},
{},
};
MODULE_DEVICE_TABLE(of, ahci_qoriq_of_match);
@@ -193,6 +195,13 @@ static int ahci_qoriq_phy_init(struct ahci_host_priv *hpriv)
if (qpriv->is_dmacoherent)
writel(AHCI_PORT_AXICC_CFG, reg_base + PORT_AXICC);
break;
+
+ case AHCI_LS2088A:
+ writel(AHCI_PORT_PHY_1_CFG, reg_base + PORT_PHY1);
+ writel(AHCI_PORT_TRANS_CFG, reg_base + PORT_TRANS);
+ if (qpriv->is_dmacoherent)
+ writel(AHCI_PORT_AXICC_CFG, reg_base + PORT_AXICC);
+ break;
}
return 0;
--
2.1.0.27.g96db324
^ permalink raw reply related
* Re: [PATCH v7 3/3] arm64: dts: exynos: Add tm2 touchkey node
From: Chanwoo Choi @ 2017-01-17 6:12 UTC (permalink / raw)
To: Jaechul Lee, Dmitry Torokhov, Rob Herring, Mark Rutland,
Catalin Marinas, Will Deacon, Kukjin Kim, Krzysztof Kozlowski,
Javier Martinez Canillas
Cc: Andi Shyti, beomho.seo, galaxyra, linux-arm-kernel, linux-input,
devicetree, linux-kernel, linux-samsung-soc
In-Reply-To: <1484632479-3111-4-git-send-email-jcsing.lee@samsung.com>
Hi,
I tested this patch on v6[1] and replied it.
But, this version is missing the my tested-by and reviewed-by tag.
[1] https://patchwork.kernel.org/patch/9504139/
So, I add my reviewed-by and tested-by tag again.
Reviewed-by: Chanwoo Choi <cw00.choi@samsung.com>
Tested-by: Chanwoo Choi <cw00.choi@samsung.com>
On 2017년 01월 17일 14:54, Jaechul Lee wrote:
> Add DT node support for TM2 touchkey device.
>
> Signed-off-by: Beomho Seo <beomho.seo@samsung.com>
> Signed-off-by: Jaechul Lee <jcsing.lee@samsung.com>
> Signed-off-by: Andi Shyti <andi.shyti@samsung.com>
> Reviewed-by: Javier Martinez Canillas <javier@osg.samsung.com>
> ---
> arch/arm64/boot/dts/exynos/exynos5433-tm2.dts | 13 +++++++++++++
> 1 file changed, 13 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts b/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
> index 2449266..ddba2f8 100644
> --- a/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
> +++ b/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
> @@ -18,6 +18,19 @@
> compatible = "samsung,tm2", "samsung,exynos5433";
> };
>
> +&hsi2c_9 {
> + status = "okay";
> +
> + touchkey@20 {
> + compatible = "cypress,tm2-touchkey";
> + reg = <0x20>;
> + interrupt-parent = <&gpa3>;
> + interrupts = <2 IRQ_TYPE_EDGE_FALLING>;
> + vcc-supply = <&ldo32_reg>;
> + vdd-supply = <&ldo33_reg>;
> + };
> +};
> +
> &ldo31_reg {
> regulator-name = "TSP_VDD_1.85V_AP";
> regulator-min-microvolt = <1850000>;
>
--
Best Regards,
Chanwoo Choi
S/W Center, Samsung Electronics
^ permalink raw reply
* RE: [PATCH v2 05/12] Document: dt: binding: imx: update pinctrl doc for imx6sll
From: Jacky Bai @ 2017-01-17 6:35 UTC (permalink / raw)
To: Linus Walleij
Cc: Shawn Guo, Michael Turquette, Stephen Boyd, Rob Herring,
Mark Rutland, Sascha Hauer, Fabio Estevam, Daniel Lezcano,
Thomas Gleixner, Philipp Zabel, linux-clk,
devicetree@vger.kernel.org, linux-gpio@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, jacky.baip@gmail.com
In-Reply-To: <CACRpkda1a4+yOrzBnKs6J84PS0StwQ68gHxDub_u7i5ofU9s7w@mail.gmail.com>
> Subject: Re: [PATCH v2 05/12] Document: dt: binding: imx: update pinctrl doc
> for imx6sll
>
> On Thu, Jan 12, 2017 at 3:57 AM, Jacky Bai <ping.bai@nxp.com> wrote:
>
> > Another thing is that we can use a pins-tool program developed by NXP
> > to generate the pinctrl configuration code that can be used directly
> > in dts. This tiny program can avoid pin function conflict. As on i.MX,
> > there are so may pins, each pin can be used for up 8 function.
> > Configuring the pins is a time-consuming work. This tools is very useful for
> customer to generate the dts code.
>
> I understand, but every silicon vendor has such a tool, all are different,
> proprietary and unfriendly to programmers and open source developers, who
> need to understand how the hardware is working without magic tools and
> secret data sheets to fix bugs.
>
> For the people working with maintaining the code it is paramount that DTS files
> are self-descriptive.
>
OK. Thanks for your comments. Adding generic-pinconf in imx pinctrl needs some time
to finish and the legacy method still need be here even if generic-pinconf is added.
Do you plan to pick this legacy binding patch for now?
> Yours,
> Linus Walleij
^ permalink raw reply
* Re: [PATCH] fbdev: ssd1307fb: allow reset-gpios is missing
From: Maxime Ripard @ 2017-01-17 7:40 UTC (permalink / raw)
To: Icenowy Zheng
Cc: David Airlie, linux-fbdev-u79uwXL29TY76Z2rM5mHXA, Rob Herring,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20170117042658.QtsSkpPN-/icbEWb855g0PDqKvflMoHmW9unr2Ajn@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 1080 bytes --]
On Mon, Jan 16, 2017 at 05:50:21PM +0800, Icenowy Zheng wrote:
>
> 2017年1月16日 16:02于 Maxime Ripard <maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>写道：
> >
> > On Sun, Jan 15, 2017 at 07:21:46PM +0800, Icenowy Zheng wrote:
> > > Currently some SSD1306 OLED modules are sold without a reset pin (only
> > > VCC, GND, SCK, SDA four pins).
> > >
> > > Add support for missing reset-gpios property.
> > >
> > > Signed-off-by: Icenowy Zheng <icenowy-ymACFijhrKM@public.gmane.org>
> >
> > Unfortunately, a similar patch has been sent a couple of times
> > already:
> > https://www.spinics.net/lists/devicetree/msg158330.html
>
> Why is it never merged?
It was sent 4 days ago...
And since you didn't have the right maintainers in the cc list, yours
didn't have a chance to be merged either.
> There are really boards that needs this function.
Then you can accelerate its inclusion by reviewing it.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [PATCH v3 00/18] FSI device driver introduction
From: Greg KH @ 2017-01-17 7:42 UTC (permalink / raw)
To: christopher.lee.bostic
Cc: mark.rutland, devicetree, geert+renesas, andrew, alistair,
mturquette, linux, Chris Bostic, linux-kernel, robh+dt, joel,
benh, linux-arm-kernel, jk
In-Reply-To: <1484601768-98079-1-git-send-email-christopher.lee.bostic@gmail.com>
On Mon, Jan 16, 2017 at 03:22:48PM -0600, christopher.lee.bostic@gmail.com wrote:
> From: Chris Bostic <cbostic@us.ibm.com>
<snip>
Only this, and patch 02/18 came through, did something get stuck on your
end?
greg k-h
^ permalink raw reply
* Re: [PATCH v3 3/3] reset: zx2967: add reset controller driver for ZTE's zx2967 family
From: Shawn Guo @ 2017-01-17 7:46 UTC (permalink / raw)
To: Baoyou Xie
Cc: mark.rutland, devicetree, xie.baoyou, linux-kernel, robh+dt,
chen.chaokai, p.zabel, wang.qiang01, jun.nie, linux-arm-kernel
In-Reply-To: <1484623377-16208-3-git-send-email-baoyou.xie@linaro.org>
On Tue, Jan 17, 2017 at 11:22:57AM +0800, Baoyou Xie wrote:
> This patch adds reset controller driver for ZTE's zx2967 family.
>
> Signed-off-by: Baoyou Xie <baoyou.xie@linaro.org>
Reviewed-by: Shawn Guo <shawnguo@kernel.org>
^ permalink raw reply
* Re: [PATCH v3 2/4] dt-bindings: Add TI SCI PM Domains
From: Tero Kristo @ 2017-01-17 7:48 UTC (permalink / raw)
To: Dave Gerlach, Rob Herring
Cc: Nishanth Menon, devicetree@vger.kernel.org, Ulf Hansson,
Santosh Shilimkar, linux-pm@vger.kernel.org, Lokesh Vutla,
Keerthy, Kevin Hilman, Rafael J . Wysocki,
linux-kernel@vger.kernel.org, Russell King, Sudeep Holla,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <0eaa9914-83f1-7716-cf04-1e3dd44df647@ti.com>
On 17/01/17 00:12, Dave Gerlach wrote:
> On 01/13/2017 08:40 PM, Rob Herring wrote:
>> On Fri, Jan 13, 2017 at 2:28 PM, Dave Gerlach <d-gerlach@ti.com> wrote:
>>> On 01/13/2017 01:25 PM, Rob Herring wrote:
>>>>
>>>> On Thu, Jan 12, 2017 at 9:27 AM, Dave Gerlach <d-gerlach@ti.com> wrote:
>>>>>
>>>>> Rob,
>>>>>
>>>>> On 01/11/2017 03:34 PM, Rob Herring wrote:
>>>>>>
>>>>>>
>>>>>> On Mon, Jan 9, 2017 at 11:57 AM, Dave Gerlach <d-gerlach@ti.com>
>>>>>> wrote:
>>>>>>>
>>>>>>>
>>>>>>> Rob,
>>>>>>>
>>>>>>> On 01/09/2017 11:50 AM, Rob Herring wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Wed, Jan 04, 2017 at 02:55:34PM -0600, Dave Gerlach wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Add a generic power domain implementation, TI SCI PM Domains, that
>>>>>>>>> will hook into the genpd framework and allow the TI SCI
>>>>>>>>> protocol to
>>>>>>>>> control device power states.
>>>>>>>>>
>>>>>>>>> Also, provide macros representing each device index as understood
>>>>>>>>> by TI SCI to be used in the device node power-domain references.
>>>>>>>>> These are identifiers for the K2G devices managed by the PMMC.
>>>>>>>>>
>>>>>>>>> Signed-off-by: Nishanth Menon <nm@ti.com>
>>>>>>>>> Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
>>>>>>>>> ---
>>>>>>>>> v2->v3:
>>>>>>>>> Update k2g_pds node docs to show it should be a child
>>>>>>>>> of pmmc
>>>>>>>>> node.
>>>>>>>>> In early versions a phandle was used to point to pmmc and
>>>>>>>>> docs
>>>>>>>>> still
>>>>>>>>> incorrectly showed this.
>>>>>>>>>
>>>>>>>>> .../devicetree/bindings/soc/ti/sci-pm-domain.txt | 59
>>>>>>>>> ++++++++++++++
>>>>>>>>> MAINTAINERS | 2 +
>>>>>>>>> include/dt-bindings/genpd/k2g.h | 90
>>>>>>>>> ++++++++++++++++++++++
>>>>>>>>> 3 files changed, 151 insertions(+)
>>>>>>>>> create mode 100644
>>>>>>>>> Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt
>>>>>>>>> create mode 100644 include/dt-bindings/genpd/k2g.h
>>>>>>>>>
>>>>>>>>> diff --git
>>>>>>>>> a/Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt
>>>>>>>>> b/Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt
>>>>>>>>> new file mode 100644
>>>>>>>>> index 000000000000..4c9064e512cb
>>>>>>>>> --- /dev/null
>>>>>>>>> +++ b/Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt
>>>>>>>>> @@ -0,0 +1,59 @@
>>>>>>>>> +Texas Instruments TI-SCI Generic Power Domain
>>>>>>>>> +---------------------------------------------
>>>>>>>>> +
>>>>>>>>> +Some TI SoCs contain a system controller (like the PMMC, etc...)
>>>>>>>>> that
>>>>>>>>> is
>>>>>>>>> +responsible for controlling the state of the IPs that are
>>>>>>>>> present.
>>>>>>>>> +Communication between the host processor running an OS and the
>>>>>>>>> system
>>>>>>>>> +controller happens through a protocol known as TI-SCI [1].
>>>>>>>>> This pm
>>>>>>>>> domain
>>>>>>>>> +implementation plugs into the generic pm domain framework and
>>>>>>>>> makes
>>>>>>>>> use
>>>>>>>>> of
>>>>>>>>> +the TI SCI protocol power on and off each device when needed.
>>>>>>>>> +
>>>>>>>>> +[1] Documentation/devicetree/bindings/arm/keystone/ti,sci.txt
>>>>>>>>> +
>>>>>>>>> +PM Domain Node
>>>>>>>>> +==============
>>>>>>>>> +The PM domain node represents the global PM domain managed by the
>>>>>>>>> PMMC,
>>>>>>>>> +which in this case is the single implementation as documented
>>>>>>>>> by the
>>>>>>>>> generic
>>>>>>>>> +PM domain bindings in
>>>>>>>>> Documentation/devicetree/bindings/power/power_domain.txt.
>>>>>>>>> +Because this relies on the TI SCI protocol to communicate with
>>>>>>>>> the
>>>>>>>>> PMMC
>>>>>>>>> it
>>>>>>>>> +must be a child of the pmmc node.
>>>>>>>>> +
>>>>>>>>> +Required Properties:
>>>>>>>>> +--------------------
>>>>>>>>> +- compatible: should be "ti,sci-pm-domain"
>>>>>>>>> +- #power-domain-cells: Must be 0.
>>>>>>>>> +
>>>>>>>>> +Example (K2G):
>>>>>>>>> +-------------
>>>>>>>>> + pmmc: pmmc {
>>>>>>>>> + compatible = "ti,k2g-sci";
>>>>>>>>> + ...
>>>>>>>>> +
>>>>>>>>> + k2g_pds: k2g_pds {
>>>>>>>>> + compatible = "ti,sci-pm-domain";
>>>>>>>>> + #power-domain-cells = <0>;
>>>>>>>>> + };
>>>>>>>>> + };
>>>>>>>>> +
>>>>>>>>> +PM Domain Consumers
>>>>>>>>> +===================
>>>>>>>>> +Hardware blocks that require SCI control over their state must
>>>>>>>>> provide
>>>>>>>>> +a reference to the sci-pm-domain they are part of and a unique
>>>>>>>>> device
>>>>>>>>> +specific ID that identifies the device.
>>>>>>>>> +
>>>>>>>>> +Required Properties:
>>>>>>>>> +--------------------
>>>>>>>>> +- power-domains: phandle pointing to the corresponding PM domain
>>>>>>>>> node.
>>>>>>>>> +- ti,sci-id: index representing the device id to be passed
>>>>>>>>> oevr SCI
>>>>>>>>> to
>>>>>>>>> + be used for device control.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> As I've already stated before, this goes in power-domain cells.
>>>>>>>> When
>>>>>>>> you
>>>>>>>> have a single thing (i.e. node) that controls multiple things, then
>>>>>>>> you
>>>>>>>> you need to specify the ID for each of them in phandle args.
>>>>>>>> This is
>>>>>>>> how
>>>>>>>> irqs, gpio, clocks, *everything* in DT works.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> You think the reasoning for doing it this way provided by both
>>>>>>> Ulf and
>>>>>>> myself on v2 [1] is not valid then?
>>>>>>>
>>>>>>> From Ulf:
>>>>>>>
>>>>>>> To me, the TI SCI ID, is similar to a "conid" for any another
>>>>>>> "device
>>>>>>> resource" (like clock, pinctrl, regulator etc) which we can describe
>>>>>>> in DT and assign to a device node. The only difference here, is that
>>>>>>> we don't have common API to fetch the resource (like clk_get(),
>>>>>>> regulator_get()), but instead we fetches the device's resource from
>>>>>>> SoC specific code, via genpd's device ->attach() callback.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Sorry, but that sounds like a kernel problem to me and has nothing to
>>>>>> do with DT bindings.
>>>>>>
>>>>>>> From me:
>>>>>>>
>>>>>>> Yes, you've pretty much hit it on the head. It is not an index
>>>>>>> into a
>>>>>>> list
>>>>>>> of genpds but rather identifies the device *within* a single
>>>>>>> genpd. It
>>>>>>> is
>>>>>>> a
>>>>>>> property specific to each device that resides in a ti-sci-genpd,
>>>>>>> not a
>>>>>>> mapping describing which genpd the device belongs to. The generic
>>>>>>> power
>>>>>>> domain binding is concerned with mapping the device to a specific
>>>>>>> genpd,
>>>>>>> which is does fine for us, but we have a sub mapping for devices
>>>>>>> that
>>>>>>> exist
>>>>>>> inside a genpd which, we must describe as well, hence the ti,sci-id.
>>>>>>>
>>>>>>>
>>>>>>> So to summarize, the genpd framework does interpret the phandle
>>>>>>> arg as
>>>>>>> an
>>>>>>> index into multiple genpds, just as you've said other frameworks do,
>>>>>>> but
>>>>>>> this is not what I am trying to do, we have multiple devices within
>>>>>>> this
>>>>>>> *single* genpd, hence the need for the ti,sci-id property.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Fix the genpd framework rather than work around it in DT.
>>>>>
>>>>>
>>>>>
>>>>> I still disagree that this has nothing to do with DT bindings, as the
>>>>> current DT binding represents something different already. I am
>>>>> trying to
>>>>> extend it to give me additional information needed for our
>>>>> platforms. Are
>>>>> you saying that we should break what the current DT binding already
>>>>> represents to mean something else?
>>>>
>>>>
>>>> No idea because what's the current binding? From the patch, looks like
>>>> a new binding to me.
>>>
>>>
>>> Yes, ti,sci-id is a new binding. I am referring to the current
>>> meaning of
>>> the "power-domains" binding, which is where you are asking this
>>> property to
>>> be added, in "power-domains" cells. This is documented here [1] in the
>>> kernel, although looking at it I must admit it is not very clear.
>>>
>>> The power-domains cell represents an offset into an array of power
>>> domains,
>>> if you choose to use it. That's what the genpd framework is hard
>>> coded to
>>> interpret it as. This is correct, as it is an index into a static
>>> list of
>>> power domains, used to identify which power domain a device belongs to,
>>> which is exactly what the genpd framework itself is concerned with.
>>> This is
>>> already how it is used in the kernel today.
>>
>> Strictly speaking, the cells are purely for the interpretation of the
>> phandle they are associated with. If some controller wants to have 20
>> cells, then it could assuming a good reason. The reality is we tend to
>> align the meaning of the cells. If genpd is interpreting the cells and
>> not letting the driver for the power domain controller interpret them,
>> then still, genpd needs to be fixed.
>
> Ok, perhaps the genpd folks on the thread can jump in here with any
> thoughts that they have.
>
>>
>> IIRC, initially it was said genpd required 0 cells, hence my confusion.
>>
>>> My ti,sci-id is not an index into a list of power domains, so it
>>> should not
>>> go in the power-domains cells and go against what the power-domains
>>> binding
>>> says that the cell expects. We have one single power domain, and the new
>>> ti,sci-id binding is not something the genpd framework itself is
>>> concerned
>>> with as it's our property to identify a device inside a power domain,
>>> not to
>>> identify which power domain it is associated with.
>>
>> What is the id used for? I can understand why you need to know what
>> power domain a device is in (as power-domains identifies), but not
>> what devices are in a power domain.
>
> We have a system control processor that provides power management
> services to the OS and it responsible for handling the power state of
> each device. This control happens over a communication interface we have
> called TI SCI (implemented at drivers/firmware/ti-sci.c). The
> communication protocol uses these ids to identify each device within the
> power domain so that the control processor can do what is necessary to
> enable that device.
I think a minor detail here that Rob might be missing right now is, that
the ti,sci-id is only controlling the PM runtime handling, and providing
the ID per-device for this purpose only. AFAIK, it is not really
connected to the power domain anymore as such, as we don't have
power-domains / per device anymore as was the case in some earlier
revision of this work.
One could argue though that the whole usage of power-domains is now
moot, as we basically only have implemented one genpd in the whole SoC,
which doesn't really reflect the reality. I wonder if better approach
would be to have this replaced with proper power domains at some point
(if needed), and just have a runtime-pm implementation in place for the
devices that require it.
So, as an example in DT, we would only have:
uart0: serial@02530c00 {
compatible = "xyz";
...
ti,sci-id = <K2G_DEV_UART0>;
};
This is somewhat analogous to what OMAP family of SoCs have in place
now, under "ti,hwmods" property. I also wonder if the "ti,sci-id" should
be replaced with something like "ti,sci-dev-id" to make its purpose clearer.
-Tero
>
> Regards,
> Dave
>
>>
>> Rob
>>
>
^ permalink raw reply
* [PATCH v5 0/5] i2c: mux: pca954x: Add interrupt controller support
From: Phil Reid @ 2017-01-17 8:00 UTC (permalink / raw)
To: peda-koto5C5qi+TLoDKTGw+V6w, wsa-z923LK4zBo2bacvFa/9K2g,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
preid-qgqNFa1JUf/o2iN0hyhwsIdd74u8MsAO,
linux-i2c-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA
Various muxes can aggregate multiple interrupts from each i2c bus.
All of the muxes with interrupt support combine the active low irq lines
using an internal 'and' function and generate a combined active low
output. The muxes do provide the ability to read a control register to
determine which irq is active. By making the mux an irq controller isr
latenct can potentially be reduced by reading the status register and
then only calling the registered isr on that bus segment.
In addition an additional enable mask is added to work around devices
that assert irq immediately before being setup by disabling the irq
from the mux until all devices are registered.
Changes from v4:
- p4: Change definition of irq_mask_enable to an array.
- p4: Removed acks due to change requested by Peter
- p5: Parse array of enables. Currently only supports 1 chip
But dt specification will allow expansion to handle
multple irq consume chips to be registered on a bus segment
- p5: Fix up logic related to enabling and disable irq's.
Use a flag to indicate when irq has been enabled.
Changes from v3:
- p3: Add spin lock to irq mask / unmask.
- p4: Add Rob's ack.
Changes from v2:
- p1: Added Acked-by
- p5: fixup 2 typos
Changes from v1:
- Update for new ACPI table
- Fix typo in documentation
- Fix typo in function names
- Fix typo in irq name
- Added spaces around '+' / '='
- Change goto label names
- Change property name from i2c-mux-irq-mask-en to nxp,irq-mask-enable
- Change variable name irq_mask_en to irq_mask_enable
- Add commentt about irq_mask_enable
- Added Acked-By's
Phil Reid (5):
i2c: mux: pca954x: Add missing pca9542 definition to chip_desc
dt: bindings: i2c-mux-pca954x: Add documentation for interrupt
controller
i2c: mux: pca954x: Add interrupt controller support
dt: bindings: i2c-mux-pca954x: Add documentation for
nxp,irq-mask-enable
i2c: mux: pca954x: Add irq-mask-enable to delay enabling irqs
.../devicetree/bindings/i2c/i2c-mux-pca954x.txt | 17 +-
drivers/i2c/muxes/i2c-mux-pca954x.c | 177 ++++++++++++++++++++-
2 files changed, 189 insertions(+), 5 deletions(-)
--
1.8.3.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH v5 1/5] i2c: mux: pca954x: Add missing pca9542 definition to chip_desc
From: Phil Reid @ 2017-01-17 8:00 UTC (permalink / raw)
To: peda, wsa, robh+dt, mark.rutland, preid, linux-i2c, devicetree
In-Reply-To: <1484640029-22870-1-git-send-email-preid@electromag.com.au>
The spec for the pca954x was missing. This chip is the same as the pca9540
except that it has interrupt lines. While the i2c_device_id table mapped
the pca9542 to the pca9540 definition the compatible table did not. In
preparation for irq support add the pca9542 definition.
Acked-by: Peter Rosin <peda@axentia.se>
Signed-off-by: Phil Reid <preid@electromag.com.au>
---
drivers/i2c/muxes/i2c-mux-pca954x.c | 9 +++++++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/i2c/muxes/i2c-mux-pca954x.c b/drivers/i2c/muxes/i2c-mux-pca954x.c
index dd18b9c..bbf088e 100644
--- a/drivers/i2c/muxes/i2c-mux-pca954x.c
+++ b/drivers/i2c/muxes/i2c-mux-pca954x.c
@@ -84,6 +84,11 @@ struct pca954x {
.enable = 0x4,
.muxtype = pca954x_ismux,
},
+ [pca_9542] = {
+ .nchans = 2,
+ .enable = 0x4,
+ .muxtype = pca954x_ismux,
+ },
[pca_9543] = {
.nchans = 2,
.muxtype = pca954x_isswi,
@@ -110,7 +115,7 @@ struct pca954x {
static const struct i2c_device_id pca954x_id[] = {
{ "pca9540", pca_9540 },
- { "pca9542", pca_9540 },
+ { "pca9542", pca_9542 },
{ "pca9543", pca_9543 },
{ "pca9544", pca_9544 },
{ "pca9545", pca_9545 },
@@ -124,7 +129,7 @@ struct pca954x {
#ifdef CONFIG_ACPI
static const struct acpi_device_id pca954x_acpi_ids[] = {
{ .id = "PCA9540", .driver_data = pca_9540 },
- { .id = "PCA9542", .driver_data = pca_9540 },
+ { .id = "PCA9542", .driver_data = pca_9542 },
{ .id = "PCA9543", .driver_data = pca_9543 },
{ .id = "PCA9544", .driver_data = pca_9544 },
{ .id = "PCA9545", .driver_data = pca_9545 },
--
1.8.3.1
^ permalink raw reply related
* [PATCH v5 2/5] dt: bindings: i2c-mux-pca954x: Add documentation for interrupt controller
From: Phil Reid @ 2017-01-17 8:00 UTC (permalink / raw)
To: peda, wsa, robh+dt, mark.rutland, preid, linux-i2c, devicetree
In-Reply-To: <1484640029-22870-1-git-send-email-preid@electromag.com.au>
Various muxes can aggregate multiple irq lines and provide a control
register to determine the active line. Add bindings for interrupt
controller support.
Acked-by: Peter Rosin <peda@axentia.se>
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Phil Reid <preid@electromag.com.au>
---
Documentation/devicetree/bindings/i2c/i2c-mux-pca954x.txt | 14 +++++++++++++-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/i2c/i2c-mux-pca954x.txt b/Documentation/devicetree/bindings/i2c/i2c-mux-pca954x.txt
index cf53d5f..aa09704 100644
--- a/Documentation/devicetree/bindings/i2c/i2c-mux-pca954x.txt
+++ b/Documentation/devicetree/bindings/i2c/i2c-mux-pca954x.txt
@@ -19,7 +19,14 @@ Optional Properties:
- i2c-mux-idle-disconnect: Boolean; if defined, forces mux to disconnect all
children in idle state. This is necessary for example, if there are several
multiplexers on the bus and the devices behind them use same I2C addresses.
-
+ - interrupt-parent: Phandle for the interrupt controller that services
+ interrupts for this device.
+ - interrupts: Interrupt mapping for IRQ.
+ - interrupt-controller: Marks the device node as an interrupt controller.
+ - #interrupt-cells : Should be two.
+ - first cell is the pin number
+ - second cell is used to specify flags.
+ See also Documentation/devicetree/bindings/interrupt-controller/interrupts.txt
Example:
@@ -29,6 +36,11 @@ Example:
#size-cells = <0>;
reg = <0x74>;
+ interrupt-parent = <&ipic>;
+ interrupts = <17 IRQ_TYPE_LEVEL_LOW>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+
i2c@2 {
#address-cells = <1>;
#size-cells = <0>;
--
1.8.3.1
^ permalink raw reply related
* [PATCH v5 3/5] i2c: mux: pca954x: Add interrupt controller support
From: Phil Reid @ 2017-01-17 8:00 UTC (permalink / raw)
To: peda, wsa, robh+dt, mark.rutland, preid, linux-i2c, devicetree
In-Reply-To: <1484640029-22870-1-git-send-email-preid@electromag.com.au>
Various muxes can aggregate multiple interrupts from each i2c bus.
All of the muxes with interrupt support combine the active low irq lines
using an internal 'and' function and generate a combined active low
output. The muxes do provide the ability to read a control register to
determine which irq is active. By making the mux an irq controller isr
latency can potentially be reduced by reading the status register and
then only calling the registered isr on that bus segment.
As there is no irq masking on the mux irq are disabled until irq_unmask is
called at least once.
Signed-off-by: Phil Reid <preid@electromag.com.au>
---
drivers/i2c/muxes/i2c-mux-pca954x.c | 141 +++++++++++++++++++++++++++++++++++-
1 file changed, 139 insertions(+), 2 deletions(-)
diff --git a/drivers/i2c/muxes/i2c-mux-pca954x.c b/drivers/i2c/muxes/i2c-mux-pca954x.c
index bbf088e..f55da88 100644
--- a/drivers/i2c/muxes/i2c-mux-pca954x.c
+++ b/drivers/i2c/muxes/i2c-mux-pca954x.c
@@ -41,14 +41,20 @@
#include <linux/i2c.h>
#include <linux/i2c-mux.h>
#include <linux/i2c/pca954x.h>
+#include <linux/interrupt.h>
+#include <linux/irq.h>
#include <linux/module.h>
#include <linux/of.h>
#include <linux/of_device.h>
+#include <linux/of_irq.h>
#include <linux/pm.h>
#include <linux/slab.h>
+#include <linux/spinlock.h>
#define PCA954X_MAX_NCHANS 8
+#define PCA954X_IRQ_OFFSET 4
+
enum pca_type {
pca_9540,
pca_9542,
@@ -63,6 +69,7 @@ enum pca_type {
struct chip_desc {
u8 nchans;
u8 enable; /* used for muxes only */
+ u8 has_irq;
enum muxtype {
pca954x_ismux = 0,
pca954x_isswi
@@ -75,6 +82,10 @@ struct pca954x {
u8 last_chan; /* last register value */
u8 deselect;
struct i2c_client *client;
+
+ struct irq_domain *irq;
+ unsigned int irq_mask;
+ spinlock_t lock;
};
/* Provide specs for the PCA954x types we know about */
@@ -87,19 +98,23 @@ struct pca954x {
[pca_9542] = {
.nchans = 2,
.enable = 0x4,
+ .has_irq = 1,
.muxtype = pca954x_ismux,
},
[pca_9543] = {
.nchans = 2,
+ .has_irq = 1,
.muxtype = pca954x_isswi,
},
[pca_9544] = {
.nchans = 4,
.enable = 0x4,
+ .has_irq = 1,
.muxtype = pca954x_ismux,
},
[pca_9545] = {
.nchans = 4,
+ .has_irq = 1,
.muxtype = pca954x_isswi,
},
[pca_9547] = {
@@ -222,6 +237,114 @@ static int pca954x_deselect_mux(struct i2c_mux_core *muxc, u32 chan)
return pca954x_reg_write(muxc->parent, client, data->last_chan);
}
+static irqreturn_t pca954x_irq_handler(int irq, void *dev_id)
+{
+ struct pca954x *data = dev_id;
+ unsigned int child_irq;
+ int ret, i, handled;
+
+ ret = i2c_smbus_read_byte(data->client);
+ if (ret < 0)
+ return IRQ_NONE;
+
+ for (i = 0; i < data->chip->nchans; i++) {
+ if (ret & BIT(PCA954X_IRQ_OFFSET + i)) {
+ child_irq = irq_linear_revmap(data->irq, i);
+ handle_nested_irq(child_irq);
+ handled++;
+ }
+ }
+ return handled ? IRQ_HANDLED : IRQ_NONE;
+}
+
+static void pca954x_irq_mask(struct irq_data *idata)
+{
+ struct pca954x *data = irq_data_get_irq_chip_data(idata);
+ unsigned int pos = idata->hwirq;
+ unsigned long flags;
+
+ spin_lock_irqsave(&data->lock, flags);
+
+ data->irq_mask &= ~BIT(pos);
+ if (!data->irq_mask)
+ disable_irq(data->client->irq);
+
+ spin_unlock_irqrestore(&data->lock, flags);
+}
+
+static void pca954x_irq_unmask(struct irq_data *idata)
+{
+ struct pca954x *data = irq_data_get_irq_chip_data(idata);
+ unsigned int pos = idata->hwirq;
+ unsigned long flags;
+
+ spin_lock_irqsave(&data->lock, flags);
+
+ if (!data->irq_mask)
+ enable_irq(data->client->irq);
+ data->irq_mask |= BIT(pos);
+
+ spin_unlock_irqrestore(&data->lock, flags);
+}
+
+static int pca954x_irq_set_type(struct irq_data *idata, unsigned int type)
+{
+ if ((type & IRQ_TYPE_SENSE_MASK) != IRQ_TYPE_LEVEL_LOW)
+ return -EINVAL;
+ return 0;
+}
+
+static struct irq_chip pca954x_irq_chip = {
+ .name = "i2c-mux-pca954x",
+ .irq_mask = pca954x_irq_mask,
+ .irq_unmask = pca954x_irq_unmask,
+ .irq_set_type = pca954x_irq_set_type,
+};
+
+static int pca954x_irq_setup(struct i2c_mux_core *muxc)
+{
+ struct pca954x *data = i2c_mux_priv(muxc);
+ struct i2c_client *client = data->client;
+ int c, err, irq;
+
+ if (!data->chip->has_irq || client->irq <= 0)
+ return 0;
+
+ spin_lock_init(&data->lock);
+
+ data->irq = irq_domain_add_linear(client->dev.of_node,
+ data->chip->nchans,
+ &irq_domain_simple_ops, data);
+ if (!data->irq)
+ return -ENODEV;
+
+ for (c = 0; c < data->chip->nchans; c++) {
+ irq = irq_create_mapping(data->irq, c);
+ irq_set_chip_data(irq, data);
+ irq_set_chip_and_handler(irq, &pca954x_irq_chip,
+ handle_simple_irq);
+ }
+
+ err = devm_request_threaded_irq(&client->dev, data->client->irq, NULL,
+ pca954x_irq_handler,
+ IRQF_ONESHOT | IRQF_SHARED,
+ "pca954x", data);
+ if (err)
+ goto err_req_irq;
+
+ disable_irq(data->client->irq);
+
+ return 0;
+err_req_irq:
+ for (c = 0; c < data->chip->nchans; c++) {
+ irq = irq_find_mapping(data->irq, c);
+ irq_dispose_mapping(irq);
+ }
+ irq_domain_remove(data->irq);
+
+ return err;
+}
+
/*
* I2C init/probing/exit functions
*/
@@ -286,6 +409,10 @@ static int pca954x_probe(struct i2c_client *client,
idle_disconnect_dt = of_node &&
of_property_read_bool(of_node, "i2c-mux-idle-disconnect");
+ ret = pca954x_irq_setup(muxc);
+ if (ret)
+ goto fail_del_adapters;
+
/* Now create an adapter for each channel */
for (num = 0; num < data->chip->nchans; num++) {
bool idle_disconnect_pd = false;
@@ -311,7 +438,7 @@ static int pca954x_probe(struct i2c_client *client,
dev_err(&client->dev,
"failed to register multiplexed adapter"
" %d as bus %d\n", num, force);
- goto virt_reg_failed;
+ goto fail_del_adapters;
}
}
@@ -322,7 +449,7 @@ static int pca954x_probe(struct i2c_client *client,
return 0;
-virt_reg_failed:
+fail_del_adapters:
i2c_mux_del_adapters(muxc);
return ret;
}
@@ -330,6 +457,16 @@ static int pca954x_probe(struct i2c_client *client,
static int pca954x_remove(struct i2c_client *client)
{
struct i2c_mux_core *muxc = i2c_get_clientdata(client);
+ struct pca954x *data = i2c_mux_priv(muxc);
+ int c, irq;
+
+ if (data->irq) {
+ for (c = 0; c < data->chip->nchans; c++) {
+ irq = irq_find_mapping(data->irq, c);
+ irq_dispose_mapping(irq);
+ }
+ irq_domain_remove(data->irq);
+ }
i2c_mux_del_adapters(muxc);
return 0;
--
1.8.3.1
^ permalink raw reply related
* [PATCH v5 4/5] dt: bindings: i2c-mux-pca954x: Add documentation for nxp,irq-mask-enable
From: Phil Reid @ 2017-01-17 8:00 UTC (permalink / raw)
To: peda-koto5C5qi+TLoDKTGw+V6w, wsa-z923LK4zBo2bacvFa/9K2g,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
preid-qgqNFa1JUf/o2iN0hyhwsIdd74u8MsAO,
linux-i2c-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1484640029-22870-1-git-send-email-preid-qgqNFa1JUf/o2iN0hyhwsIdd74u8MsAO@public.gmane.org>
Unfortunately some hardware device will assert their irq line immediately
on power on and provide no mechanism to mask the irq. As the i2c muxes
provide no method to mask irq line this provides a work around by keeping
the parent irq masked until enough device drivers have loaded to service
all pending interrupts.
For example the the ltc1760 assert its SMBALERT irq immediately on power
on. With two ltc1760 attached to bus 0 & 1 on a pca954x mux when the first
device is registered irq are enabled and fire continuously as the second
device driver has not yet loaded. Setting this parameter to <1 1> will
delay the irq being enabled until both devices are ready.
Signed-off-by: Phil Reid <preid-qgqNFa1JUf/o2iN0hyhwsIdd74u8MsAO@public.gmane.org>
---
Documentation/devicetree/bindings/i2c/i2c-mux-pca954x.txt | 3 +++
1 file changed, 3 insertions(+)
diff --git a/Documentation/devicetree/bindings/i2c/i2c-mux-pca954x.txt b/Documentation/devicetree/bindings/i2c/i2c-mux-pca954x.txt
index aa09704..ac71be6 100644
--- a/Documentation/devicetree/bindings/i2c/i2c-mux-pca954x.txt
+++ b/Documentation/devicetree/bindings/i2c/i2c-mux-pca954x.txt
@@ -19,6 +19,8 @@ Optional Properties:
- i2c-mux-idle-disconnect: Boolean; if defined, forces mux to disconnect all
children in idle state. This is necessary for example, if there are several
multiplexers on the bus and the devices behind them use same I2C addresses.
+ - nxp,irq-mask-enable: array; Defines the minimum number of chips that must
+ register an irq for each channel before the parent irq line in enabled.
- interrupt-parent: Phandle for the interrupt controller that services
interrupts for this device.
- interrupts: Interrupt mapping for IRQ.
@@ -36,6 +38,7 @@ Example:
#size-cells = <0>;
reg = <0x74>;
+ nxp,irq-mask-enable = <0 0 0 0 1 0 0 0>;
interrupt-parent = <&ipic>;
interrupts = <17 IRQ_TYPE_LEVEL_LOW>;
interrupt-controller;
--
1.8.3.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH v5 5/5] i2c: mux: pca954x: Add irq-mask-enable to delay enabling irqs
From: Phil Reid @ 2017-01-17 8:00 UTC (permalink / raw)
To: peda, wsa, robh+dt, mark.rutland, preid, linux-i2c, devicetree
In-Reply-To: <1484640029-22870-1-git-send-email-preid@electromag.com.au>
Unfortunately some hardware device will assert their irq line immediately
on power on and provide no mechanism to mask the irq. As the i2c muxes
provide no method to mask irq line this provides a work around by keeping
the parent irq masked until enough device drivers have loaded to service
all pending interrupts.
For example the the ltc1760 assert its SMBALERT irq immediately on power
on. With two ltc1760 attached to bus 0 & 1 on a pca954x mux when the first
device is registered irq are enabled and fire continuously as the second
device driver has not yet loaded. Setting this parameter to <1 1> will
delay the irq being enabled until both devices are ready.
Signed-off-by: Phil Reid <preid@electromag.com.au>
---
drivers/i2c/muxes/i2c-mux-pca954x.c | 33 ++++++++++++++++++++++++++++++---
1 file changed, 30 insertions(+), 3 deletions(-)
diff --git a/drivers/i2c/muxes/i2c-mux-pca954x.c b/drivers/i2c/muxes/i2c-mux-pca954x.c
index f55da88..012b2ef 100644
--- a/drivers/i2c/muxes/i2c-mux-pca954x.c
+++ b/drivers/i2c/muxes/i2c-mux-pca954x.c
@@ -76,6 +76,19 @@ struct chip_desc {
} muxtype;
};
+/*
+ * irq_mask_enable: Provides a mechanism to work around hardware that asserts
+ * their irq immediately on power on. It allows the enabling of the irq to be
+ * delayed until the corresponding bits in the the irq_mask are set thru
+ * irq_unmask.
+ * For example the ltc1760 assert its SMBALERT irq immediately on power on.
+ * With two ltc1760 attached to bus 0 & 1 on a pca954x mux when the first
+ * device is registered irq are enabled and fire continuously as the second
+ * device driver has not yet loaded. Setting this parameter to 0x3 while
+ * delay the irq being enabled until both devices are ready.
+ * This workaround will not work if two devices share an interrupt on the
+ * same bus segment.
+ */
struct pca954x {
const struct chip_desc *chip;
@@ -84,7 +97,9 @@ struct pca954x {
struct i2c_client *client;
struct irq_domain *irq;
+ unsigned int irq_mask_enable;
unsigned int irq_mask;
+ bool irq_enabled;
spinlock_t lock;
};
@@ -266,8 +281,10 @@ static void pca954x_irq_mask(struct irq_data *idata)
spin_lock_irqsave(&data->lock, flags);
data->irq_mask &= ~BIT(pos);
- if (!data->irq_mask)
+ if (data->irq_enabled && !data->irq_mask) {
disable_irq(data->client->irq);
+ data->irq_enabled = false;
+ }
spin_unlock_irqrestore(&data->lock, flags);
}
@@ -275,14 +292,18 @@ static void pca954x_irq_mask(struct irq_data *idata)
static void pca954x_irq_unmask(struct irq_data *idata)
{
struct pca954x *data = irq_data_get_irq_chip_data(idata);
+ unsigned int mask_enable = data->irq_mask_enable;
unsigned int pos = idata->hwirq;
unsigned long flags;
spin_lock_irqsave(&data->lock, flags);
- if (!data->irq_mask)
- enable_irq(data->client->irq);
data->irq_mask |= BIT(pos);
+ if (!data->irq_enabled
+ && (data->irq_mask & mask_enable) == mask_enable) {
+ enable_irq(data->client->irq);
+ data->irq_enabled = true;
+ }
spin_unlock_irqrestore(&data->lock, flags);
}
@@ -305,6 +326,7 @@ static int pca954x_irq_setup(struct i2c_mux_core *muxc)
{
struct pca954x *data = i2c_mux_priv(muxc);
struct i2c_client *client = data->client;
+ u32 irq_mask_enable[PCA954X_MAX_NCHANS] = { 0 };
int c, err, irq;
if (!data->chip->has_irq || client->irq <= 0)
@@ -312,6 +334,9 @@ static int pca954x_irq_setup(struct i2c_mux_core *muxc)
spin_lock_init(&data->lock);
+ of_property_read_u32_array(client->dev.of_node, "nxp,irq-mask-enable",
+ irq_mask_enable, data->chip->nchans);
+
data->irq = irq_domain_add_linear(client->dev.of_node,
data->chip->nchans,
&irq_domain_simple_ops, data);
@@ -319,6 +344,8 @@ static int pca954x_irq_setup(struct i2c_mux_core *muxc)
return -ENODEV;
for (c = 0; c < data->chip->nchans; c++) {
+ data->irq_mask_enable |= irq_mask_enable[c] ? BIT(c) : 0;
+ WARN_ON(irq_mask_enable[c] > 1);
irq = irq_create_mapping(data->irq, c);
irq_set_chip_data(irq, data);
irq_set_chip_and_handler(irq, &pca954x_irq_chip,
--
1.8.3.1
^ permalink raw reply related
* [RFC v2 0/5] Platform driver support for 'amd5536udc' driver
From: Raviteja Garimella @ 2017-01-17 8:05 UTC (permalink / raw)
To: Rob Herring, Mark Rutland, Greg Kroah-Hartman, Felipe Balbi
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
bcm-kernel-feedback-list-dY08KVG/lbpWk0Htik3J/w,
linux-usb-u79uwXL29TY76Z2rM5mHXA
This is RFC for the changes made as per the review comments made for
the previous version. I would like to know if this approach (the way
the driver is split and the naming and all)looks good to be submitted.
Changes from v1:
===============
1. Split the driver into platform/pci specific drivers with a core driver
file that handles the common driver routines that are exported.
2. Split the driver into number of patches as suggested in previous
review comments.
3. Added the devicetree bindings documentation for Synopsys platform
driver.
Introduction from previous version:
===================================
This patch adds platform device support to the existing 'amd5536udc'
driver.
The UDC is based on Synopsys Designware core USB (2.0) Device controller
IP.
The driver so far supports UDCs that are a part of AMD southbridge
and is connected through PCI bus.
The same driver can be used with UDCs that are integrated into SoCs
like Broadcom's Northstar2/Cygnus platforms by adding platform device
suooprt.
This patch contains all the changes that were required to get the driver
functional on Broadcom's Northstar2 platform.
This is a request for comments from maintainers/others regarding approach
on whether to have 2 different drivers (one each for AMD and Broadcom)
with a common library (3 files in total), or have a single driver like
it's done in this patch and have the driver filename changed to some
common name based on ther underlying IP, like snps_udc.c.
Below are the main changes done:
1. Added OF based platform device registration -- so that the driver gets
probed based on the device tree entry. Like wise, remove routine and
platform PM ops are supported.
2. Modified debug prints to be compatible with both pci and platform
devices.
3. Added members to 'struct udc' in header file for extcon and phy support.
This is required if the UDC is connected to a Dual Role Device Phy
where the Phy can be configured to be in Device mode or Host mode based
on the type of external cable that is connected to the port.
4. Added checks in udc connect/disconnect routines so as to return if the
routine is already called.
5. Modified the arguments passed to dma_pool_create routine -- which
expects struct device, whereas NULL is passed in the existing version.
6. Kconfig changes are done so that the driver now depends on either of
CONFIG_OF or CONFIG_PCI. More description about the Synopsys IP is
provided.
Raviteja Garimella (5):
UDC: Split the driver into amd (pci) and Synopsys core driver
UDC: make debug prints compatible with both pci and platform devices
UDC: Provide correct arguments for 'dma_pool_create'
DT bindings documentation for Synopsys UDC platform driver
UDC: Add Synopsys UDC Platform driver
.../devicetree/bindings/usb/snps,dw-ahb-udc.txt | 27 +
drivers/usb/gadget/udc/Kconfig | 32 +
drivers/usb/gadget/udc/Makefile | 2 +
drivers/usb/gadget/udc/amd5536udc.c | 3249 +-------------------
drivers/usb/gadget/udc/amd5536udc.h | 54 +-
drivers/usb/gadget/udc/snps_udc_core.c | 3232 +++++++++++++++++++
drivers/usb/gadget/udc/snps_udc_plat.c | 342 +++
7 files changed, 3714 insertions(+), 3224 deletions(-)
create mode 100644 Documentation/devicetree/bindings/usb/snps,dw-ahb-udc.txt
create mode 100644 drivers/usb/gadget/udc/snps_udc_core.c
create mode 100644 drivers/usb/gadget/udc/snps_udc_plat.c
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox