Re: [PATCH v6 0/3] irqchip: vf610-mscm: add MSCM interrupt router driver
On Sun, Mar 01, 2015 at 11:41:26PM +0100, Stefan Agner wrote: ... > Stefan Agner (3): > irqchip: vf610-mscm-ir: add support for MSCM interrupt router > irqchip: vf610-mscm: dt-bindings: add MSCM bindings > ARM: dts: vf610: add Miscellaneous System Control Module (MSCM) > > .../arm/freescale/fsl,vf610-mscm-cpucfg.txt| 14 ++ > .../bindings/arm/freescale/fsl,vf610-mscm-ir.txt | 33 > arch/arm/boot/dts/vf500.dtsi | 137 + > arch/arm/boot/dts/vfxxx.dtsi | 49 + > arch/arm/mach-imx/Kconfig | 1 + > drivers/irqchip/Makefile | 1 + > drivers/irqchip/irq-vf610-mscm-ir.c| 212 > + > 7 files changed, 314 insertions(+), 133 deletions(-) > create mode 100644 > Documentation/devicetree/bindings/arm/freescale/fsl,vf610-mscm-cpucfg.txt > create mode 100644 > Documentation/devicetree/bindings/arm/freescale/fsl,vf610-mscm-ir.txt > create mode 100644 drivers/irqchip/irq-vf610-mscm-ir.c Applied patches 1 and 2 to irqchip/vybrid. Please let me know if you need to base other work off of this. thx, Jason. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 4/5] Input: add haptic drvier on max77843
On Sat, Mar 07, 2015 at 09:21:02PM +0100, Sebastian Reichel wrote: > Hi, > > On Wed, Mar 04, 2015 at 02:47:42PM -0800, Dmitry Torokhov wrote: > > [...] > > > >Do you want it to go through my or MFD tree? > > > Other drivers merged in each maintainers git. > > Actually only Lee took PATCH 1 so far. > > > > If you don`t hava a problem, please merge your input git tree. > > > > Applied, thank you. > > Patches 2-4 depend on linux/mfd/max77843-private.h from Patch 1, > so taking them independently will introduce build problems. Luckily at least the input driver depends no MFD core so while I agree that the situation is not ideal it is pretty safe since make *config will not allow selecting it. Thanks. -- Dmitry -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] Input: add support for Semtech SX8654 I2C touchscreen controller
On Sat, Mar 07, 2015 at 11:38:55PM +0100, Paul Bolle wrote:
> On Sat, 2015-03-07 at 14:26 -0800, Dmitry Torokhov wrote:
> > On March 7, 2015 2:12:20 PM PST, Paul Bolle wrote:
> > I was talking about them being treated differently from technological
> > standpoint (i.e. the code), not from legal one.
>
> From a technological standpoint it would be easy to declare "GPL" (or
> any other string) to mean "GPL v2 compatible", which is, I think, all
> that matters. But license_is_gpl_compatible() doesn't do that. And I
> fear that's for a reason. Is my fear unfounded?
Well we might ask Rusty on the off chance that he remembers but my guess
would be that he added "GPL v2" in addition to "GPL" and other license
stings because at the time there was one driver,
drivers/net/tulip/xircom_tulip_cb.c, that used MODULE_LICENSE("GPL v2").
>
> > If you want to fix up input drivers I'll take such patch, but I am
> > sure more such cases will sneak in unless you also make sure that
> > there are tools (such as checkpatch.pl) that can alert developers to
> >the inconsistency.
>
> checkpatch.pl crossed my mind too. But in just over a week of checking
> the license comments of (a subset of) the submitted patches I've come to
> think that just won't work.
Thanks.
--
Dmitry
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 0/8] irqchip: New driver for ST's SysCfg controlled IRQs
Lee, On Wed, Feb 18, 2015 at 03:13:56PM +, Lee Jones wrote: > Rebased (again) and resending. > > This driver enables IRQs which are controlled using System Configuration > registers. Without it Performance Monitoring, Core Sight Tracing and some > L2 Caches will fail to function. > > v2 => v3: > - Removed filename from header as suggested by Thomas > > v1 => v2: > - Fixed up Jason's review comments > > Lee Jones (8): > dt: bindings: Supply shared ST IRQ defines > irqchip: Supply new driver for STi based devices > irqchip: irq-st: Add documentation for STi based syscfg IRQs ... > .../interrupt-controller/st,sti-irq-syscfg.txt | 35 ... > drivers/irqchip/Kconfig| 7 + > drivers/irqchip/Makefile | 1 + > drivers/irqchip/irq-st.c | 206 > + > include/dt-bindings/interrupt-controller/irq-st.h | 30 +++ ... > create mode 100644 > Documentation/devicetree/bindings/interrupt-controller/st,sti-irq-syscfg.txt > create mode 100644 drivers/irqchip/irq-st.c > create mode 100644 include/dt-bindings/interrupt-controller/irq-st.h Patches 1-3 applied to irqchip/st several days ago. Sorry for not letting you know earlier. I'm just getting things back in order from hardware failures in my build machine *and* my mailserver. It's been a rough week. :-/ Let me know if you'd like to use that branch as a stable base. thx, Jason. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/5] iommu/mediatek: Add mt8173 IOMMU driver
Hi Yong Wu,
Thanks for this series. Please see my comments inline.
On Fri, Mar 6, 2015 at 7:48 PM, wrote:
> From: Yong Wu
>
> This patch adds support for mediatek m4u (MultiMedia Memory Management Unit).
> Currently this only supports m4u gen 2 with 2 levels of page table on mt8173.
[snip]
> diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
> new file mode 100644
> index 000..d62d4ab
> --- /dev/null
> +++ b/drivers/iommu/mtk_iommu.c
> @@ -0,0 +1,754 @@
> +/*
> + * Copyright (c) 2014-2015 MediaTek Inc.
> + * Author: Yong Wu
> + *
> + * 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.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + */
> +
> +#define pr_fmt(fmt) "m4u:"fmt
This format is not very useful, especially when using dev_ helpers
prepends messages with device name.
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include "mtk_iommu.h"
CodingStyle: The definitions below do not seem to be aligned
correctly. Please make sure all the values are in the same column and
are aligned using tabs only (remembering that tab width specified by
Linux coding style is 8 characters).
> +
> +#define REG_MMUG_PT_BASE0x0
> +
> +#define REG_MMU_INVLD 0x20
> +#define F_MMU_INV_ALL 0x2
> +#define F_MMU_INV_RANGE 0x1
> +
> +#define REG_MMU_INVLD_SA0x24
> +#define REG_MMU_INVLD_EA 0x28
> +
> +#define REG_MMU_INVLD_SEC 0x2c
> +#define F_MMU_INV_SEC_ALL 0x2
> +#define F_MMU_INV_SEC_RANGE0x1
> +
> +#define REG_INVLID_SEL 0x38
> +#define F_MMU_INV_EN_L1 BIT(0)
> +#define F_MMU_INV_EN_L2 BIT(1)
> +
> +#define REG_MMU_STANDARD_AXI_MODE 0x48
> +#define REG_MMU_DCM_DIS 0x50
> +#define REG_MMU_LEGACY_4KB_MODE 0x60
> +
> +#define REG_MMU_CTRL_REG 0x110
> +#define F_MMU_CTRL_REROUTE_PFQ_TO_MQ_EN BIT(4)
> +#define F_MMU_CTRL_TF_PROT_VAL(prot) (((prot) & 0x3)<<5)
CodingStyle: Operators (e.g. <<) should have spaces on both sides.
> +#define F_MMU_CTRL_COHERE_EN BIT(8)
> +
> +#define REG_MMU_IVRP_PADDR 0x114
> +#define F_MMU_IVRP_PA_SET(PA)(PA>>1)
Please make sure that all references to macro arguments in macro
definitions are surrounded by parentheses to avoid issues with
operator precedence. (i.e. ((pa) >> 1))
CodingStyle: Macro arguments should be lowercase.
> +
> +#define REG_MMU_INT_L2_CONTROL 0x120
> +#define F_INT_L2_CLR_BITBIT(12)
> +
> +#define REG_MMU_INT_MAIN_CONTROL0x124
> +#define F_INT_TRANSLATION_FAULT(MMU)
> (1<<(0+(((MMU)<<1)|((MMU)<<2
> +#define F_INT_MAIN_MULTI_HIT_FAULT(MMU)
> (1<<(1+(((MMU)<<1)|((MMU)<<2
> +#define F_INT_INVALID_PA_FAULT(MMU)
> (1<<(2+(((MMU)<<1)|((MMU)<<2
> +#define F_INT_ENTRY_REPLACEMENT_FAULT(MMU)
> (1<<(3+(((MMU)<<1)|((MMU)<<2
> +#define F_INT_TLB_MISS_FAULT(MMU)
> (1<<(4+(((MMU)<<1)|((MMU)<<2
> +#define F_INT_PFH_FIFO_ERR(MMU)
> (1<<(6+(((MMU)<<1)|((MMU)<<2
Multiple coding style issues in these 6 macros, as per my comments above.
> +
> +#define REG_MMU_CPE_DONE 0x12C
> +
> +#define REG_MMU_MAIN_FAULT_ST 0x134
> +
> +#define REG_MMU_FAULT_VA(mmu) (0x13c+((mmu)<<3))
> +#define F_MMU_FAULT_VA_MSK((~0x0)<<12)
Please specify the mask manually to avoid ambiguities with result type.
+ CodingStyle
> +#define F_MMU_FAULT_VA_WRITE_BIT BIT(1)
> +#define F_MMU_FAULT_VA_LAYER_BIT BIT(0)
> +
> +#define REG_MMU_INVLD_PA(mmu) (0x140+((mmu)<<3))
> +#define REG_MMU_INT_ID(mmu) (0x150+((mmu)<<2))
> +#define F_MMU0_INT_ID_TF_MSK (~0x3) /* only for MM iommu. */
Ditto.
> +
> +#define MTK_TFID(larbid, portid) ((larbid << 7) | (portid << 2))
Missing parentheses around macro arguments.
> +
> +static const struct mtk_iommu_port mtk_iommu_mt8173_port[] = {
> + /* port namem4uid slaveid larbid portid tfid */
> + /* larb0 */
> + {"M4U_PORT_DISP_OVL0", 0, 0,0, 0, MTK_TFID(0, 0)},
> + {"M4U_PORT_DISP_RDMA0", 0, 0,0, 1, MTK_TFID(0, 1)},
> + {"M4U_PORT_DISP_WDMA0", 0, 0,0, 2, MTK_TFID(0, 2)},
> + {"M4U_PORT_DISP_OD_R", 0, 0,0, 3, MTK_TFID(0, 3)},
> + {"M4U_PORT_DISP_OD_W", 0, 0,0, 4, MTK_TFID(0, 4)},
> + {"M4U_POR
Re: [PATCH v4 0/4] net/macb: merge at91_ether driver into macb driver
From: Boris Brezillon Date: Sat, 7 Mar 2015 07:23:28 +0100 > The rm9200 boards use the dedicated at91_ether driver instead of the > regular macb driver. > > Both the macb and at91_ether drivers can be compiled as separated > modules. > Since the at91_ether driver uses code from the macb driver, at91_ether.ko > depends on macb.ko. > > However the macb.ko module always fails to load on rm9200 boards: the > macb_probe() function expects a hclk clock which doesn't exist on rm9200. > Then the at91_ether.ko can't be loaded in turn due to unresolved > dependencies. > > This series of patches fix this issue by merging at91_ether into macb. > > Patch 1 is fixing a problem that might happen when enabling ARM > multi-platform suppot. Series applied, thanks. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-sunxi] [PATCH 6/7] ARM: dts: sun7i: Add OOB irq support to boards with broadcom sdio wifi
On Sun, Mar 8, 2015 at 3:01 AM, Hans de Goede wrote:
> Signed-off-by: Hans de Goede
> ---
> arch/arm/boot/dts/sun7i-a20-cubietruck.dts | 11 +++
> arch/arm/boot/dts/sun7i-a20-i12-tvbox.dts | 11 +++
> 2 files changed, 22 insertions(+)
>
> diff --git a/arch/arm/boot/dts/sun7i-a20-cubietruck.dts
> b/arch/arm/boot/dts/sun7i-a20-cubietruck.dts
> index 0c219a4..8111b0c 100644
> --- a/arch/arm/boot/dts/sun7i-a20-cubietruck.dts
> +++ b/arch/arm/boot/dts/sun7i-a20-cubietruck.dts
> @@ -167,12 +167,23 @@
> };
>
> &mmc3 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> pinctrl-names = "default";
> pinctrl-0 = <&mmc3_pins_a>;
> vmmc-supply = <®_vmmc3>;
> bus-width = <4>;
> non-removable;
> status = "okay";
> +
> + brcmf: bcrmf@1 {
> + reg = <1>;
> + compatible = "brcm,bcm4329-fmac";
> + interrupt-parent = <&pio>;
> + interrupts = <10 8>; /* PH10 / EINT10 */
> + interrupt-names = "host-wake";
> + };
I gave this a spin on my Cubietruck. (I was running cap-sdio-irq before.)
Ran a few ping tests with a simple
"sudo ping -i 0.1 -I wlan0 -s 65500 192.168.1.1"
After a few runs I got
sunxi-mmc 1c12000.mmc: smc 1 err, cmd 53, RD SBE !!
sunxi-mmc 1c12000.mmc: data error, sending stop command
brcmfmac: brcmf_sdio_readframes: RXHEADER FAILED: -110
brcmfmac: brcmf_sdio_rxfail: abort command, terminate frame, send NAK
brcmfmac: brcmf_sdiod_regrw_helper: failed to write data F1@0x0a040, err: -5
brcmfmac: brcmf_sdio_hdparse: seq 226: sequence number error, expect 227
sunxi-mmc 1c12000.mmc: smc 1 err, cmd 53, RD DTO !!
sunxi-mmc 1c12000.mmc: data error, sending stop command
sunxi-mmc 1c12000.mmc: smc 1 err, cmd 53, RD DTO !!
sunxi-mmc 1c12000.mmc: data error, sending stop command
sunxi-mmc 1c12000.mmc: smc 1 err, cmd 53, RD DTO !!
sunxi-mmc 1c12000.mmc: data error, sending stop command
brcmfmac: brcmf_sdiod_regrw_helper: failed to read data F1@0x0a020, err: -110
brcmfmac: brcmf_sdio_dpc: failed backplane access over SDIO, halting operation
sunxi-mmc 1c12000.mmc: smc 1 err, cmd 53, RD DTO !!
sunxi-mmc 1c12000.mmc: data error, sending stop command
sunxi-mmc 1c12000.mmc: smc 1 err, cmd 53, RD DTO !!
sunxi-mmc 1c12000.mmc: data error, sending stop command
sunxi-mmc 1c12000.mmc: smc 1 err, cmd 53, RD DTO !!
sunxi-mmc 1c12000.mmc: data error, sending stop command
The chip is pretty much dead afterwards.
With cap-sdio-irq it doesn't happen so soon, but it does.
Without either, the response time is bad with packet losses,
but at least it doesn't die.
Is this the problem Arend (CC-ed) was looking into?
Regards
ChenYu
> };
>
> &mmc3_pins_a {
> diff --git a/arch/arm/boot/dts/sun7i-a20-i12-tvbox.dts
> b/arch/arm/boot/dts/sun7i-a20-i12-tvbox.dts
> index baee563..4a8defd 100644
> --- a/arch/arm/boot/dts/sun7i-a20-i12-tvbox.dts
> +++ b/arch/arm/boot/dts/sun7i-a20-i12-tvbox.dts
> @@ -164,12 +164,23 @@
> };
>
> &mmc3 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> pinctrl-names = "default";
> pinctrl-0 = <&mmc3_pins_a>;
> vmmc-supply = <®_vmmc3>;
> bus-width = <4>;
> non-removable;
> status = "okay";
> +
> + brcmf: bcrmf@1 {
> + reg = <1>;
> + compatible = "brcm,bcm4329-fmac";
> + interrupt-parent = <&pio>;
> + interrupts = <10 8>; /* PH10 / EINT10 */
> + interrupt-names = "host-wake";
> + };
> };
>
> &mmc3_pins_a {
> --
> 2.3.1
>
> --
> You received this message because you are subscribed to the Google Groups
> "linux-sunxi" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to linux-sunxi+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-sunxi] [PATCH 7/7] ARM: dts: sun7i: Enable cap-sdio-irq for bananapro sdio wifi
On Sun, Mar 8, 2015 at 3:01 AM, Hans de Goede wrote: > The sdio wifi on the Banana Pro does not appear to have an oob irq hooked > up, so enable sdio-irq support to avoid unnecessary polling. I wonder if this is stable enough to put back into the mmc driver, i.e. declare the capability in the driver itself? IIRC at one point it did. ChenYu > Signed-off-by: Hans de Goede > --- > arch/arm/boot/dts/sun7i-a20-bananapro.dts | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/arch/arm/boot/dts/sun7i-a20-bananapro.dts > b/arch/arm/boot/dts/sun7i-a20-bananapro.dts > index fb89fe7..d0cd78f 100644 > --- a/arch/arm/boot/dts/sun7i-a20-bananapro.dts > +++ b/arch/arm/boot/dts/sun7i-a20-bananapro.dts > @@ -164,6 +164,7 @@ > vmmc-supply = <®_vmmc3>; > bus-width = <4>; > non-removable; > + cap-sdio-irq; > status = "okay"; > }; > > -- > 2.3.1 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-sunxi] [PATCH 6/7] ARM: dts: sun7i: Add OOB irq support to boards with broadcom sdio wifi
Hi,
On Sun, Mar 8, 2015 at 3:01 AM, Hans de Goede wrote:
> Signed-off-by: Hans de Goede
> ---
> arch/arm/boot/dts/sun7i-a20-cubietruck.dts | 11 +++
> arch/arm/boot/dts/sun7i-a20-i12-tvbox.dts | 11 +++
> 2 files changed, 22 insertions(+)
>
> diff --git a/arch/arm/boot/dts/sun7i-a20-cubietruck.dts
> b/arch/arm/boot/dts/sun7i-a20-cubietruck.dts
> index 0c219a4..8111b0c 100644
> --- a/arch/arm/boot/dts/sun7i-a20-cubietruck.dts
> +++ b/arch/arm/boot/dts/sun7i-a20-cubietruck.dts
> @@ -167,12 +167,23 @@
> };
>
> &mmc3 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> pinctrl-names = "default";
> pinctrl-0 = <&mmc3_pins_a>;
> vmmc-supply = <®_vmmc3>;
> bus-width = <4>;
> non-removable;
> status = "okay";
> +
> + brcmf: bcrmf@1 {
> + reg = <1>;
> + compatible = "brcm,bcm4329-fmac";
> + interrupt-parent = <&pio>;
> + interrupts = <10 8>; /* PH10 / EINT10 */
^ IRQ_TYPE_LEVEL_LOW?
> + interrupt-names = "host-wake";
> + };
> };
>
> &mmc3_pins_a {
> diff --git a/arch/arm/boot/dts/sun7i-a20-i12-tvbox.dts
> b/arch/arm/boot/dts/sun7i-a20-i12-tvbox.dts
> index baee563..4a8defd 100644
> --- a/arch/arm/boot/dts/sun7i-a20-i12-tvbox.dts
> +++ b/arch/arm/boot/dts/sun7i-a20-i12-tvbox.dts
> @@ -164,12 +164,23 @@
> };
>
> &mmc3 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> pinctrl-names = "default";
> pinctrl-0 = <&mmc3_pins_a>;
> vmmc-supply = <®_vmmc3>;
> bus-width = <4>;
> non-removable;
> status = "okay";
> +
> + brcmf: bcrmf@1 {
> + reg = <1>;
> + compatible = "brcm,bcm4329-fmac";
> + interrupt-parent = <&pio>;
> + interrupts = <10 8>; /* PH10 / EINT10 */
Same here.
ChenYu
> + interrupt-names = "host-wake";
> + };
> };
>
> &mmc3_pins_a {
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/3] mtd: nand: add Broadcom NAND controller support
On Sun, Mar 08, 2015 at 01:01:14AM +0100, Rafał Miłecki wrote: > Thanks for your work on this. It looks amazing, nice piece of code :) Thanks :) And thanks for testing this. I believe I suggested to you that I'd be releasing this "soon" several months ago. Better late than never, I guess? > On 7 March 2015 at 02:18, Brian Norris wrote: > > This adds (long in coming) support for the Broadcom BCM7xxx Set-Top Box NAND > > controller. This controller has been used in a variety of Broadcom SoCs. > > > > There are a few more features I'd like add in the near future, mostly to > > support more SoCs, but this is the base set, which should only need > > relatively > > minor additions to support chips like BCM63138, BCM3384, and Cygnus/iProc. > > Particularly, we may need to straighten out some endianness issues for the > > data > > path on iProc, and interrupt enabling/acking on iProc, BCM63xxx, BCM3xxx, > > and > > others. > > After applying workaround for not working IRQ, it seems I have some > problem with endianess on my BCM4708 (SoC with 6.01 controller). > > Let me start with dumps of "nvram" MTD partition. > 1) Dumping with Netgear's original firmware: > # hexdump -C -n 16 mtdblock1.bin > 46 4c 53 48 40 79 00 00 84 01 00 00 47 01 1c 08 |FLSH@y..G...| > 2) Dumping with OpenWrt and its bcm_nand.c: > root@OpenWrt:/# hexdump -C -n 16 /dev/mtdblock1 > 46 4c 53 48 38 79 00 00 cb 01 00 00 47 01 1c 08 |FLSH8y..G...| > > This makes me feel that bcm_nand.c driver is OK. > Unfortunately when using brcmstb_nand.c my bcm47xxpart partition > driver didn't detect any partition at all. This means I couldn't use > any /dev/mtdblockX, not even user space as it wasn't mounted. > > So since I didn't have user space, I decided to add some debugging to > bcm47xxpart itself. There is what I got: > 1) OpenWrt and its bcm_nand.c: > [bcm47xxpart_parse] 0x8 46 4c 53 48 38 79 00 00 cb 01 00 00 47 01 1c > 08 > 2) OpenWrt and brcmstb_nand.c: > [bcm47xxpart_parse] 0x8 48 53 4c 46 00 00 79 38 00 00 01 cb 08 1c 01 > 47 > > So obviously data returned by brcmstb_nand.c seems to be all > endianess-flipped. Could you take a loo at this? I'll take a look at all your comments/questions when I get back into the office, but a few pointers: 1. IRQs are a touchy subject; for platforms I've supported, I've found it best if the NAND interrupt bits are handled in an irqchip driver. Particularly, that's one of the use cases for drivers/irqchip/irq-brcmstb-l2.c. If you can arrange the NAND enable/ack registers to act as a second-level interrupt controller, that should hopefully solve your problems. But if BCM4708's NAND interrupt registers can't be shaped into a sane irqchip driver, then we can probably handle them in a per-SoC extension of the driver. I have code already that supports another chip in this way, so I can point you that way if the first suggestion doesn't work out. 2. Endianness is a known issue with at least one other platform. On many chips (spanning MIPS LE, MIPS BE, and ARM LE), NAND has been integrated such that data can just be read/programmed in the native endianness through the FLASH_CACHE registers (as this driver does), but there are a few (on ARM, LE) that require a be32_to_cpu()/cpu_to_be32() swap. I'm considering supporting DT properties like one of the following: brcm,nand-cache-be brcm,nand-cache-big-endian brcm,nand-cache-reverse-endian You might also check (though I might actually be better equipped for this) if there is a separate register that can tell the NAND data bus to automatically endian-swap data into the native endianness. I know a lot of the buses and peripherals in BCG, at least, are designed such that either (1) they can work naturally in the CPU's native endianness or else (2) they can be configured to swap endianness into either format. But if such a register does not exist, then we'll definitely have to do something like the DT property above. Do the bad block markers look OK without extra endian swapping? I'm wondering whether the swapping will have to occur on both the FLASH_CACHE and SPARE_AREA registers. 3. I was told that there were only 2 or 3 chips that were released with a v6.1 NAND controller, and BCM4708 wasn't one of them. Apparently I was told wrong... I'll have to see if there are any other quirks we should be accounting for. Brian -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] mtd: nand: add NAND driver for Broadcom STB NAND controller
On 7 March 2015 at 18:39, Rafał Miłecki wrote: > It seems that brcmnand_ctlrdy_irq never fires on my device. Just like > controller was never generating any IRQ. > > > I started comparing your driver with OpenWrt's bcm_nand.c (which > should be very similar to Broadcom's SDK NAND driver for ARM). Below > are few things I've noticed. > > 1) In bcm_nand.c IRQ handler also doesn't seem to be fired (or very rarely). Oh, wait, I was wrong there. So in bcm_nand.c IRQ handler fires very often, just not during the early phase (RESET, READID), when we don't use IRQs. During standard read/program/etc IRQ is commonly used. So maybe all we're missing in case of brcmstb_nand.c is enabling/acking/disabling IRQ? It seem that my controller 6.01 has: 1) Following IRQs: DIREC_READ_MISS ERASE_COMPLETE COPYBACK_COMPLETE PROGRAM_COMPLETE CONTROLLER_RDY RDBSY_RDY ECC_UNCORRECTABLE ECC_CORRECTABLE 2) Registers for reading/acking above IRQs: 0xf00 DIREC_READ_MISS 0xf04 ERASE_COMPLETE 0xf08 COPYBACK_COMPLETE 0xf0c PROGRAM_COMPLETE 0xf10 CONTROLLER_RDY 0xf14 RDBSY_RDY 0xf18 ECC_UNCORRECTABLE 0xf1c ECC_CORRECTABLE (if 0x1 is set, it means IRQ was raised, writing 0x1 ack-es it) 3) Register 0x408 for enabling/disabling IRQs: 0x0004 DIREC_READ_MISS 0x0008 ERASE_COMPLETE 0x0010 COPYBACK_COMPLETE 0x0020 PROGRAM_COMPLETE 0x0040 CONTROLLER_RDY 0x0080 RDBSY_RDY 0x0100 ECC_UNCORRECTABLE 0x0200 ECC_CORRECTABLE -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 17/18] arm: dts: n950, n9: Add primary camera support
Hi Laurent,
On Sun, Mar 08, 2015 at 01:56:13AM +0200, Laurent Pinchart wrote:
> Hi Sakari,
>
> Thank you for the patch.
>
> On Saturday 07 March 2015 23:41:14 Sakari Ailus wrote:
> > Add support for the primary camera of the Nokia N950 and N9.
> >
> > Signed-off-by: Sakari Ailus
> > ---
> > arch/arm/boot/dts/omap3-n9.dts | 39 +++
> > arch/arm/boot/dts/omap3-n950-n9.dtsi |4
> > arch/arm/boot/dts/omap3-n950.dts | 39 +++
> > 3 files changed, 78 insertions(+), 4 deletions(-)
> >
> > diff --git a/arch/arm/boot/dts/omap3-n9.dts b/arch/arm/boot/dts/omap3-n9.dts
> > index 9938b5d..05f32ae 100644
> > --- a/arch/arm/boot/dts/omap3-n9.dts
> > +++ b/arch/arm/boot/dts/omap3-n9.dts
> > @@ -16,3 +16,42 @@
> > model = "Nokia N9";
> > compatible = "nokia,omap3-n9", "ti,omap36xx", "ti,omap3";
> > };
> > +
> > +&i2c2 {
> > + clock-frequency = <40>;
> > +
> > + smia_1: camera@10 {
> > + compatible = "nokia,smia";
> > + reg = <0x10>;
> > + /* No reset gpio */
> > + vana-supply = <&vaux3>;
> > + clocks = <&omap3_isp 0>;
> > + clock-frequency = <960>;
> > + nokia,nvm-size = <1024>; /* 16 * 64 */
>
> You could actually specify that as "<(16 * 64)>".
Will fix.
> > + link-frequencies = /bits/ 64 <19920 21000 49920>;
> > + port {
> > + smia_1_1: endpoint {
> > + clock-lanes = <0>;
> > + data-lanes = <1 2>;
> > + remote-endpoint = <&csi2a_ep>;
> > + };
> > + };
> > + };
> > +};
> > +
> > +&omap3_isp {
> > + vdd-csiphy1-supply = <&vaux2>;
> > + vdd-csiphy2-supply = <&vaux2>;
> > + ports {
> > + port@2 {
> > + reg = <2>;
> > + csi2a_ep: endpoint {
> > + remote-endpoint = <&smia_1_1>;
> > + clock-lanes = <2>;
> > + data-lanes = <1 3>;
> > + crc = <1>;
> > + lane-polarity = <1 1 1>;
> > + };
> > + };
> > + };
> > +};
> > diff --git a/arch/arm/boot/dts/omap3-n950-n9.dtsi
> > b/arch/arm/boot/dts/omap3-n950-n9.dtsi index c41db94..51e5043 100644
> > --- a/arch/arm/boot/dts/omap3-n950-n9.dtsi
> > +++ b/arch/arm/boot/dts/omap3-n950-n9.dtsi
> > @@ -86,10 +86,6 @@
> > regulator-max-microvolt = <280>;
> > };
> >
> > -&i2c2 {
> > - clock-frequency = <40>;
> > -};
> > -
>
> What's the reason for moving this to the N9 and N950 DT files as you keep the
> same value in both ?
Just before submitting the patches I thought someone might ask. :-D
I'll fix that.
> > &i2c3 {
> > clock-frequency = <40>;
> > };
> > diff --git a/arch/arm/boot/dts/omap3-n950.dts
> > b/arch/arm/boot/dts/omap3-n950.dts index 261c558..2b2ed9c 100644
> > --- a/arch/arm/boot/dts/omap3-n950.dts
> > +++ b/arch/arm/boot/dts/omap3-n950.dts
> > @@ -16,3 +16,42 @@
> > model = "Nokia N950";
> > compatible = "nokia,omap3-n950", "ti,omap36xx", "ti,omap3";
> > };
> > +
> > +&i2c2 {
> > + clock-frequency = <40>;
> > +
> > + smia_1: camera@10 {
> > + compatible = "nokia,smia";
> > + reg = <0x10>;
> > + /* No reset gpio */
> > + vana-supply = <&vaux3>;
> > + clocks = <&omap3_isp 0>;
> > + clock-frequency = <960>;
> > + nokia,nvm-size = <1024>; /* 16 * 64 */
> > + link-frequencies = /bits/ 64 <21000 33360 39840>;
> > + port {
> > + smia_1_1: endpoint {
> > + clock-lanes = <0>;
> > + data-lanes = <1 2>;
> > + remote-endpoint = <&csi2a_ep>;
> > + };
> > + };
> > + };
> > +};
> > +
> > +&omap3_isp {
> > + vdd-csiphy1-supply = <&vaux2>;
> > + vdd-csiphy2-supply = <&vaux2>;
> > + ports {
> > + port@2 {
> > + reg = <2>;
> > + csi2a_ep: endpoint {
> > + remote-endpoint = <&smia_1_1>;
> > + clock-lanes = <2>;
> > + data-lanes = <3 1>;
> > + crc = <1>;
> > + lane-polarity = <1 1 1>;
> > + };
> > + };
> > + };
> > +};
>
--
Kind regards,
Sakari Ailus
e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/3] mtd: nand: add Broadcom NAND controller support
Hi Brian, Thanks for your work on this. It looks amazing, nice piece of code :) On 7 March 2015 at 02:18, Brian Norris wrote: > This adds (long in coming) support for the Broadcom BCM7xxx Set-Top Box NAND > controller. This controller has been used in a variety of Broadcom SoCs. > > There are a few more features I'd like add in the near future, mostly to > support more SoCs, but this is the base set, which should only need relatively > minor additions to support chips like BCM63138, BCM3384, and Cygnus/iProc. > Particularly, we may need to straighten out some endianness issues for the > data > path on iProc, and interrupt enabling/acking on iProc, BCM63xxx, BCM3xxx, and > others. After applying workaround for not working IRQ, it seems I have some problem with endianess on my BCM4708 (SoC with 6.01 controller). Let me start with dumps of "nvram" MTD partition. 1) Dumping with Netgear's original firmware: # hexdump -C -n 16 mtdblock1.bin 46 4c 53 48 40 79 00 00 84 01 00 00 47 01 1c 08 |FLSH@y..G...| 2) Dumping with OpenWrt and its bcm_nand.c: root@OpenWrt:/# hexdump -C -n 16 /dev/mtdblock1 46 4c 53 48 38 79 00 00 cb 01 00 00 47 01 1c 08 |FLSH8y..G...| This makes me feel that bcm_nand.c driver is OK. Unfortunately when using brcmstb_nand.c my bcm47xxpart partition driver didn't detect any partition at all. This means I couldn't use any /dev/mtdblockX, not even user space as it wasn't mounted. So since I didn't have user space, I decided to add some debugging to bcm47xxpart itself. There is what I got: 1) OpenWrt and its bcm_nand.c: [bcm47xxpart_parse] 0x8 46 4c 53 48 38 79 00 00 cb 01 00 00 47 01 1c 08 2) OpenWrt and brcmstb_nand.c: [bcm47xxpart_parse] 0x8 48 53 4c 46 00 00 79 38 00 00 01 cb 08 1c 01 47 So obviously data returned by brcmstb_nand.c seems to be all endianess-flipped. Could you take a loo at this? -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 12/18] dt: bindings: Add lane-polarity property to endpoint nodes
Hi Laurent, On Sun, Mar 08, 2015 at 01:46:02AM +0200, Laurent Pinchart wrote: > Hi Sakari, > > Thank you for the patch. > > (CC'ing Sylwester) > > On Saturday 07 March 2015 23:41:09 Sakari Ailus wrote: > > Add lane-polarity property to endpoint nodes. This essentially tells that > > the order of the differential signal wires is inverted. > > > > Signed-off-by: Sakari Ailus > > --- > > Documentation/devicetree/bindings/media/video-interfaces.txt |5 + > > 1 file changed, 5 insertions(+) > > > > diff --git a/Documentation/devicetree/bindings/media/video-interfaces.txt > > b/Documentation/devicetree/bindings/media/video-interfaces.txt index > > 571b4c6..058d1e6 100644 > > --- a/Documentation/devicetree/bindings/media/video-interfaces.txt > > +++ b/Documentation/devicetree/bindings/media/video-interfaces.txt > > @@ -106,6 +106,11 @@ Optional endpoint properties > > - link-frequencies: Allowed data bus frequencies. For MIPI CSI-2, for > >instance, this is the actual frequency of the bus, not bits per clock per > > lane value. An array of 64-bit unsigned integers. > > +- lane-polarity: an array of polarities of the lanes starting from the > > clock > > + lane and followed by the data lanes in the same order as in data-lanes. > > + Valid values are 0 (normal) and 1 (inverted). > > Would it make sense to add #define's for this ? Good question. I don't really have too much of an opinion. I think I'd just use a number until someone else needs this. :-) > > The length of the array > > + should be the combined length of data-lanes and clock-lanes > > properties. > > + This property is valid for serial busses only. > > You should also document what happens when the property is omitted. Will add. -- Regards, Sakari Ailus e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 17/18] arm: dts: n950, n9: Add primary camera support
Hi Sakari,
Thank you for the patch.
On Saturday 07 March 2015 23:41:14 Sakari Ailus wrote:
> Add support for the primary camera of the Nokia N950 and N9.
>
> Signed-off-by: Sakari Ailus
> ---
> arch/arm/boot/dts/omap3-n9.dts | 39 +++
> arch/arm/boot/dts/omap3-n950-n9.dtsi |4
> arch/arm/boot/dts/omap3-n950.dts | 39 +++
> 3 files changed, 78 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm/boot/dts/omap3-n9.dts b/arch/arm/boot/dts/omap3-n9.dts
> index 9938b5d..05f32ae 100644
> --- a/arch/arm/boot/dts/omap3-n9.dts
> +++ b/arch/arm/boot/dts/omap3-n9.dts
> @@ -16,3 +16,42 @@
> model = "Nokia N9";
> compatible = "nokia,omap3-n9", "ti,omap36xx", "ti,omap3";
> };
> +
> +&i2c2 {
> + clock-frequency = <40>;
> +
> + smia_1: camera@10 {
> + compatible = "nokia,smia";
> + reg = <0x10>;
> + /* No reset gpio */
> + vana-supply = <&vaux3>;
> + clocks = <&omap3_isp 0>;
> + clock-frequency = <960>;
> + nokia,nvm-size = <1024>; /* 16 * 64 */
You could actually specify that as "<(16 * 64)>".
> + link-frequencies = /bits/ 64 <19920 21000 49920>;
> + port {
> + smia_1_1: endpoint {
> + clock-lanes = <0>;
> + data-lanes = <1 2>;
> + remote-endpoint = <&csi2a_ep>;
> + };
> + };
> + };
> +};
> +
> +&omap3_isp {
> + vdd-csiphy1-supply = <&vaux2>;
> + vdd-csiphy2-supply = <&vaux2>;
> + ports {
> + port@2 {
> + reg = <2>;
> + csi2a_ep: endpoint {
> + remote-endpoint = <&smia_1_1>;
> + clock-lanes = <2>;
> + data-lanes = <1 3>;
> + crc = <1>;
> + lane-polarity = <1 1 1>;
> + };
> + };
> + };
> +};
> diff --git a/arch/arm/boot/dts/omap3-n950-n9.dtsi
> b/arch/arm/boot/dts/omap3-n950-n9.dtsi index c41db94..51e5043 100644
> --- a/arch/arm/boot/dts/omap3-n950-n9.dtsi
> +++ b/arch/arm/boot/dts/omap3-n950-n9.dtsi
> @@ -86,10 +86,6 @@
> regulator-max-microvolt = <280>;
> };
>
> -&i2c2 {
> - clock-frequency = <40>;
> -};
> -
What's the reason for moving this to the N9 and N950 DT files as you keep the
same value in both ?
> &i2c3 {
> clock-frequency = <40>;
> };
> diff --git a/arch/arm/boot/dts/omap3-n950.dts
> b/arch/arm/boot/dts/omap3-n950.dts index 261c558..2b2ed9c 100644
> --- a/arch/arm/boot/dts/omap3-n950.dts
> +++ b/arch/arm/boot/dts/omap3-n950.dts
> @@ -16,3 +16,42 @@
> model = "Nokia N950";
> compatible = "nokia,omap3-n950", "ti,omap36xx", "ti,omap3";
> };
> +
> +&i2c2 {
> + clock-frequency = <40>;
> +
> + smia_1: camera@10 {
> + compatible = "nokia,smia";
> + reg = <0x10>;
> + /* No reset gpio */
> + vana-supply = <&vaux3>;
> + clocks = <&omap3_isp 0>;
> + clock-frequency = <960>;
> + nokia,nvm-size = <1024>; /* 16 * 64 */
> + link-frequencies = /bits/ 64 <21000 33360 39840>;
> + port {
> + smia_1_1: endpoint {
> + clock-lanes = <0>;
> + data-lanes = <1 2>;
> + remote-endpoint = <&csi2a_ep>;
> + };
> + };
> + };
> +};
> +
> +&omap3_isp {
> + vdd-csiphy1-supply = <&vaux2>;
> + vdd-csiphy2-supply = <&vaux2>;
> + ports {
> + port@2 {
> + reg = <2>;
> + csi2a_ep: endpoint {
> + remote-endpoint = <&smia_1_1>;
> + clock-lanes = <2>;
> + data-lanes = <3 1>;
> + crc = <1>;
> + lane-polarity = <1 1 1>;
> + };
> + };
> + };
> +};
--
Regards,
Laurent Pinchart
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 16/18] arm: dts: omap3: Add DT entries for OMAP 3
Hi Sakari,
Thank you for the patch.
On Saturday 07 March 2015 23:41:13 Sakari Ailus wrote:
> The resources the ISP needs are slightly different on 3[45]xx and 3[67]xx.
> Especially the phy-type property is different.
>
> Signed-off-by: Sakari Ailus
> ---
> arch/arm/boot/dts/omap34xx.dtsi | 15 +++
> arch/arm/boot/dts/omap36xx.dtsi | 15 +++
> 2 files changed, 30 insertions(+)
>
> diff --git a/arch/arm/boot/dts/omap34xx.dtsi
> b/arch/arm/boot/dts/omap34xx.dtsi index 3819c1e..4c034d0 100644
> --- a/arch/arm/boot/dts/omap34xx.dtsi
> +++ b/arch/arm/boot/dts/omap34xx.dtsi
> @@ -37,6 +37,21 @@
> pinctrl-single,register-width = <16>;
> pinctrl-single,function-mask = <0xff1f>;
> };
> +
> + omap3_isp: omap3_isp@480bc000 {
> + compatible = "ti,omap3-isp";
> + reg = <0x480bc000 0x12fc
> +0x480bd800 0x017c>;
> + interrupts = <24>;
> + iommus = <&mmu_isp>;
> + syscon = <&omap3_scm_general 0xdc>;
> + ti,phy-type = <0>;
> + #clock-cells = <1>;
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
How about predefining the ports too ?
> + };
> + };
> };
> };
>
> diff --git a/arch/arm/boot/dts/omap36xx.dtsi
> b/arch/arm/boot/dts/omap36xx.dtsi index 541704a..31ac41c 100644
> --- a/arch/arm/boot/dts/omap36xx.dtsi
> +++ b/arch/arm/boot/dts/omap36xx.dtsi
> @@ -69,6 +69,21 @@
> pinctrl-single,register-width = <16>;
> pinctrl-single,function-mask = <0xff1f>;
> };
> +
> + omap3_isp: omap3_isp@480bc000 {
> + compatible = "ti,omap3-isp";
> + reg = <0x480bc000 0x12fc
> +0x480bd800 0x0600>;
> + interrupts = <24>;
> + iommus = <&mmu_isp>;
> + syscon = <&omap3_scm_general 0x2f0>;
> + ti,phy-type = <1>;
> + #clock-cells = <1>;
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
And obviously here too.
> + };
> + };
> };
> };
--
Regards,
Laurent Pinchart
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 05/18] omap3isp: Platform data could be NULL
Hi Sakari,
Thank you for the patch.
On Saturday 07 March 2015 23:41:02 Sakari Ailus wrote:
> Only check for call platform data callback functions if there's platform
> data. Also take care of a few other cases where the NULL pdata pointer could
> have been accessed, and remove the check for NULL dev->platform_data
> pointer.
>
> Removing the check for NULL dev->platform_data isn't strictly needed by the
> DT support but there's no harm from that either: the device now can be used
> without sensors, for instance.
>
> Signed-off-by: Sakari Ailus
Acked-by: Laurent Pinchart
> ---
> drivers/media/platform/omap3isp/isp.c | 10 --
> drivers/media/platform/omap3isp/ispvideo.c |6 +++---
> 2 files changed, 7 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/media/platform/omap3isp/isp.c
> b/drivers/media/platform/omap3isp/isp.c index 01356dd..b836bc8 100644
> --- a/drivers/media/platform/omap3isp/isp.c
> +++ b/drivers/media/platform/omap3isp/isp.c
> @@ -330,8 +330,8 @@ static int isp_xclk_init(struct isp_device *isp)
> if (np)
> continue;
>
> - if (pdata->xclks[i].con_id == NULL &&
> - pdata->xclks[i].dev_id == NULL)
> + if (!pdata || (pdata->xclks[i].con_id == NULL &&
> +pdata->xclks[i].dev_id == NULL))
> continue;
>
> xclk->lookup = kzalloc(sizeof(*xclk->lookup), GFP_KERNEL);
> @@ -1989,7 +1989,8 @@ static int isp_register_entities(struct isp_device
> *isp) goto done;
>
> /* Register external entities */
> - for (subdevs = pdata->subdevs; subdevs && subdevs->subdevs; ++subdevs) {
> + for (subdevs = pdata ? pdata->subdevs : NULL;
> + subdevs && subdevs->subdevs; ++subdevs) {
> struct v4l2_subdev *sensor =
> isp_register_subdev_group(isp, subdevs->subdevs);
>
> @@ -2271,9 +2272,6 @@ static int isp_probe(struct platform_device *pdev)
> int ret;
> int i, m;
>
> - if (pdata == NULL)
> - return -EINVAL;
> -
> isp = devm_kzalloc(&pdev->dev, sizeof(*isp), GFP_KERNEL);
> if (!isp) {
> dev_err(&pdev->dev, "could not allocate memory\n");
> diff --git a/drivers/media/platform/omap3isp/ispvideo.c
> b/drivers/media/platform/omap3isp/ispvideo.c index 3fe9047..d644164 100644
> --- a/drivers/media/platform/omap3isp/ispvideo.c
> +++ b/drivers/media/platform/omap3isp/ispvideo.c
> @@ -1022,7 +1022,7 @@ isp_video_streamon(struct file *file, void *fh, enum
> v4l2_buf_type type)
>
> pipe->entities = 0;
>
> - if (video->isp->pdata->set_constraints)
> + if (video->isp->pdata && video->isp->pdata->set_constraints)
> video->isp->pdata->set_constraints(video->isp, true);
> pipe->l3_ick = clk_get_rate(video->isp->clock[ISP_CLK_L3_ICK]);
> pipe->max_rate = pipe->l3_ick;
> @@ -1104,7 +1104,7 @@ err_set_stream:
> err_check_format:
> media_entity_pipeline_stop(&video->video.entity);
> err_pipeline_start:
> - if (video->isp->pdata->set_constraints)
> + if (video->isp->pdata && video->isp->pdata->set_constraints)
> video->isp->pdata->set_constraints(video->isp, false);
> /* The DMA queue must be emptied here, otherwise CCDC interrupts that
>* will get triggered the next time the CCDC is powered up will try to
> @@ -1165,7 +1165,7 @@ isp_video_streamoff(struct file *file, void *fh, enum
> v4l2_buf_type type) video->queue = NULL;
> video->error = false;
>
> - if (video->isp->pdata->set_constraints)
> + if (video->isp->pdata && video->isp->pdata->set_constraints)
> video->isp->pdata->set_constraints(video->isp, false);
> media_entity_pipeline_stop(&video->video.entity);
--
Regards,
Laurent Pinchart
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 13/18] v4l: of: Read lane-polarity endpoint property
Hi Sakari,
Thank you for the patch.
On Saturday 07 March 2015 23:41:10 Sakari Ailus wrote:
> Add lane_polarity field to struct v4l2_of_bus_mipi_csi2 and write the
> contents of the lane polarity property to it. The field tells the polarity
> of the physical lanes starting from the first one. Any unused lanes are
> ignored, i.e. only the polarity of the used lanes is specified.
>
> Signed-off-by: Sakari Ailus
> ---
> drivers/media/v4l2-core/v4l2-of.c | 21 -
> include/media/v4l2-of.h |3 +++
> 2 files changed, 19 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/media/v4l2-core/v4l2-of.c
> b/drivers/media/v4l2-core/v4l2-of.c index b4ed9a9..a7a855e 100644
> --- a/drivers/media/v4l2-core/v4l2-of.c
> +++ b/drivers/media/v4l2-core/v4l2-of.c
> @@ -23,7 +23,6 @@ static void v4l2_of_parse_csi_bus(const struct device_node
> *node, struct v4l2_of_endpoint *endpoint)
> {
> struct v4l2_of_bus_mipi_csi2 *bus = &endpoint->bus.mipi_csi2;
> - u32 data_lanes[ARRAY_SIZE(bus->data_lanes)];
> struct property *prop;
> bool have_clk_lane = false;
> unsigned int flags = 0;
> @@ -34,14 +33,26 @@ static void v4l2_of_parse_csi_bus(const struct
> device_node *node, const __be32 *lane = NULL;
> int i;
>
> - for (i = 0; i < ARRAY_SIZE(data_lanes); i++) {
> - lane = of_prop_next_u32(prop, lane, &data_lanes[i]);
> + for (i = 0; i < ARRAY_SIZE(bus->data_lanes); i++) {
> + lane = of_prop_next_u32(prop, lane, &v);
> if (!lane)
> break;
> + bus->data_lanes[i] = v;
> }
> bus->num_data_lanes = i;
> - while (i--)
> - bus->data_lanes[i] = data_lanes[i];
> + }
> +
> + prop = of_find_property(node, "lane-polarity", NULL);
> + if (prop) {
> + const __be32 *polarity = NULL;
> + int i;
Could you please use unsigned int instead of int as the loop index can't have
negative value ? Feel free to fix the index in the previous loop too :-)
> +
> + for (i = 0; i < ARRAY_SIZE(bus->lane_polarity); i++) {
> + polarity = of_prop_next_u32(prop, polarity, &v);
> + if (!polarity)
> + break;
> + bus->lane_polarity[i] = v;
> + }
Should we check that i == num_data_lines + 1 ?
> }
>
> if (!of_property_read_u32(node, "clock-lanes", &v)) {
> diff --git a/include/media/v4l2-of.h b/include/media/v4l2-of.h
> index 70fa7b7..a70eb52 100644
> --- a/include/media/v4l2-of.h
> +++ b/include/media/v4l2-of.h
> @@ -29,12 +29,15 @@ struct device_node;
> * @data_lanes: an array of physical data lane indexes
> * @clock_lane: physical lane index of the clock lane
> * @num_data_lanes: number of data lanes
> + * @lane_polarity: polarity of the lanes. The order is the same of
> + * the physical lanes.
> */
> struct v4l2_of_bus_mipi_csi2 {
> unsigned int flags;
> unsigned char data_lanes[4];
> unsigned char clock_lane;
> unsigned short num_data_lanes;
> + bool lane_polarity[5];
> };
>
> /**
--
Regards,
Laurent Pinchart
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 12/18] dt: bindings: Add lane-polarity property to endpoint nodes
Hi Sakari, Thank you for the patch. (CC'ing Sylwester) On Saturday 07 March 2015 23:41:09 Sakari Ailus wrote: > Add lane-polarity property to endpoint nodes. This essentially tells that > the order of the differential signal wires is inverted. > > Signed-off-by: Sakari Ailus > --- > Documentation/devicetree/bindings/media/video-interfaces.txt |5 + > 1 file changed, 5 insertions(+) > > diff --git a/Documentation/devicetree/bindings/media/video-interfaces.txt > b/Documentation/devicetree/bindings/media/video-interfaces.txt index > 571b4c6..058d1e6 100644 > --- a/Documentation/devicetree/bindings/media/video-interfaces.txt > +++ b/Documentation/devicetree/bindings/media/video-interfaces.txt > @@ -106,6 +106,11 @@ Optional endpoint properties > - link-frequencies: Allowed data bus frequencies. For MIPI CSI-2, for >instance, this is the actual frequency of the bus, not bits per clock per > lane value. An array of 64-bit unsigned integers. > +- lane-polarity: an array of polarities of the lanes starting from the > clock > + lane and followed by the data lanes in the same order as in data-lanes. > + Valid values are 0 (normal) and 1 (inverted). Would it make sense to add #define's for this ? > The length of the array > + should be the combined length of data-lanes and clock-lanes > properties. > + This property is valid for serial busses only. You should also document what happens when the property is omitted. > Example -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 10/18] omap3isp: Move the syscon register out of the ISP register maps
Hi Laurent,
On Sun, Mar 08, 2015 at 01:34:17AM +0200, Laurent Pinchart wrote:
> Hi Sakari,
>
> Thank you for the patch.
>
> (CC'ing linux-omap and Tony)
Thanks.
> On Saturday 07 March 2015 23:41:07 Sakari Ailus wrote:
> > The syscon register isn't part of the ISP, use it through the syscom driver
> > regmap instead. The syscom block is considered to be from 343x on ISP
> > revision 2.0 whereas 15.0 is assumed to have 3630 syscon.
> >
> > Signed-off-by: Sakari Ailus
> > ---
> > arch/arm/boot/dts/omap3.dtsi|2 +-
> > arch/arm/mach-omap2/devices.c | 10 --
> > drivers/media/platform/omap3isp/isp.c | 19 +++
> > drivers/media/platform/omap3isp/isp.h | 19 +--
> > drivers/media/platform/omap3isp/ispcsiphy.c | 20 +---
>
> You might be asked to split the patch into two, let's see what Tony says.
>
> > 5 files changed, 42 insertions(+), 28 deletions(-)
> >
> > diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
> > index 01b7111..fe0b293 100644
> > --- a/arch/arm/boot/dts/omap3.dtsi
> > +++ b/arch/arm/boot/dts/omap3.dtsi
> > @@ -183,7 +183,7 @@
> >
> > omap3_scm_general: tisyscon@48002270 {
> > compatible = "syscon";
> > - reg = <0x48002270 0x2f0>;
> > + reg = <0x48002270 0x2f4>;
> > };
> >
> > pbias_regulator: pbias_regulator {
> > diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
> > index 1afb50d..e945957 100644
> > --- a/arch/arm/mach-omap2/devices.c
> > +++ b/arch/arm/mach-omap2/devices.c
> > @@ -143,16 +143,6 @@ static struct resource omap3isp_resources[] = {
> > .flags = IORESOURCE_MEM,
> > },
> > {
> > - .start = OMAP343X_CTRL_BASE + OMAP343X_CONTROL_CSIRXFE,
> > - .end= OMAP343X_CTRL_BASE + OMAP343X_CONTROL_CSIRXFE
> > + 3,
> > - .flags = IORESOURCE_MEM,
> > - },
> > - {
> > - .start = OMAP343X_CTRL_BASE +
> > OMAP3630_CONTROL_CAMERA_PHY_CTRL,
> > - .end= OMAP343X_CTRL_BASE +
> > OMAP3630_CONTROL_CAMERA_PHY_CTRL + 3,
> > - .flags = IORESOURCE_MEM,
> > - },
> > - {
> > .start = 24 + OMAP_INTC_START,
> > .flags = IORESOURCE_IRQ,
> > }
> > diff --git a/drivers/media/platform/omap3isp/isp.c
> > b/drivers/media/platform/omap3isp/isp.c index 68d7edfc..4ff4bbd 100644
> > --- a/drivers/media/platform/omap3isp/isp.c
> > +++ b/drivers/media/platform/omap3isp/isp.c
> > @@ -51,6 +51,7 @@
> > #include
> > #include
> > #include
> > +#include
> > #include
> > #include
> > #include
> > @@ -94,8 +95,9 @@ static const struct isp_res_mapping isp_res_maps[] = {
> >1 << OMAP3_ISP_IOMEM_RESZ |
> >1 << OMAP3_ISP_IOMEM_SBL |
> >1 << OMAP3_ISP_IOMEM_CSI2A_REGS1 |
> > - 1 << OMAP3_ISP_IOMEM_CSIPHY2 |
> > - 1 << OMAP3_ISP_IOMEM_343X_CONTROL_CSIRXFE,
> > + 1 << OMAP3_ISP_IOMEM_CSIPHY2,
> > + .syscon_offset = 0xdc,
> > + .phy_type = ISP_PHY_TYPE_3430,
> > },
> > {
> > .isp_rev = ISP_REVISION_15_0,
> > @@ -112,8 +114,9 @@ static const struct isp_res_mapping isp_res_maps[] = {
> >1 << OMAP3_ISP_IOMEM_CSI2A_REGS2 |
> >1 << OMAP3_ISP_IOMEM_CSI2C_REGS1 |
> >1 << OMAP3_ISP_IOMEM_CSIPHY1 |
> > - 1 << OMAP3_ISP_IOMEM_CSI2C_REGS2 |
> > - 1 << OMAP3_ISP_IOMEM_3630_CONTROL_CAMERA_PHY_CTRL,
> > + 1 << OMAP3_ISP_IOMEM_CSI2C_REGS2,
> > + .syscon_offset = 0x2f0,
> > + .phy_type = ISP_PHY_TYPE_3630,
> > },
> > };
> >
> > @@ -2352,6 +2355,14 @@ static int isp_probe(struct platform_device *pdev)
> > }
> > }
> >
> > + isp->syscon = syscon_regmap_lookup_by_pdevname("syscon.0");
> > + isp->syscon_offset = isp_res_maps[m].syscon_offset;
> > + isp->phy_type = isp_res_maps[m].phy_type;
>
> You could move those two lines after the error check to keep the check closer
> to the source of error.
Ack.
> Apart from that,
>
> Acked-by: Laurent Pinchart
Thanks for the acks!
--
Kind regards,
Sakari Ailus
e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 11/18] omap3isp: Replace many MMIO regions by two
Hi Sakari,
Thank you for the patch.
(CC'ing linux-omap and Tony)
On Saturday 07 March 2015 23:41:08 Sakari Ailus wrote:
> The omap3isp MMIO register block is contiguous in the MMIO register space
> apart from the fact that the ISP IOMMU register block is in the middle of
> the area. Ioremap it at two occasions, and keep the rest of the layout of
> the register space internal to the omap3isp driver.
>
> Signed-off-by: Sakari Ailus
Acked-by: Laurent Pinchart
> ---
> arch/arm/mach-omap2/devices.c | 66 +--
> arch/arm/mach-omap2/omap34xx.h| 36 +--
Once again you might be asked to split this. However, it would be pretty
painful, so it would be nice if we could merge everything through the Linux
media tree. You will need an ack from Tony.
> drivers/media/platform/omap3isp/isp.c | 113 --
> drivers/media/platform/omap3isp/isp.h |4 +-
> 4 files changed, 66 insertions(+), 153 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
> index e945957..990338f 100644
> --- a/arch/arm/mach-omap2/devices.c
> +++ b/arch/arm/mach-omap2/devices.c
> @@ -74,72 +74,12 @@ omap_postcore_initcall(omap3_l3_init);
> static struct resource omap3isp_resources[] = {
> {
> .start = OMAP3430_ISP_BASE,
> - .end= OMAP3430_ISP_END,
> + .end= OMAP3430_ISP_BASE + 0x12fc,
> .flags = IORESOURCE_MEM,
> },
> {
> - .start = OMAP3430_ISP_CCP2_BASE,
> - .end= OMAP3430_ISP_CCP2_END,
> - .flags = IORESOURCE_MEM,
> - },
> - {
> - .start = OMAP3430_ISP_CCDC_BASE,
> - .end= OMAP3430_ISP_CCDC_END,
> - .flags = IORESOURCE_MEM,
> - },
> - {
> - .start = OMAP3430_ISP_HIST_BASE,
> - .end= OMAP3430_ISP_HIST_END,
> - .flags = IORESOURCE_MEM,
> - },
> - {
> - .start = OMAP3430_ISP_H3A_BASE,
> - .end= OMAP3430_ISP_H3A_END,
> - .flags = IORESOURCE_MEM,
> - },
> - {
> - .start = OMAP3430_ISP_PREV_BASE,
> - .end= OMAP3430_ISP_PREV_END,
> - .flags = IORESOURCE_MEM,
> - },
> - {
> - .start = OMAP3430_ISP_RESZ_BASE,
> - .end= OMAP3430_ISP_RESZ_END,
> - .flags = IORESOURCE_MEM,
> - },
> - {
> - .start = OMAP3430_ISP_SBL_BASE,
> - .end= OMAP3430_ISP_SBL_END,
> - .flags = IORESOURCE_MEM,
> - },
> - {
> - .start = OMAP3430_ISP_CSI2A_REGS1_BASE,
> - .end= OMAP3430_ISP_CSI2A_REGS1_END,
> - .flags = IORESOURCE_MEM,
> - },
> - {
> - .start = OMAP3430_ISP_CSIPHY2_BASE,
> - .end= OMAP3430_ISP_CSIPHY2_END,
> - .flags = IORESOURCE_MEM,
> - },
> - {
> - .start = OMAP3630_ISP_CSI2A_REGS2_BASE,
> - .end= OMAP3630_ISP_CSI2A_REGS2_END,
> - .flags = IORESOURCE_MEM,
> - },
> - {
> - .start = OMAP3630_ISP_CSI2C_REGS1_BASE,
> - .end= OMAP3630_ISP_CSI2C_REGS1_END,
> - .flags = IORESOURCE_MEM,
> - },
> - {
> - .start = OMAP3630_ISP_CSIPHY1_BASE,
> - .end= OMAP3630_ISP_CSIPHY1_END,
> - .flags = IORESOURCE_MEM,
> - },
> - {
> - .start = OMAP3630_ISP_CSI2C_REGS2_BASE,
> - .end= OMAP3630_ISP_CSI2C_REGS2_END,
> + .start = OMAP3430_ISP_BASE2,
> + .end= OMAP3430_ISP_BASE2 + 0x0600,
> .flags = IORESOURCE_MEM,
> },
> {
> diff --git a/arch/arm/mach-omap2/omap34xx.h b/arch/arm/mach-omap2/omap34xx.h
> index c0d1b4b..ed0024d 100644
> --- a/arch/arm/mach-omap2/omap34xx.h
> +++ b/arch/arm/mach-omap2/omap34xx.h
> @@ -46,39 +46,9 @@
>
> #define OMAP34XX_IC_BASE 0x4820
>
> -#define OMAP3430_ISP_BASE(L4_34XX_BASE + 0xBC000)
> -#define OMAP3430_ISP_CBUFF_BASE (OMAP3430_ISP_BASE + 0x0100)
> -#define OMAP3430_ISP_CCP2_BASE (OMAP3430_ISP_BASE + 0x0400)
> -#define OMAP3430_ISP_CCDC_BASE (OMAP3430_ISP_BASE + 0x0600)
> -#define OMAP3430_ISP_HIST_BASE (OMAP3430_ISP_BASE + 0x0A00)
> -#define OMAP3430_ISP_H3A_BASE(OMAP3430_ISP_BASE + 0x0C00)
> -#define OMAP3430_ISP_PREV_BASE (OMAP3430_ISP_BASE + 0x0E00)
> -#define OMAP3430_ISP_RESZ_BASE (OMAP3430_ISP_BASE + 0x1000)
> -#
Re: [RFC 18/18] omap3isp: Deprecate platform data support
Hi Sakari,
Thank you for the patch.
On Saturday 07 March 2015 23:41:15 Sakari Ailus wrote:
> Print a warning when the driver is used with platform data. Existing
> platform data user should move to DT now.
>
> Signed-off-by: Sakari Ailus
Acked-by: Laurent Pinchart
> ---
> drivers/media/platform/omap3isp/isp.c |2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/media/platform/omap3isp/isp.c
> b/drivers/media/platform/omap3isp/isp.c index 2c9bc0d..e4a78bb 100644
> --- a/drivers/media/platform/omap3isp/isp.c
> +++ b/drivers/media/platform/omap3isp/isp.c
> @@ -2447,6 +2447,8 @@ static int isp_probe(struct platform_device *pdev)
> isp->syscon = syscon_regmap_lookup_by_pdevname("syscon.0");
> if (IS_ERR(isp->syscon))
> return PTR_ERR(isp->syscon);
> + dev_warn(&pdev->dev,
> + "Platform data support is deprecated! Please move to
> DT now!
\n");
> }
>
> isp->autoidle = autoidle;
--
Regards,
Laurent Pinchart
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 10/18] omap3isp: Move the syscon register out of the ISP register maps
Hi Sakari,
Thank you for the patch.
(CC'ing linux-omap and Tony)
On Saturday 07 March 2015 23:41:07 Sakari Ailus wrote:
> The syscon register isn't part of the ISP, use it through the syscom driver
> regmap instead. The syscom block is considered to be from 343x on ISP
> revision 2.0 whereas 15.0 is assumed to have 3630 syscon.
>
> Signed-off-by: Sakari Ailus
> ---
> arch/arm/boot/dts/omap3.dtsi|2 +-
> arch/arm/mach-omap2/devices.c | 10 --
> drivers/media/platform/omap3isp/isp.c | 19 +++
> drivers/media/platform/omap3isp/isp.h | 19 +--
> drivers/media/platform/omap3isp/ispcsiphy.c | 20 +---
You might be asked to split the patch into two, let's see what Tony says.
> 5 files changed, 42 insertions(+), 28 deletions(-)
>
> diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
> index 01b7111..fe0b293 100644
> --- a/arch/arm/boot/dts/omap3.dtsi
> +++ b/arch/arm/boot/dts/omap3.dtsi
> @@ -183,7 +183,7 @@
>
> omap3_scm_general: tisyscon@48002270 {
> compatible = "syscon";
> - reg = <0x48002270 0x2f0>;
> + reg = <0x48002270 0x2f4>;
> };
>
> pbias_regulator: pbias_regulator {
> diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
> index 1afb50d..e945957 100644
> --- a/arch/arm/mach-omap2/devices.c
> +++ b/arch/arm/mach-omap2/devices.c
> @@ -143,16 +143,6 @@ static struct resource omap3isp_resources[] = {
> .flags = IORESOURCE_MEM,
> },
> {
> - .start = OMAP343X_CTRL_BASE + OMAP343X_CONTROL_CSIRXFE,
> - .end= OMAP343X_CTRL_BASE + OMAP343X_CONTROL_CSIRXFE
> + 3,
> - .flags = IORESOURCE_MEM,
> - },
> - {
> - .start = OMAP343X_CTRL_BASE +
> OMAP3630_CONTROL_CAMERA_PHY_CTRL,
> - .end= OMAP343X_CTRL_BASE +
> OMAP3630_CONTROL_CAMERA_PHY_CTRL + 3,
> - .flags = IORESOURCE_MEM,
> - },
> - {
> .start = 24 + OMAP_INTC_START,
> .flags = IORESOURCE_IRQ,
> }
> diff --git a/drivers/media/platform/omap3isp/isp.c
> b/drivers/media/platform/omap3isp/isp.c index 68d7edfc..4ff4bbd 100644
> --- a/drivers/media/platform/omap3isp/isp.c
> +++ b/drivers/media/platform/omap3isp/isp.c
> @@ -51,6 +51,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -94,8 +95,9 @@ static const struct isp_res_mapping isp_res_maps[] = {
> 1 << OMAP3_ISP_IOMEM_RESZ |
> 1 << OMAP3_ISP_IOMEM_SBL |
> 1 << OMAP3_ISP_IOMEM_CSI2A_REGS1 |
> -1 << OMAP3_ISP_IOMEM_CSIPHY2 |
> -1 << OMAP3_ISP_IOMEM_343X_CONTROL_CSIRXFE,
> +1 << OMAP3_ISP_IOMEM_CSIPHY2,
> + .syscon_offset = 0xdc,
> + .phy_type = ISP_PHY_TYPE_3430,
> },
> {
> .isp_rev = ISP_REVISION_15_0,
> @@ -112,8 +114,9 @@ static const struct isp_res_mapping isp_res_maps[] = {
> 1 << OMAP3_ISP_IOMEM_CSI2A_REGS2 |
> 1 << OMAP3_ISP_IOMEM_CSI2C_REGS1 |
> 1 << OMAP3_ISP_IOMEM_CSIPHY1 |
> -1 << OMAP3_ISP_IOMEM_CSI2C_REGS2 |
> -1 << OMAP3_ISP_IOMEM_3630_CONTROL_CAMERA_PHY_CTRL,
> +1 << OMAP3_ISP_IOMEM_CSI2C_REGS2,
> + .syscon_offset = 0x2f0,
> + .phy_type = ISP_PHY_TYPE_3630,
> },
> };
>
> @@ -2352,6 +2355,14 @@ static int isp_probe(struct platform_device *pdev)
> }
> }
>
> + isp->syscon = syscon_regmap_lookup_by_pdevname("syscon.0");
> + isp->syscon_offset = isp_res_maps[m].syscon_offset;
> + isp->phy_type = isp_res_maps[m].phy_type;
You could move those two lines after the error check to keep the check closer
to the source of error.
Apart from that,
Acked-by: Laurent Pinchart
> + if (IS_ERR(isp->syscon)) {
> + ret = PTR_ERR(isp->syscon);
> + goto error_isp;
> + }
> +
> /* IOMMU */
> ret = isp_attach_iommu(isp);
> if (ret < 0) {
> diff --git a/drivers/media/platform/omap3isp/isp.h
> b/drivers/media/platform/omap3isp/isp.h index 9535524..03d2129 100644
> --- a/drivers/media/platform/omap3isp/isp.h
> +++ b/drivers/media/platform/omap3isp/isp.h
> @@ -59,8 +59,6 @@ enum isp_mem_resources {
> OMAP3_ISP_IOMEM_CSI2C_REGS1,
> OMAP3_ISP_IOMEM_CSIPHY1,
> OMAP3_ISP_IOMEM_CSI2C_REGS2,
> - OMAP3_ISP_IOMEM_343X_CONTROL_CSIRXFE,
> - OMAP3_ISP_IOMEM_3630_CONTROL_CAMERA_PHY_CTRL,
> OMAP3_ISP_IOMEM_LAST
> };
>
> @@ -93,14 +91,25 @@ enum isp_subclk_resource {
> /* ISP2P: OMAP 36xx */
> #define ISP_REVISION_15_00xF0
>
> +#define ISP_PHY_TY
Re: [RFC 08/18] omap3isp: Calculate vpclk_div for CSI-2
Hi Sakari,
Thank you for the patch.
On Saturday 07 March 2015 23:41:05 Sakari Ailus wrote:
> The video port clock is l3_ick divided by vpclk_div. This clock must be high
> enough for the external pixel rate. The video port requires two clock
> cycles to process a pixel.
>
> Signed-off-by: Sakari Ailus
Acked-by: Laurent Pinchart
> ---
> drivers/media/platform/omap3isp/ispcsi2.c |8 +++-
> include/media/omap3isp.h |2 --
> 2 files changed, 7 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/media/platform/omap3isp/ispcsi2.c
> b/drivers/media/platform/omap3isp/ispcsi2.c index 14d279d..97cdfeb 100644
> --- a/drivers/media/platform/omap3isp/ispcsi2.c
> +++ b/drivers/media/platform/omap3isp/ispcsi2.c
> @@ -548,6 +548,7 @@ int omap3isp_csi2_reset(struct isp_csi2_device *csi2)
>
> static int csi2_configure(struct isp_csi2_device *csi2)
> {
> + struct isp_pipeline *pipe = to_isp_pipeline(&csi2->subdev.entity);
> const struct isp_bus_cfg *buscfg;
> struct isp_device *isp = csi2->isp;
> struct isp_csi2_timing_cfg *timing = &csi2->timing[0];
> @@ -570,7 +571,12 @@ static int csi2_configure(struct isp_csi2_device *csi2)
> csi2->frame_skip = 0;
> v4l2_subdev_call(sensor, sensor, g_skip_frames, &csi2->frame_skip);
>
> - csi2->ctrl.vp_out_ctrl = buscfg->bus.csi2.vpclk_div;
> + csi2->ctrl.vp_out_ctrl =
> + clamp_t(unsigned int, pipe->l3_ick / pipe->external_rate - 1,
> + 1, 3);
> + dev_dbg(isp->dev, "%s: l3_ick %lu, external_rate %u, vp_out_ctrl %u\n",
> + __func__, pipe->l3_ick, pipe->external_rate,
> + csi2->ctrl.vp_out_ctrl);
> csi2->ctrl.frame_mode = ISP_CSI2_FRAME_IMMEDIATE;
> csi2->ctrl.ecc_enable = buscfg->bus.csi2.crc;
>
> diff --git a/include/media/omap3isp.h b/include/media/omap3isp.h
> index 39e0748..0f0c08b 100644
> --- a/include/media/omap3isp.h
> +++ b/include/media/omap3isp.h
> @@ -129,11 +129,9 @@ struct isp_ccp2_cfg {
> /**
> * struct isp_csi2_cfg - CSI2 interface configuration
> * @crc: Enable the cyclic redundancy check
> - * @vpclk_div: Video port output clock control
> */
> struct isp_csi2_cfg {
> unsigned crc:1;
> - unsigned vpclk_div:2;
> struct isp_csiphy_lanes_cfg lanecfg;
> };
--
Regards,
Laurent Pinchart
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 09/18] omap3isp: Replace mmio_base_phys array with the histogram block base
Hi Sakari,
Thank you for the patch.
On Saturday 07 March 2015 23:41:06 Sakari Ailus wrote:
> Only the histogram sub-block driver uses the physical address. Do not store
> it for other sub-blocks.
>
> Signed-off-by: Sakari Ailus
Acked-by: Laurent Pinchart
> ---
> drivers/media/platform/omap3isp/isp.c |3 ++-
> drivers/media/platform/omap3isp/isp.h |6 +++---
> drivers/media/platform/omap3isp/isphist.c |2 +-
> 3 files changed, 6 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/media/platform/omap3isp/isp.c
> b/drivers/media/platform/omap3isp/isp.c index c045318..68d7edfc 100644
> --- a/drivers/media/platform/omap3isp/isp.c
> +++ b/drivers/media/platform/omap3isp/isp.c
> @@ -2247,7 +2247,8 @@ static int isp_map_mem_resource(struct platform_device
> *pdev, if (IS_ERR(isp->mmio_base[res]))
> return PTR_ERR(isp->mmio_base[res]);
>
> - isp->mmio_base_phys[res] = mem->start;
> + if (res == OMAP3_ISP_IOMEM_HIST)
> + isp->mmio_hist_base_phys = mem->start;
>
> return 0;
> }
> diff --git a/drivers/media/platform/omap3isp/isp.h
> b/drivers/media/platform/omap3isp/isp.h index b932a6f..9535524 100644
> --- a/drivers/media/platform/omap3isp/isp.h
> +++ b/drivers/media/platform/omap3isp/isp.h
> @@ -138,8 +138,8 @@ struct isp_xclk {
> * @irq_num: Currently used IRQ number.
> * @mmio_base: Array with kernel base addresses for ioremapped ISP register
> * regions.
> - * @mmio_base_phys: Array with physical L4 bus addresses for ISP register
> - * regions.
> + * @mmio_hist_base_phys: Physical L4 bus address for ISP hist block
> register + * region.
> * @mapping: IOMMU mapping
> * @stat_lock: Spinlock for handling statistics
> * @isp_mutex: Mutex for serializing requests to ISP.
> @@ -175,7 +175,7 @@ struct isp_device {
> unsigned int irq_num;
>
> void __iomem *mmio_base[OMAP3_ISP_IOMEM_LAST];
> - unsigned long mmio_base_phys[OMAP3_ISP_IOMEM_LAST];
> + unsigned long mmio_hist_base_phys;
>
> struct dma_iommu_mapping *mapping;
>
> diff --git a/drivers/media/platform/omap3isp/isphist.c
> b/drivers/media/platform/omap3isp/isphist.c index ce822c3..3bb9c4f 100644
> --- a/drivers/media/platform/omap3isp/isphist.c
> +++ b/drivers/media/platform/omap3isp/isphist.c
> @@ -70,7 +70,7 @@ static void hist_dma_config(struct ispstat *hist)
> hist->dma_config.sync_mode = OMAP_DMA_SYNC_ELEMENT;
> hist->dma_config.frame_count = 1;
> hist->dma_config.src_amode = OMAP_DMA_AMODE_CONSTANT;
> - hist->dma_config.src_start = isp->mmio_base_phys[OMAP3_ISP_IOMEM_HIST]
> + hist->dma_config.src_start = isp->mmio_hist_base_phys
> + ISPHIST_DATA;
> hist->dma_config.dst_amode = OMAP_DMA_AMODE_POST_INC;
> hist->dma_config.src_or_dst_synch = OMAP_DMA_SRC_SYNC;
--
Regards,
Laurent Pinchart
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/10] omap3 crypto fixes
Hi, On Fri, Feb 27, 2015 at 01:40:44PM +0100, Pali Rohár wrote: > > However I get these when CONFIG_CRYPTO_MANAGER_DISABLE_TESTS > > is not set: > > > > alg: hash: Chunking test 1 failed for omap-sha1 > > alg: hash: Chunking test 1 failed for omap-md5 > > alg: hash: Chunking test 1 failed for omap-hmac-sha1 > > alg: hash: Chunking test 1 failed for omap-hmac-md5 BTW, it seems these errors are reported to be introduced possibly somewhere between 3.11 and 3.15: https://lists.fedoraproject.org/pipermail/arm/2014-August/008240.html A. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 07/18] omap3isp: Rename regulators to better suit the Device Tree
Hi Sakari, Thank you for the patch. On Saturday 07 March 2015 23:41:04 Sakari Ailus wrote: > Rename VDD_CSIPHY1 as vdd-csiphy1 and VDD_CSIPHY2 as vdd-csiphy2. > > Signed-off-by: Sakari Ailus Acked-by: Laurent Pinchart > --- > drivers/media/platform/omap3isp/isp.c |4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/media/platform/omap3isp/isp.c > b/drivers/media/platform/omap3isp/isp.c index 1b5c6df..c045318 100644 > --- a/drivers/media/platform/omap3isp/isp.c > +++ b/drivers/media/platform/omap3isp/isp.c > @@ -2292,8 +2292,8 @@ static int isp_probe(struct platform_device *pdev) > platform_set_drvdata(pdev, isp); > > /* Regulators */ > - isp->isp_csiphy1.vdd = devm_regulator_get(&pdev->dev, "VDD_CSIPHY1"); > - isp->isp_csiphy2.vdd = devm_regulator_get(&pdev->dev, "VDD_CSIPHY2"); > + isp->isp_csiphy1.vdd = devm_regulator_get(&pdev->dev, "vdd-csiphy1"); > + isp->isp_csiphy2.vdd = devm_regulator_get(&pdev->dev, "vdd-csiphy2"); > > /* Clocks >* -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 03/18] omap3isp: Separate external link creation from platform data parsing
Hi Sakari,
Thank you for the patch.
On Saturday 07 March 2015 23:41:00 Sakari Ailus wrote:
> Move the code which connects the external entity to an ISP entity into a
> separate function. This disconnects it from parsing the platform data.
>
> Signed-off-by: Sakari Ailus
> ---
> drivers/media/platform/omap3isp/isp.c | 147 +++--
> 1 file changed, 74 insertions(+), 73 deletions(-)
>
> diff --git a/drivers/media/platform/omap3isp/isp.c
> b/drivers/media/platform/omap3isp/isp.c index 4ab674d..a607f26 100644
> --- a/drivers/media/platform/omap3isp/isp.c
> +++ b/drivers/media/platform/omap3isp/isp.c
> @@ -1832,6 +1832,77 @@ isp_register_subdev_group(struct isp_device *isp,
> return sensor;
> }
>
> +static int isp_link_entity(
> + struct isp_device *isp, struct media_entity *entity,
> + enum isp_interface_type interface)
> +{
> + struct media_entity *input;
> + unsigned int flags;
> + unsigned int pad;
> + unsigned int i;
> +
> + /* Connect the sensor to the correct interface module.
> + * Parallel sensors are connected directly to the CCDC, while
> + * serial sensors are connected to the CSI2a, CCP2b or CSI2c
> + * receiver through CSIPHY1 or CSIPHY2.
> + */
> + switch (interface) {
> + case ISP_INTERFACE_PARALLEL:
> + input = &isp->isp_ccdc.subdev.entity;
> + pad = CCDC_PAD_SINK;
> + flags = 0;
> + break;
> +
> + case ISP_INTERFACE_CSI2A_PHY2:
> + input = &isp->isp_csi2a.subdev.entity;
> + pad = CSI2_PAD_SINK;
> + flags = MEDIA_LNK_FL_IMMUTABLE | MEDIA_LNK_FL_ENABLED;
> + break;
> +
> + case ISP_INTERFACE_CCP2B_PHY1:
> + case ISP_INTERFACE_CCP2B_PHY2:
> + input = &isp->isp_ccp2.subdev.entity;
> + pad = CCP2_PAD_SINK;
> + flags = 0;
> + break;
> +
> + case ISP_INTERFACE_CSI2C_PHY1:
> + input = &isp->isp_csi2c.subdev.entity;
> + pad = CSI2_PAD_SINK;
> + flags = MEDIA_LNK_FL_IMMUTABLE | MEDIA_LNK_FL_ENABLED;
> + break;
> +
> + default:
> + dev_err(isp->dev, "%s: invalid interface type %u\n", __func__,
> + interface);
> + return -EINVAL;
> + }
> +
> + /*
> + * Not all interfaces are available on all revisions of the
> + * ISP. The sub-devices of those interfaces aren't initialised
> + * in such a case. Check this by ensuring the num_pads is
> + * non-zero.
> + */
> + if (!input->num_pads) {
> + dev_err(isp->dev, "%s: invalid input %u\n", entity->name,
> + interface);
> + return -EINVAL;
> + }
> +
> + for (i = 0; i < entity->num_pads; i++) {
> + if (entity->pads[i].flags & MEDIA_PAD_FL_SOURCE)
> + break;
> + }
> + if (i == entity->num_pads) {
> + dev_err(isp->dev, "%s: no source pad in external entity\n",
> + __func__);
> + return -EINVAL;
> + }
> +
> + return media_entity_create_link(entity, i, input, pad, flags);
> +}
> +
> static int isp_register_entities(struct isp_device *isp)
> {
> struct isp_platform_data *pdata = isp->pdata;
> @@ -1894,85 +1965,15 @@ static int isp_register_entities(struct isp_device
> *isp)
>
> /* Register external entities */
> for (subdevs = pdata->subdevs; subdevs && subdevs->subdevs; ++subdevs) {
> - struct v4l2_subdev *sensor;
> - struct media_entity *input;
> - unsigned int flags;
> - unsigned int pad;
> - unsigned int i;
> + struct v4l2_subdev *sensor =
> + isp_register_subdev_group(isp, subdevs->subdevs);
>
> - sensor = isp_register_subdev_group(isp, subdevs->subdevs);
Nit-picking a bit, I'd keep the variable declaration and the function call
separate here, as isp_register_subdev_group() is much more than an
initializer. Apart from that,
Acked-by: Laurent Pinchart
> if (sensor == NULL)
> continue;
>
> sensor->host_priv = subdevs;
>
> - /* Connect the sensor to the correct interface module. Parallel
> - * sensors are connected directly to the CCDC, while serial
> - * sensors are connected to the CSI2a, CCP2b or CSI2c receiver
> - * through CSIPHY1 or CSIPHY2.
> - */
> - switch (subdevs->interface) {
> - case ISP_INTERFACE_PARALLEL:
> - input = &isp->isp_ccdc.subdev.entity;
> - pad = CCDC_PAD_SINK;
> - flags = 0;
> - break;
> -
> - case ISP_INTERFACE_CSI2A_PHY2:
> - input = &isp->isp_csi2a.subdev.entity;
> - pad = CSI2_PAD_SINK;
> - flags = MEDIA
Re: [RFC 02/18] omap3isp: Avoid a BUG_ON() in media_entity_create_link()
Hi Sakari,
Thank you for the patch.
On Saturday 07 March 2015 23:40:59 Sakari Ailus wrote:
> If an uninitialised v4l2_subdev struct was passed to
> media_entity_create_link(), one of the BUG_ON()'s in the function will be
> hit since media_entity.num_pads will be zero. Avoid this by checking whether
> the num_pads field is non-zero for the interface.
>
> Signed-off-by: Sakari Ailus
Acked-by: Laurent Pinchart
> ---
> drivers/media/platform/omap3isp/isp.c | 13 +
> 1 file changed, 13 insertions(+)
>
> diff --git a/drivers/media/platform/omap3isp/isp.c
> b/drivers/media/platform/omap3isp/isp.c index fb193b6..4ab674d 100644
> --- a/drivers/media/platform/omap3isp/isp.c
> +++ b/drivers/media/platform/omap3isp/isp.c
> @@ -1946,6 +1946,19 @@ static int isp_register_entities(struct isp_device
> *isp) goto done;
> }
>
> + /*
> + * Not all interfaces are available on all revisions
> + * of the ISP. The sub-devices of those interfaces
> + * aren't initialised in such a case. Check this by
> + * ensuring the num_pads is non-zero.
> + */
> + if (!input->num_pads) {
> + dev_err(isp->dev, "%s: invalid input %u\n",
> + entity->name, subdevs->interface);
> + ret = -EINVAL;
> + goto done;
> + }
> +
> for (i = 0; i < sensor->entity.num_pads; i++) {
> if (sensor->entity.pads[i].flags & MEDIA_PAD_FL_SOURCE)
> break;
--
Regards,
Laurent Pinchart
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 01/18] omap3isp: Fix error handling in probe
Hi Sakari, Thank you for the patch. On Saturday 07 March 2015 23:40:58 Sakari Ailus wrote: > The mutex was not destroyed correctly if dma_coerce_mask_and_coherent() > failed for some reason. > > Signed-off-by: Sakari Ailus Acked-by: Laurent Pinchart > --- > drivers/media/platform/omap3isp/isp.c |2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/media/platform/omap3isp/isp.c > b/drivers/media/platform/omap3isp/isp.c index deca809..fb193b6 100644 > --- a/drivers/media/platform/omap3isp/isp.c > +++ b/drivers/media/platform/omap3isp/isp.c > @@ -2252,7 +2252,7 @@ static int isp_probe(struct platform_device *pdev) > > ret = dma_coerce_mask_and_coherent(isp->dev, DMA_BIT_MASK(32)); > if (ret) > - return ret; > + goto error; > > platform_set_drvdata(pdev, isp); -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3] media: i2c: add support for omnivision's ov2659 sensor
On Sat, 2015-03-07 at 15:21 +, Lad Prabhakar wrote:
> --- /dev/null
> +++ b/drivers/media/i2c/ov2659.c
> @@ -0,0 +1,1495 @@
> +/*
> + * Omnivision OV2659 CMOS Image Sensor driver
> + *
> + * Copyright (C) 2015 Texas Instruments, Inc.
> + *
> + * Benoit Parrot
> + * Lad, Prabhakar
> + *
> + * This program is free software; you may redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; version 2 of the License.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
> + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
> + * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
> + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS
> + * BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN
> + * ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
> + * CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
> + * SOFTWARE.
> + */
This states the license of this modules is GPL v2.
> +MODULE_LICENSE("GPL");
So you probably want
MODULE_LICENSE("GPL v2");
here.
(If you think this is a bit silly, and somewhere I think so too, you're
invited to jump into the discussion starting at
https://lkml.org/lkml/2015/3/7/119 .)
Paul Bolle
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] Input: add support for Semtech SX8654 I2C touchscreen controller
On Sat, 2015-03-07 at 14:26 -0800, Dmitry Torokhov wrote: > On March 7, 2015 2:12:20 PM PST, Paul Bolle wrote: > I was talking about them being treated differently from technological > standpoint (i.e. the code), not from legal one. >From a technological standpoint it would be easy to declare "GPL" (or any other string) to mean "GPL v2 compatible", which is, I think, all that matters. But license_is_gpl_compatible() doesn't do that. And I fear that's for a reason. Is my fear unfounded? > If you want to fix up input drivers I'll take such patch, but I am > sure more such cases will sneak in unless you also make sure that > there are tools (such as checkpatch.pl) that can alert developers to >the inconsistency. checkpatch.pl crossed my mind too. But in just over a week of checking the license comments of (a subset of) the submitted patches I've come to think that just won't work. Paul Bolle -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] Input: add support for Semtech SX8654 I2C touchscreen controller
On March 7, 2015 2:12:20 PM PST, Paul Bolle wrote: >On Sat, 2015-03-07 at 14:02 -0800, Dmitry Torokhov wrote: >> On March 7, 2015 1:54:41 PM PST, Paul Bolle >wrote: >> >By that logic we might as well simplify the logic of >> >license_is_gpl_compatible() and MODULE_LICENSE() quite a bit. Why >check >> >for six variants instead of just one and be done with it? >> >> Because nobody wants to go through hundreds of drivers and change >them? > >Not fun, but surely doable. > >> >Anyhow, "GPL" and "GPL v2" are both allowed but not identical. So, >> >unless a patch is applied to treat them interchangeably, somehow, in >> >the module license checking code, >> >> They are treated interchangeably as far as I can see. Where do you >see >> "GPL" is being treated differently than "GPL v2". > >I'm not going to explain here why "GPL v2" or "GPL v2 or later" differ. I was talking about them being treated differently from technological standpoint (i.e. the code), not from legal one. > >"GPL" is documented to mean "GPL v2 or later". "GPL v2" is documented >to >mean just that (see include/linux/module.h). Again, you're free to >submit a patch to somehow simplify that. But unless a patch like that >is >applied, we should make sure MODULE_LICENSE() matches the actual >license >of the module involved. If you want to fix up input drivers I'll take such patch, but I am sure more such cases will sneak in unless you also make sure that there are tools (such as checkpatch.pl) that can alert developers to the inconsistency. Thanks. -- Dmitry -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] mtd: nand: add NAND driver for Broadcom STB NAND controller
On 7 March 2015 at 02:18, Brian Norris wrote:
> +static int brcmnand_waitfunc(struct mtd_info *mtd, struct nand_chip *this)
> +{
> + struct nand_chip *chip = mtd->priv;
> + struct brcmnand_host *host = chip->priv;
> + struct brcmnand_controller *ctrl = host->ctrl;
> + unsigned long timeo = msecs_to_jiffies(100);
> +
> + dev_dbg(ctrl->dev, "wait on native cmd %d\n", ctrl->cmd_pending);
> + if (ctrl->cmd_pending &&
> + wait_for_completion_timeout(&ctrl->done, timeo) <= 0)
> {
> + unsigned long cmd = brcmnand_read_reg(ctrl,
> BRCMNAND_CMD_START)
> + >> brcmnand_cmd_shift(ctrl);
> +
> + dev_err_ratelimited(ctrl->dev,
> + "timeout waiting for command %u (%ld)\n",
> + host->last_cmd, cmd);
I think that using host->last_cmd in the above message is really
misleading. Please consider following:
[2.061139] [brcmnand_cmdfunc:1151] command:0x90 native_cmd:0x07
[2.067123] brcmstb_nand 18028000.nand: send native cmd 7 addr_lo 0x40
[2.168395] brcmstb_nand 18028000.nand: timeout waiting for command 144 (7)
[2.175321] brcmstb_nand 18028000.nand: intfc status f000
[2.181051] nand: device found, Manufacturer ID: 0x92, Chip ID: 0xf1
[2.187370] nand: Eon NAND 128MiB 3,3V 8-bit
[2.191632] nand: 128 MiB, SLC, erase size: 128 KiB, page size:
2048, OOB size: 64
[2.199192] brcmstb_nand 18028000.nand: detected 128MiB total,
128KiB blocks, 2KiB pages, 16B OOB, 8-bit, BCH-8
[2.199192]
[2.210724] Scanning device for bad blocks
[2.214812] brcmstb_nand 18028000.nand: send native cmd 1 addr_lo 0x0
[2.318394] brcmstb_nand 18028000.nand: timeout waiting for command 144 (1)
As you can see, first there was a brcmnand_cmdfunc call with 0x90
(NAND_CMD_READID). It was translated into internal command 0x07
(CMD_DEVICE_ID_READ).
Then there was a call to brcmnand_read_by_pio which resulted in
sending internal command 0x01 (CMD_PAGE_READ). This one overwrote
previous command. So the timeout wasn't about 144 (0x90) anymore.
I suggest replacing that with something like
"timeout waiting for internal command 0x%02x\n", cmd
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] Input: add support for Semtech SX8654 I2C touchscreen controller
On Sat, 2015-03-07 at 14:02 -0800, Dmitry Torokhov wrote: > On March 7, 2015 1:54:41 PM PST, Paul Bolle wrote: > >By that logic we might as well simplify the logic of > >license_is_gpl_compatible() and MODULE_LICENSE() quite a bit. Why check > >for six variants instead of just one and be done with it? > > Because nobody wants to go through hundreds of drivers and change them? Not fun, but surely doable. > >Anyhow, "GPL" and "GPL v2" are both allowed but not identical. So, > >unless a patch is applied to treat them interchangeably, somehow, in > >the module license checking code, > > They are treated interchangeably as far as I can see. Where do you see > "GPL" is being treated differently than "GPL v2". I'm not going to explain here why "GPL v2" or "GPL v2 or later" differ. "GPL" is documented to mean "GPL v2 or later". "GPL v2" is documented to mean just that (see include/linux/module.h). Again, you're free to submit a patch to somehow simplify that. But unless a patch like that is applied, we should make sure MODULE_LICENSE() matches the actual license of the module involved. Paul Bolle -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] Input: add support for Semtech SX8654 I2C touchscreen controller
On March 7, 2015 1:54:41 PM PST, Paul Bolle wrote:
>On Sat, 2015-03-07 at 13:25 -0800, Dmitry Torokhov wrote:
>> I am not sure if anyone cares about exact version of GPL in module
>> information (2 only vs 2+) since it only used to figure out if the
>> module taints kernel or not. In fact there are more modules that are
>v2
>> only that claim GPL than the ones claiming GPL v2.
>>
>> dtor@dtor-ws:~/kernel/master$ for file in `grep -r -l
>'MODULE_LICENSE("GPL")'`; do grep -H '2 as published' $file; done | wc
>-l
>> 259
>> dtor@dtor-ws:~/kernel/master$ for file in `grep -r -l
>'MODULE_LICENSE("GPL v2")'`; do grep -H '2 as published' $file; do ne |
>wc -l
>> 150
>>
>> Also:
>>
>> dtor@dtor-ws:~/kernel/master$ for file in `grep -r -l
>'MODULE_LICENSE("GPL v2")'`; do grep -H '2 or ' $file; done | wc -l
>> 68
>> dtor@dtor-ws:~/kernel/master$ for file in `grep -r -l
>'MODULE_LICENSE("GPL")'`; do grep -H '2 or ' $file; done | wc -l
>> 237
>
>By that logic we might as well simplify the logic of
>license_is_gpl_compatible() and MODULE_LICENSE() quite a bit. Why check
>for six variants instead of just one and be done with it?
Because nobody wants to go through hundreds of drivers and change them?
>
>Anyhow, "GPL" and "GPL v2" are both allowed but not identical. So,
>unless a patch is applied to treat them interchangeably, somehow, in
>the
>module license checking code,
They are treated interchangeably as far as I can see. Where do you see "GPL" is
being treated differently than "GPL v2".
> we ought to make each instance of
>MODULE_LICENSE() match the actual license of the module it's used for.
>
>Yes, that's annoying. You're free to submit a patch to end all the
>busywork this brings along. But I fear there's a reason for all that
>busywork. Please prove me wrong. It would make everyone's life a bit
>easier.
>
>
>Paul Bolle
Thanks.
--
Dmitry
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3] media: i2c: add support for omnivision's ov2659 sensor
Hi Prabhakar, On Sat, Mar 07, 2015 at 03:21:40PM +, Lad Prabhakar wrote: > + pixel-clock-frequency = <7000>; As commented privately, could you use the link-frequencies property for this purpose? On parallel bus if often equals the pixel clock, but works much better on serial busses. It'd documented in video-interfaces.txt. -- Kind regards, Sakari Ailus e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] Input: add support for Semtech SX8654 I2C touchscreen controller
On Sat, 2015-03-07 at 13:25 -0800, Dmitry Torokhov wrote:
> I am not sure if anyone cares about exact version of GPL in module
> information (2 only vs 2+) since it only used to figure out if the
> module taints kernel or not. In fact there are more modules that are v2
> only that claim GPL than the ones claiming GPL v2.
>
> dtor@dtor-ws:~/kernel/master$ for file in `grep -r -l
> 'MODULE_LICENSE("GPL")'`; do grep -H '2 as published' $file; done | wc -l
> 259
> dtor@dtor-ws:~/kernel/master$ for file in `grep -r -l 'MODULE_LICENSE("GPL
> v2")'`; do grep -H '2 as published' $file; do ne | wc -l
> 150
>
> Also:
>
> dtor@dtor-ws:~/kernel/master$ for file in `grep -r -l 'MODULE_LICENSE("GPL
> v2")'`; do grep -H '2 or ' $file; done | wc -l
> 68
> dtor@dtor-ws:~/kernel/master$ for file in `grep -r -l
> 'MODULE_LICENSE("GPL")'`; do grep -H '2 or ' $file; done | wc -l
> 237
By that logic we might as well simplify the logic of
license_is_gpl_compatible() and MODULE_LICENSE() quite a bit. Why check
for six variants instead of just one and be done with it?
Anyhow, "GPL" and "GPL v2" are both allowed but not identical. So,
unless a patch is applied to treat them interchangeably, somehow, in the
module license checking code, we ought to make each instance of
MODULE_LICENSE() match the actual license of the module it's used for.
Yes, that's annoying. You're free to submit a patch to end all the
busywork this brings along. But I fear there's a reason for all that
busywork. Please prove me wrong. It would make everyone's life a bit
easier.
Paul Bolle
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] mtd: nand: add NAND driver for Broadcom STB NAND controller
On 7 March 2015 at 18:39, Rafał Miłecki wrote: > On 7 March 2015 at 02:18, Brian Norris wrote: >> This core originated in Set-Top Box chips (BCM7xxx) but is used in a >> variety of other Broadcom chips, including some BCM63xxx, BCM33xx, and >> iProc/Cygnus. It's been used only on ARM and MIPS SoCs, so restrict it >> to those architectures. >> >> There are multiple revisions of this core throughout the years, and >> almost every version broke register compatibility in some small way, but >> with some effort, this driver is able to support v4.0, v5.0, v6.x, v7.0, >> and v7.1. It's been tested on v5.0, v6.0, v7.0, and v7.1 recently, so >> there hopefully are no more lurking inconsistencies. > > Unfortunately, it seems I can't make this driver work with my BCM4708 > based router. This is a SoC with 6.01 controller. > > Sometimes I get this: > [0.478443] brcmstb_nand 18028000.nand: timeout waiting for command 255 (9) > [0.485385] brcmstb_nand 18028000.nand: intfc status f000 > [0.588393] brcmstb_nand 18028000.nand: timeout waiting for command 144 (7) > [0.595326] brcmstb_nand 18028000.nand: intfc status f000 > [0.698392] brcmstb_nand 18028000.nand: timeout waiting for command 144 (7) > [0.705322] brcmstb_nand 18028000.nand: intfc status f000 > [0.711051] nand: second ID read did not match 20,20 against 20,00 > [0.717197] nand: No NAND device found > > Other time: > [0.478441] brcmstb_nand 18028000.nand: timeout waiting for command 255 (9) > [0.485385] brcmstb_nand 18028000.nand: intfc status f000 > [0.588396] brcmstb_nand 18028000.nand: timeout waiting for command 144 (7) > [0.595327] brcmstb_nand 18028000.nand: intfc status f000 > [0.698393] brcmstb_nand 18028000.nand: timeout waiting for command 144 (7) > [0.705321] brcmstb_nand 18028000.nand: intfc status f000 > [0.808394] brcmstb_nand 18028000.nand: timeout waiting for command 144 (7) > [0.815326] brcmstb_nand 18028000.nand: intfc status f000 > [0.918392] brcmstb_nand 18028000.nand: timeout waiting for command 144 (7) > [0.925322] brcmstb_nand 18028000.nand: intfc status f000 > [0.931047] nand: No NAND device found > > (Btw. I guess you could use 0x%x instead of %d for printing commands). > > It seems that brcmnand_ctlrdy_irq never fires on my device. Just like > controller was never generating any IRQ. Oh, damn, I was doing sth stupid. I copied example from Documentation which has "brcm,nandcs" with reg = <1>;. That was wrong of course. after changing chip from 1 to 0 I got: [1.688413] brcmstb_nand 18028000.nand: timeout waiting for command 255 (9) [1.695355] brcmstb_nand 18028000.nand: intfc status f000 [1.808384] brcmstb_nand 18028000.nand: timeout waiting for command 144 (7) [1.815320] brcmstb_nand 18028000.nand: intfc status f000 [1.928385] brcmstb_nand 18028000.nand: timeout waiting for command 144 (7) [1.935312] brcmstb_nand 18028000.nand: intfc status f000 [2.048460] brcmstb_nand 18028000.nand: timeout waiting for command 144 (7) [2.055392] brcmstb_nand 18028000.nand: intfc status f000 [2.168386] brcmstb_nand 18028000.nand: timeout waiting for command 144 (7) [2.175315] brcmstb_nand 18028000.nand: intfc status f000 [2.185640] nand: device found, Manufacturer ID: 0x92, Chip ID: 0xf1 [2.191967] nand: Eon NAND 128MiB 3,3V 8-bit [2.196221] nand: 128 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64 [2.203784] brcmstb_nand 18028000.nand: detected 128MiB total, 128KiB blocks, 2KiB pages, 16B OOB, 8-bit, BCH-8 So there is still problem with lacking IRQ (and timeouts), but at least communication with chip looks OK in general. Of course the lost of log is also spammed in these "timeout waiting" and driver is unusable. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC 16/18] arm: dts: omap3: Add DT entries for OMAP 3
The resources the ISP needs are slightly different on 3[45]xx and 3[67]xx.
Especially the phy-type property is different.
Signed-off-by: Sakari Ailus
---
arch/arm/boot/dts/omap34xx.dtsi | 15 +++
arch/arm/boot/dts/omap36xx.dtsi | 15 +++
2 files changed, 30 insertions(+)
diff --git a/arch/arm/boot/dts/omap34xx.dtsi b/arch/arm/boot/dts/omap34xx.dtsi
index 3819c1e..4c034d0 100644
--- a/arch/arm/boot/dts/omap34xx.dtsi
+++ b/arch/arm/boot/dts/omap34xx.dtsi
@@ -37,6 +37,21 @@
pinctrl-single,register-width = <16>;
pinctrl-single,function-mask = <0xff1f>;
};
+
+ omap3_isp: omap3_isp@480bc000 {
+ compatible = "ti,omap3-isp";
+ reg = <0x480bc000 0x12fc
+ 0x480bd800 0x017c>;
+ interrupts = <24>;
+ iommus = <&mmu_isp>;
+ syscon = <&omap3_scm_general 0xdc>;
+ ti,phy-type = <0>;
+ #clock-cells = <1>;
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+ };
};
};
diff --git a/arch/arm/boot/dts/omap36xx.dtsi b/arch/arm/boot/dts/omap36xx.dtsi
index 541704a..31ac41c 100644
--- a/arch/arm/boot/dts/omap36xx.dtsi
+++ b/arch/arm/boot/dts/omap36xx.dtsi
@@ -69,6 +69,21 @@
pinctrl-single,register-width = <16>;
pinctrl-single,function-mask = <0xff1f>;
};
+
+ omap3_isp: omap3_isp@480bc000 {
+ compatible = "ti,omap3-isp";
+ reg = <0x480bc000 0x12fc
+ 0x480bd800 0x0600>;
+ interrupts = <24>;
+ iommus = <&mmu_isp>;
+ syscon = <&omap3_scm_general 0x2f0>;
+ ti,phy-type = <1>;
+ #clock-cells = <1>;
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+ };
};
};
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC 12/18] dt: bindings: Add lane-polarity property to endpoint nodes
Add lane-polarity property to endpoint nodes. This essentially tells that the order of the differential signal wires is inverted. Signed-off-by: Sakari Ailus --- Documentation/devicetree/bindings/media/video-interfaces.txt |5 + 1 file changed, 5 insertions(+) diff --git a/Documentation/devicetree/bindings/media/video-interfaces.txt b/Documentation/devicetree/bindings/media/video-interfaces.txt index 571b4c6..058d1e6 100644 --- a/Documentation/devicetree/bindings/media/video-interfaces.txt +++ b/Documentation/devicetree/bindings/media/video-interfaces.txt @@ -106,6 +106,11 @@ Optional endpoint properties - link-frequencies: Allowed data bus frequencies. For MIPI CSI-2, for instance, this is the actual frequency of the bus, not bits per clock per lane value. An array of 64-bit unsigned integers. +- lane-polarity: an array of polarities of the lanes starting from the clock + lane and followed by the data lanes in the same order as in data-lanes. + Valid values are 0 (normal) and 1 (inverted). The length of the array + should be the combined length of data-lanes and clock-lanes properties. + This property is valid for serial busses only. Example -- 1.7.10.4 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC 08/18] omap3isp: Calculate vpclk_div for CSI-2
The video port clock is l3_ick divided by vpclk_div. This clock must be high
enough for the external pixel rate. The video port requires two clock cycles
to process a pixel.
Signed-off-by: Sakari Ailus
---
drivers/media/platform/omap3isp/ispcsi2.c |8 +++-
include/media/omap3isp.h |2 --
2 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/media/platform/omap3isp/ispcsi2.c
b/drivers/media/platform/omap3isp/ispcsi2.c
index 14d279d..97cdfeb 100644
--- a/drivers/media/platform/omap3isp/ispcsi2.c
+++ b/drivers/media/platform/omap3isp/ispcsi2.c
@@ -548,6 +548,7 @@ int omap3isp_csi2_reset(struct isp_csi2_device *csi2)
static int csi2_configure(struct isp_csi2_device *csi2)
{
+ struct isp_pipeline *pipe = to_isp_pipeline(&csi2->subdev.entity);
const struct isp_bus_cfg *buscfg;
struct isp_device *isp = csi2->isp;
struct isp_csi2_timing_cfg *timing = &csi2->timing[0];
@@ -570,7 +571,12 @@ static int csi2_configure(struct isp_csi2_device *csi2)
csi2->frame_skip = 0;
v4l2_subdev_call(sensor, sensor, g_skip_frames, &csi2->frame_skip);
- csi2->ctrl.vp_out_ctrl = buscfg->bus.csi2.vpclk_div;
+ csi2->ctrl.vp_out_ctrl =
+ clamp_t(unsigned int, pipe->l3_ick / pipe->external_rate - 1,
+ 1, 3);
+ dev_dbg(isp->dev, "%s: l3_ick %lu, external_rate %u, vp_out_ctrl %u\n",
+ __func__, pipe->l3_ick, pipe->external_rate,
+ csi2->ctrl.vp_out_ctrl);
csi2->ctrl.frame_mode = ISP_CSI2_FRAME_IMMEDIATE;
csi2->ctrl.ecc_enable = buscfg->bus.csi2.crc;
diff --git a/include/media/omap3isp.h b/include/media/omap3isp.h
index 39e0748..0f0c08b 100644
--- a/include/media/omap3isp.h
+++ b/include/media/omap3isp.h
@@ -129,11 +129,9 @@ struct isp_ccp2_cfg {
/**
* struct isp_csi2_cfg - CSI2 interface configuration
* @crc: Enable the cyclic redundancy check
- * @vpclk_div: Video port output clock control
*/
struct isp_csi2_cfg {
unsigned crc:1;
- unsigned vpclk_div:2;
struct isp_csiphy_lanes_cfg lanecfg;
};
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC 04/18] omap3isp: DT support for clocks
From: Laurent Pinchart
Signed-off-by: Laurent Pinchart
---
drivers/media/platform/omap3isp/isp.c | 25 +
1 file changed, 25 insertions(+)
diff --git a/drivers/media/platform/omap3isp/isp.c
b/drivers/media/platform/omap3isp/isp.c
index a607f26..01356dd 100644
--- a/drivers/media/platform/omap3isp/isp.c
+++ b/drivers/media/platform/omap3isp/isp.c
@@ -279,9 +279,21 @@ static const struct clk_init_data isp_xclk_init_data = {
.num_parents = 1,
};
+static struct clk *isp_xclk_src_get(struct of_phandle_args *clkspec, void
*data)
+{
+ unsigned int idx = clkspec->args[0];
+ struct isp_device *isp = data;
+
+ if (idx >= ARRAY_SIZE(isp->xclks))
+ return ERR_PTR(-ENOENT);
+
+ return isp->xclks[idx].clk;
+}
+
static int isp_xclk_init(struct isp_device *isp)
{
struct isp_platform_data *pdata = isp->pdata;
+ struct device_node *np = isp->dev->of_node;
struct clk_init_data init;
unsigned int i;
@@ -312,6 +324,12 @@ static int isp_xclk_init(struct isp_device *isp)
if (IS_ERR(xclk->clk))
return PTR_ERR(xclk->clk);
+ /* When instantiated from DT we don't need to register clock
+* aliases.
+*/
+ if (np)
+ continue;
+
if (pdata->xclks[i].con_id == NULL &&
pdata->xclks[i].dev_id == NULL)
continue;
@@ -327,13 +345,20 @@ static int isp_xclk_init(struct isp_device *isp)
clkdev_add(xclk->lookup);
}
+ if (np)
+ of_clk_add_provider(np, isp_xclk_src_get, isp);
+
return 0;
}
static void isp_xclk_cleanup(struct isp_device *isp)
{
+ struct device_node *np = isp->dev->of_node;
unsigned int i;
+ if (np)
+ of_clk_del_provider(np);
+
for (i = 0; i < ARRAY_SIZE(isp->xclks); ++i) {
struct isp_xclk *xclk = &isp->xclks[i];
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC 03/18] omap3isp: Separate external link creation from platform data parsing
Move the code which connects the external entity to an ISP entity into a
separate function. This disconnects it from parsing the platform data.
Signed-off-by: Sakari Ailus
---
drivers/media/platform/omap3isp/isp.c | 147 +
1 file changed, 74 insertions(+), 73 deletions(-)
diff --git a/drivers/media/platform/omap3isp/isp.c
b/drivers/media/platform/omap3isp/isp.c
index 4ab674d..a607f26 100644
--- a/drivers/media/platform/omap3isp/isp.c
+++ b/drivers/media/platform/omap3isp/isp.c
@@ -1832,6 +1832,77 @@ isp_register_subdev_group(struct isp_device *isp,
return sensor;
}
+static int isp_link_entity(
+ struct isp_device *isp, struct media_entity *entity,
+ enum isp_interface_type interface)
+{
+ struct media_entity *input;
+ unsigned int flags;
+ unsigned int pad;
+ unsigned int i;
+
+ /* Connect the sensor to the correct interface module.
+* Parallel sensors are connected directly to the CCDC, while
+* serial sensors are connected to the CSI2a, CCP2b or CSI2c
+* receiver through CSIPHY1 or CSIPHY2.
+*/
+ switch (interface) {
+ case ISP_INTERFACE_PARALLEL:
+ input = &isp->isp_ccdc.subdev.entity;
+ pad = CCDC_PAD_SINK;
+ flags = 0;
+ break;
+
+ case ISP_INTERFACE_CSI2A_PHY2:
+ input = &isp->isp_csi2a.subdev.entity;
+ pad = CSI2_PAD_SINK;
+ flags = MEDIA_LNK_FL_IMMUTABLE | MEDIA_LNK_FL_ENABLED;
+ break;
+
+ case ISP_INTERFACE_CCP2B_PHY1:
+ case ISP_INTERFACE_CCP2B_PHY2:
+ input = &isp->isp_ccp2.subdev.entity;
+ pad = CCP2_PAD_SINK;
+ flags = 0;
+ break;
+
+ case ISP_INTERFACE_CSI2C_PHY1:
+ input = &isp->isp_csi2c.subdev.entity;
+ pad = CSI2_PAD_SINK;
+ flags = MEDIA_LNK_FL_IMMUTABLE | MEDIA_LNK_FL_ENABLED;
+ break;
+
+ default:
+ dev_err(isp->dev, "%s: invalid interface type %u\n", __func__,
+ interface);
+ return -EINVAL;
+ }
+
+ /*
+* Not all interfaces are available on all revisions of the
+* ISP. The sub-devices of those interfaces aren't initialised
+* in such a case. Check this by ensuring the num_pads is
+* non-zero.
+*/
+ if (!input->num_pads) {
+ dev_err(isp->dev, "%s: invalid input %u\n", entity->name,
+ interface);
+ return -EINVAL;
+ }
+
+ for (i = 0; i < entity->num_pads; i++) {
+ if (entity->pads[i].flags & MEDIA_PAD_FL_SOURCE)
+ break;
+ }
+ if (i == entity->num_pads) {
+ dev_err(isp->dev, "%s: no source pad in external entity\n",
+ __func__);
+ return -EINVAL;
+ }
+
+ return media_entity_create_link(entity, i, input, pad, flags);
+}
+
static int isp_register_entities(struct isp_device *isp)
{
struct isp_platform_data *pdata = isp->pdata;
@@ -1894,85 +1965,15 @@ static int isp_register_entities(struct isp_device *isp)
/* Register external entities */
for (subdevs = pdata->subdevs; subdevs && subdevs->subdevs; ++subdevs) {
- struct v4l2_subdev *sensor;
- struct media_entity *input;
- unsigned int flags;
- unsigned int pad;
- unsigned int i;
+ struct v4l2_subdev *sensor =
+ isp_register_subdev_group(isp, subdevs->subdevs);
- sensor = isp_register_subdev_group(isp, subdevs->subdevs);
if (sensor == NULL)
continue;
sensor->host_priv = subdevs;
- /* Connect the sensor to the correct interface module. Parallel
-* sensors are connected directly to the CCDC, while serial
-* sensors are connected to the CSI2a, CCP2b or CSI2c receiver
-* through CSIPHY1 or CSIPHY2.
-*/
- switch (subdevs->interface) {
- case ISP_INTERFACE_PARALLEL:
- input = &isp->isp_ccdc.subdev.entity;
- pad = CCDC_PAD_SINK;
- flags = 0;
- break;
-
- case ISP_INTERFACE_CSI2A_PHY2:
- input = &isp->isp_csi2a.subdev.entity;
- pad = CSI2_PAD_SINK;
- flags = MEDIA_LNK_FL_IMMUTABLE
- | MEDIA_LNK_FL_ENABLED;
- break;
-
- case ISP_INTERFACE_CCP2B_PHY1:
- case ISP_INTERFACE_CCP2B_PHY2:
- input = &isp->isp_ccp2.subdev.entity;
- pad = CCP2_PAD_SINK;
- flags = 0;
-
[RFC 05/18] omap3isp: Platform data could be NULL
Only check for call platform data callback functions if there's platform
data. Also take care of a few other cases where the NULL pdata pointer could
have been accessed, and remove the check for NULL dev->platform_data
pointer.
Removing the check for NULL dev->platform_data isn't strictly needed by the
DT support but there's no harm from that either: the device now can be used
without sensors, for instance.
Signed-off-by: Sakari Ailus
---
drivers/media/platform/omap3isp/isp.c | 10 --
drivers/media/platform/omap3isp/ispvideo.c |6 +++---
2 files changed, 7 insertions(+), 9 deletions(-)
diff --git a/drivers/media/platform/omap3isp/isp.c
b/drivers/media/platform/omap3isp/isp.c
index 01356dd..b836bc8 100644
--- a/drivers/media/platform/omap3isp/isp.c
+++ b/drivers/media/platform/omap3isp/isp.c
@@ -330,8 +330,8 @@ static int isp_xclk_init(struct isp_device *isp)
if (np)
continue;
- if (pdata->xclks[i].con_id == NULL &&
- pdata->xclks[i].dev_id == NULL)
+ if (!pdata || (pdata->xclks[i].con_id == NULL &&
+ pdata->xclks[i].dev_id == NULL))
continue;
xclk->lookup = kzalloc(sizeof(*xclk->lookup), GFP_KERNEL);
@@ -1989,7 +1989,8 @@ static int isp_register_entities(struct isp_device *isp)
goto done;
/* Register external entities */
- for (subdevs = pdata->subdevs; subdevs && subdevs->subdevs; ++subdevs) {
+ for (subdevs = pdata ? pdata->subdevs : NULL;
+subdevs && subdevs->subdevs; ++subdevs) {
struct v4l2_subdev *sensor =
isp_register_subdev_group(isp, subdevs->subdevs);
@@ -2271,9 +2272,6 @@ static int isp_probe(struct platform_device *pdev)
int ret;
int i, m;
- if (pdata == NULL)
- return -EINVAL;
-
isp = devm_kzalloc(&pdev->dev, sizeof(*isp), GFP_KERNEL);
if (!isp) {
dev_err(&pdev->dev, "could not allocate memory\n");
diff --git a/drivers/media/platform/omap3isp/ispvideo.c
b/drivers/media/platform/omap3isp/ispvideo.c
index 3fe9047..d644164 100644
--- a/drivers/media/platform/omap3isp/ispvideo.c
+++ b/drivers/media/platform/omap3isp/ispvideo.c
@@ -1022,7 +1022,7 @@ isp_video_streamon(struct file *file, void *fh, enum
v4l2_buf_type type)
pipe->entities = 0;
- if (video->isp->pdata->set_constraints)
+ if (video->isp->pdata && video->isp->pdata->set_constraints)
video->isp->pdata->set_constraints(video->isp, true);
pipe->l3_ick = clk_get_rate(video->isp->clock[ISP_CLK_L3_ICK]);
pipe->max_rate = pipe->l3_ick;
@@ -1104,7 +1104,7 @@ err_set_stream:
err_check_format:
media_entity_pipeline_stop(&video->video.entity);
err_pipeline_start:
- if (video->isp->pdata->set_constraints)
+ if (video->isp->pdata && video->isp->pdata->set_constraints)
video->isp->pdata->set_constraints(video->isp, false);
/* The DMA queue must be emptied here, otherwise CCDC interrupts that
* will get triggered the next time the CCDC is powered up will try to
@@ -1165,7 +1165,7 @@ isp_video_streamoff(struct file *file, void *fh, enum
v4l2_buf_type type)
video->queue = NULL;
video->error = false;
- if (video->isp->pdata->set_constraints)
+ if (video->isp->pdata && video->isp->pdata->set_constraints)
video->isp->pdata->set_constraints(video->isp, false);
media_entity_pipeline_stop(&video->video.entity);
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC 13/18] v4l: of: Read lane-polarity endpoint property
Add lane_polarity field to struct v4l2_of_bus_mipi_csi2 and write the
contents of the lane polarity property to it. The field tells the polarity
of the physical lanes starting from the first one. Any unused lanes are
ignored, i.e. only the polarity of the used lanes is specified.
Signed-off-by: Sakari Ailus
---
drivers/media/v4l2-core/v4l2-of.c | 21 -
include/media/v4l2-of.h |3 +++
2 files changed, 19 insertions(+), 5 deletions(-)
diff --git a/drivers/media/v4l2-core/v4l2-of.c
b/drivers/media/v4l2-core/v4l2-of.c
index b4ed9a9..a7a855e 100644
--- a/drivers/media/v4l2-core/v4l2-of.c
+++ b/drivers/media/v4l2-core/v4l2-of.c
@@ -23,7 +23,6 @@ static void v4l2_of_parse_csi_bus(const struct device_node
*node,
struct v4l2_of_endpoint *endpoint)
{
struct v4l2_of_bus_mipi_csi2 *bus = &endpoint->bus.mipi_csi2;
- u32 data_lanes[ARRAY_SIZE(bus->data_lanes)];
struct property *prop;
bool have_clk_lane = false;
unsigned int flags = 0;
@@ -34,14 +33,26 @@ static void v4l2_of_parse_csi_bus(const struct device_node
*node,
const __be32 *lane = NULL;
int i;
- for (i = 0; i < ARRAY_SIZE(data_lanes); i++) {
- lane = of_prop_next_u32(prop, lane, &data_lanes[i]);
+ for (i = 0; i < ARRAY_SIZE(bus->data_lanes); i++) {
+ lane = of_prop_next_u32(prop, lane, &v);
if (!lane)
break;
+ bus->data_lanes[i] = v;
}
bus->num_data_lanes = i;
- while (i--)
- bus->data_lanes[i] = data_lanes[i];
+ }
+
+ prop = of_find_property(node, "lane-polarity", NULL);
+ if (prop) {
+ const __be32 *polarity = NULL;
+ int i;
+
+ for (i = 0; i < ARRAY_SIZE(bus->lane_polarity); i++) {
+ polarity = of_prop_next_u32(prop, polarity, &v);
+ if (!polarity)
+ break;
+ bus->lane_polarity[i] = v;
+ }
}
if (!of_property_read_u32(node, "clock-lanes", &v)) {
diff --git a/include/media/v4l2-of.h b/include/media/v4l2-of.h
index 70fa7b7..a70eb52 100644
--- a/include/media/v4l2-of.h
+++ b/include/media/v4l2-of.h
@@ -29,12 +29,15 @@ struct device_node;
* @data_lanes: an array of physical data lane indexes
* @clock_lane: physical lane index of the clock lane
* @num_data_lanes: number of data lanes
+ * @lane_polarity: polarity of the lanes. The order is the same of
+ *the physical lanes.
*/
struct v4l2_of_bus_mipi_csi2 {
unsigned int flags;
unsigned char data_lanes[4];
unsigned char clock_lane;
unsigned short num_data_lanes;
+ bool lane_polarity[5];
};
/**
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC 18/18] omap3isp: Deprecate platform data support
Print a warning when the driver is used with platform data. Existing
platform data user should move to DT now.
Signed-off-by: Sakari Ailus
---
drivers/media/platform/omap3isp/isp.c |2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/media/platform/omap3isp/isp.c
b/drivers/media/platform/omap3isp/isp.c
index 2c9bc0d..e4a78bb 100644
--- a/drivers/media/platform/omap3isp/isp.c
+++ b/drivers/media/platform/omap3isp/isp.c
@@ -2447,6 +2447,8 @@ static int isp_probe(struct platform_device *pdev)
isp->syscon = syscon_regmap_lookup_by_pdevname("syscon.0");
if (IS_ERR(isp->syscon))
return PTR_ERR(isp->syscon);
+ dev_warn(&pdev->dev,
+"Platform data support is deprecated! Please move to
DT now!\n");
}
isp->autoidle = autoidle;
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC 15/18] omap3isp: Add support for the Device Tree
Add the ISP device to omap3 DT include file and add support to the driver to
use it.
Also obtain information on the external entities and the ISP configuration
related to them through the Device Tree in addition to the platform data.
Signed-off-by: Sakari Ailus
---
drivers/media/platform/omap3isp/isp.c | 206 +--
drivers/media/platform/omap3isp/isp.h | 11 ++
drivers/media/platform/omap3isp/ispcsiphy.c |7 +
3 files changed, 213 insertions(+), 11 deletions(-)
diff --git a/drivers/media/platform/omap3isp/isp.c
b/drivers/media/platform/omap3isp/isp.c
index 7804895..2c9bc0d 100644
--- a/drivers/media/platform/omap3isp/isp.c
+++ b/drivers/media/platform/omap3isp/isp.c
@@ -64,6 +64,7 @@
#include
#include
+#include
#include "isp.h"
#include "ispreg.h"
@@ -1991,6 +1992,14 @@ static int isp_register_entities(struct isp_device *isp)
if (ret < 0)
goto done;
+ /*
+* Device Tree --- the external of the sub-devices will be
+* registered later. Same goes for the sub-device node
+* registration.
+*/
+ if (isp->dev->of_node)
+ return 0;
+
/* Register external entities */
for (isp_subdev = pdata ? pdata->subdevs : NULL;
isp_subdev && isp_subdev->board_info; isp_subdev++) {
@@ -2016,8 +2025,10 @@ static int isp_register_entities(struct isp_device *isp)
ret = v4l2_device_register_subdev_nodes(&isp->v4l2_dev);
done:
- if (ret < 0)
+ if (ret < 0) {
isp_unregister_entities(isp);
+ v4l2_async_notifier_unregister(&isp->notifier);
+ }
return ret;
}
@@ -2232,6 +2243,7 @@ static int isp_remove(struct platform_device *pdev)
{
struct isp_device *isp = platform_get_drvdata(pdev);
+ v4l2_async_notifier_unregister(&isp->notifier);
isp_unregister_entities(isp);
isp_cleanup_modules(isp);
isp_xclk_cleanup(isp);
@@ -2243,6 +2255,151 @@ static int isp_remove(struct platform_device *pdev)
return 0;
}
+enum isp_of_phy {
+ ISP_OF_PHY_PARALLEL = 0,
+ ISP_OF_PHY_CSIPHY1,
+ ISP_OF_PHY_CSIPHY2,
+};
+
+static int isp_of_parse_node(struct device *dev, struct device_node *node,
+struct isp_async_subdev *isd)
+{
+ struct isp_bus_cfg *buscfg = &isd->bus;
+ struct v4l2_of_endpoint vep;
+ unsigned int i;
+
+ v4l2_of_parse_endpoint(node, &vep);
+
+ dev_dbg(dev, "interface %u\n", vep.base.port);
+
+ switch (vep.base.port) {
+ case ISP_OF_PHY_PARALLEL:
+ buscfg->interface = ISP_INTERFACE_PARALLEL;
+ buscfg->bus.parallel.data_lane_shift =
+ vep.bus.parallel.data_shift;
+ buscfg->bus.parallel.clk_pol =
+ !!(vep.bus.parallel.flags
+ & V4L2_MBUS_PCLK_SAMPLE_FALLING);
+ buscfg->bus.parallel.hs_pol =
+ !!(vep.bus.parallel.flags & V4L2_MBUS_VSYNC_ACTIVE_LOW);
+ buscfg->bus.parallel.vs_pol =
+ !!(vep.bus.parallel.flags & V4L2_MBUS_HSYNC_ACTIVE_LOW);
+ buscfg->bus.parallel.fld_pol =
+ !!(vep.bus.parallel.flags & V4L2_MBUS_FIELD_EVEN_LOW);
+ buscfg->bus.parallel.data_pol =
+ !!(vep.bus.parallel.flags & V4L2_MBUS_DATA_ACTIVE_LOW);
+ break;
+
+ case ISP_OF_PHY_CSIPHY1:
+ case ISP_OF_PHY_CSIPHY2:
+ /* FIXME: always assume CSI-2 for now. */
+ switch (vep.base.port) {
+ case ISP_OF_PHY_CSIPHY1:
+ buscfg->interface = ISP_INTERFACE_CSI2C_PHY1;
+ break;
+ case ISP_OF_PHY_CSIPHY2:
+ buscfg->interface = ISP_INTERFACE_CSI2A_PHY2;
+ break;
+ }
+ buscfg->bus.csi2.lanecfg.clk.pos = vep.bus.mipi_csi2.clock_lane;
+ buscfg->bus.csi2.lanecfg.clk.pol =
+ vep.bus.mipi_csi2.lane_polarity[0];
+ dev_dbg(dev, "clock lane polarity %u, pos %u\n",
+ buscfg->bus.csi2.lanecfg.clk.pol,
+ buscfg->bus.csi2.lanecfg.clk.pos);
+
+ for (i = 0; i < ISP_CSIPHY2_NUM_DATA_LANES; i++) {
+ buscfg->bus.csi2.lanecfg.data[i].pos =
+ vep.bus.mipi_csi2.data_lanes[i];
+ buscfg->bus.csi2.lanecfg.data[i].pol =
+ vep.bus.mipi_csi2.lane_polarity[i + 1];
+ dev_dbg(dev, "data lane %u polarity %u, pos %u\n", i,
+ buscfg->bus.csi2.lanecfg.data[i].pol,
+ buscfg->bus.csi2.lanecfg.data[i].pos);
+ }
+
+ /*
+* FIXME: now we assume the CRC is always there.
+* Imp
[RFC 17/18] arm: dts: n950, n9: Add primary camera support
Add support for the primary camera of the Nokia N950 and N9.
Signed-off-by: Sakari Ailus
---
arch/arm/boot/dts/omap3-n9.dts | 39 ++
arch/arm/boot/dts/omap3-n950-n9.dtsi |4
arch/arm/boot/dts/omap3-n950.dts | 39 ++
3 files changed, 78 insertions(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/omap3-n9.dts b/arch/arm/boot/dts/omap3-n9.dts
index 9938b5d..05f32ae 100644
--- a/arch/arm/boot/dts/omap3-n9.dts
+++ b/arch/arm/boot/dts/omap3-n9.dts
@@ -16,3 +16,42 @@
model = "Nokia N9";
compatible = "nokia,omap3-n9", "ti,omap36xx", "ti,omap3";
};
+
+&i2c2 {
+ clock-frequency = <40>;
+
+ smia_1: camera@10 {
+ compatible = "nokia,smia";
+ reg = <0x10>;
+ /* No reset gpio */
+ vana-supply = <&vaux3>;
+ clocks = <&omap3_isp 0>;
+ clock-frequency = <960>;
+ nokia,nvm-size = <1024>; /* 16 * 64 */
+ link-frequencies = /bits/ 64 <19920 21000 49920>;
+ port {
+ smia_1_1: endpoint {
+ clock-lanes = <0>;
+ data-lanes = <1 2>;
+ remote-endpoint = <&csi2a_ep>;
+ };
+ };
+ };
+};
+
+&omap3_isp {
+ vdd-csiphy1-supply = <&vaux2>;
+ vdd-csiphy2-supply = <&vaux2>;
+ ports {
+ port@2 {
+ reg = <2>;
+ csi2a_ep: endpoint {
+ remote-endpoint = <&smia_1_1>;
+ clock-lanes = <2>;
+ data-lanes = <1 3>;
+ crc = <1>;
+ lane-polarity = <1 1 1>;
+ };
+ };
+ };
+};
diff --git a/arch/arm/boot/dts/omap3-n950-n9.dtsi
b/arch/arm/boot/dts/omap3-n950-n9.dtsi
index c41db94..51e5043 100644
--- a/arch/arm/boot/dts/omap3-n950-n9.dtsi
+++ b/arch/arm/boot/dts/omap3-n950-n9.dtsi
@@ -86,10 +86,6 @@
regulator-max-microvolt = <280>;
};
-&i2c2 {
- clock-frequency = <40>;
-};
-
&i2c3 {
clock-frequency = <40>;
};
diff --git a/arch/arm/boot/dts/omap3-n950.dts b/arch/arm/boot/dts/omap3-n950.dts
index 261c558..2b2ed9c 100644
--- a/arch/arm/boot/dts/omap3-n950.dts
+++ b/arch/arm/boot/dts/omap3-n950.dts
@@ -16,3 +16,42 @@
model = "Nokia N950";
compatible = "nokia,omap3-n950", "ti,omap36xx", "ti,omap3";
};
+
+&i2c2 {
+ clock-frequency = <40>;
+
+ smia_1: camera@10 {
+ compatible = "nokia,smia";
+ reg = <0x10>;
+ /* No reset gpio */
+ vana-supply = <&vaux3>;
+ clocks = <&omap3_isp 0>;
+ clock-frequency = <960>;
+ nokia,nvm-size = <1024>; /* 16 * 64 */
+ link-frequencies = /bits/ 64 <21000 33360 39840>;
+ port {
+ smia_1_1: endpoint {
+ clock-lanes = <0>;
+ data-lanes = <1 2>;
+ remote-endpoint = <&csi2a_ep>;
+ };
+ };
+ };
+};
+
+&omap3_isp {
+ vdd-csiphy1-supply = <&vaux2>;
+ vdd-csiphy2-supply = <&vaux2>;
+ ports {
+ port@2 {
+ reg = <2>;
+ csi2a_ep: endpoint {
+ remote-endpoint = <&smia_1_1>;
+ clock-lanes = <2>;
+ data-lanes = <3 1>;
+ crc = <1>;
+ lane-polarity = <1 1 1>;
+ };
+ };
+ };
+};
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC 02/18] omap3isp: Avoid a BUG_ON() in media_entity_create_link()
If an uninitialised v4l2_subdev struct was passed to
media_entity_create_link(), one of the BUG_ON()'s in the function will be
hit since media_entity.num_pads will be zero. Avoid this by checking whether
the num_pads field is non-zero for the interface.
Signed-off-by: Sakari Ailus
---
drivers/media/platform/omap3isp/isp.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/drivers/media/platform/omap3isp/isp.c
b/drivers/media/platform/omap3isp/isp.c
index fb193b6..4ab674d 100644
--- a/drivers/media/platform/omap3isp/isp.c
+++ b/drivers/media/platform/omap3isp/isp.c
@@ -1946,6 +1946,19 @@ static int isp_register_entities(struct isp_device *isp)
goto done;
}
+ /*
+* Not all interfaces are available on all revisions
+* of the ISP. The sub-devices of those interfaces
+* aren't initialised in such a case. Check this by
+* ensuring the num_pads is non-zero.
+*/
+ if (!input->num_pads) {
+ dev_err(isp->dev, "%s: invalid input %u\n",
+ entity->name, subdevs->interface);
+ ret = -EINVAL;
+ goto done;
+ }
+
for (i = 0; i < sensor->entity.num_pads; i++) {
if (sensor->entity.pads[i].flags & MEDIA_PAD_FL_SOURCE)
break;
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC 11/18] omap3isp: Replace many MMIO regions by two
The omap3isp MMIO register block is contiguous in the MMIO register space
apart from the fact that the ISP IOMMU register block is in the middle of
the area. Ioremap it at two occasions, and keep the rest of the layout of
the register space internal to the omap3isp driver.
Signed-off-by: Sakari Ailus
---
arch/arm/mach-omap2/devices.c | 66 +--
arch/arm/mach-omap2/omap34xx.h| 36 +--
drivers/media/platform/omap3isp/isp.c | 113 +
drivers/media/platform/omap3isp/isp.h |4 +-
4 files changed, 66 insertions(+), 153 deletions(-)
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index e945957..990338f 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -74,72 +74,12 @@ omap_postcore_initcall(omap3_l3_init);
static struct resource omap3isp_resources[] = {
{
.start = OMAP3430_ISP_BASE,
- .end= OMAP3430_ISP_END,
+ .end= OMAP3430_ISP_BASE + 0x12fc,
.flags = IORESOURCE_MEM,
},
{
- .start = OMAP3430_ISP_CCP2_BASE,
- .end= OMAP3430_ISP_CCP2_END,
- .flags = IORESOURCE_MEM,
- },
- {
- .start = OMAP3430_ISP_CCDC_BASE,
- .end= OMAP3430_ISP_CCDC_END,
- .flags = IORESOURCE_MEM,
- },
- {
- .start = OMAP3430_ISP_HIST_BASE,
- .end= OMAP3430_ISP_HIST_END,
- .flags = IORESOURCE_MEM,
- },
- {
- .start = OMAP3430_ISP_H3A_BASE,
- .end= OMAP3430_ISP_H3A_END,
- .flags = IORESOURCE_MEM,
- },
- {
- .start = OMAP3430_ISP_PREV_BASE,
- .end= OMAP3430_ISP_PREV_END,
- .flags = IORESOURCE_MEM,
- },
- {
- .start = OMAP3430_ISP_RESZ_BASE,
- .end= OMAP3430_ISP_RESZ_END,
- .flags = IORESOURCE_MEM,
- },
- {
- .start = OMAP3430_ISP_SBL_BASE,
- .end= OMAP3430_ISP_SBL_END,
- .flags = IORESOURCE_MEM,
- },
- {
- .start = OMAP3430_ISP_CSI2A_REGS1_BASE,
- .end= OMAP3430_ISP_CSI2A_REGS1_END,
- .flags = IORESOURCE_MEM,
- },
- {
- .start = OMAP3430_ISP_CSIPHY2_BASE,
- .end= OMAP3430_ISP_CSIPHY2_END,
- .flags = IORESOURCE_MEM,
- },
- {
- .start = OMAP3630_ISP_CSI2A_REGS2_BASE,
- .end= OMAP3630_ISP_CSI2A_REGS2_END,
- .flags = IORESOURCE_MEM,
- },
- {
- .start = OMAP3630_ISP_CSI2C_REGS1_BASE,
- .end= OMAP3630_ISP_CSI2C_REGS1_END,
- .flags = IORESOURCE_MEM,
- },
- {
- .start = OMAP3630_ISP_CSIPHY1_BASE,
- .end= OMAP3630_ISP_CSIPHY1_END,
- .flags = IORESOURCE_MEM,
- },
- {
- .start = OMAP3630_ISP_CSI2C_REGS2_BASE,
- .end= OMAP3630_ISP_CSI2C_REGS2_END,
+ .start = OMAP3430_ISP_BASE2,
+ .end= OMAP3430_ISP_BASE2 + 0x0600,
.flags = IORESOURCE_MEM,
},
{
diff --git a/arch/arm/mach-omap2/omap34xx.h b/arch/arm/mach-omap2/omap34xx.h
index c0d1b4b..ed0024d 100644
--- a/arch/arm/mach-omap2/omap34xx.h
+++ b/arch/arm/mach-omap2/omap34xx.h
@@ -46,39 +46,9 @@
#define OMAP34XX_IC_BASE 0x4820
-#define OMAP3430_ISP_BASE (L4_34XX_BASE + 0xBC000)
-#define OMAP3430_ISP_CBUFF_BASE(OMAP3430_ISP_BASE + 0x0100)
-#define OMAP3430_ISP_CCP2_BASE (OMAP3430_ISP_BASE + 0x0400)
-#define OMAP3430_ISP_CCDC_BASE (OMAP3430_ISP_BASE + 0x0600)
-#define OMAP3430_ISP_HIST_BASE (OMAP3430_ISP_BASE + 0x0A00)
-#define OMAP3430_ISP_H3A_BASE (OMAP3430_ISP_BASE + 0x0C00)
-#define OMAP3430_ISP_PREV_BASE (OMAP3430_ISP_BASE + 0x0E00)
-#define OMAP3430_ISP_RESZ_BASE (OMAP3430_ISP_BASE + 0x1000)
-#define OMAP3430_ISP_SBL_BASE (OMAP3430_ISP_BASE + 0x1200)
-#define OMAP3430_ISP_MMU_BASE (OMAP3430_ISP_BASE + 0x1400)
-#define OMAP3430_ISP_CSI2A_REGS1_BASE (OMAP3430_ISP_BASE + 0x1800)
-#define OMAP3430_ISP_CSIPHY2_BASE (OMAP3430_ISP_BASE + 0x1970)
-#define OMAP3630_ISP_CSI2A_REGS2_BASE (OMAP3430_ISP_BASE + 0x19C0)
-#define OMAP3630_ISP_CSI2C_REGS1_BASE (OMAP3430_ISP_BASE + 0x1C00)
-#define OMAP3630_ISP_CSIPHY1_BASE
[RFC 07/18] omap3isp: Rename regulators to better suit the Device Tree
Rename VDD_CSIPHY1 as vdd-csiphy1 and VDD_CSIPHY2 as vdd-csiphy2. Signed-off-by: Sakari Ailus --- drivers/media/platform/omap3isp/isp.c |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/media/platform/omap3isp/isp.c b/drivers/media/platform/omap3isp/isp.c index 1b5c6df..c045318 100644 --- a/drivers/media/platform/omap3isp/isp.c +++ b/drivers/media/platform/omap3isp/isp.c @@ -2292,8 +2292,8 @@ static int isp_probe(struct platform_device *pdev) platform_set_drvdata(pdev, isp); /* Regulators */ - isp->isp_csiphy1.vdd = devm_regulator_get(&pdev->dev, "VDD_CSIPHY1"); - isp->isp_csiphy2.vdd = devm_regulator_get(&pdev->dev, "VDD_CSIPHY2"); + isp->isp_csiphy1.vdd = devm_regulator_get(&pdev->dev, "vdd-csiphy1"); + isp->isp_csiphy2.vdd = devm_regulator_get(&pdev->dev, "vdd-csiphy2"); /* Clocks * -- 1.7.10.4 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC 06/18] omap3isp: Refactor device configuration structs for Device Tree
Make omap3isp configuration data structures more suitable for consumption by
the DT by separating the I2C bus information of all the sub-devices in a
group and the ISP bus information from each other. The ISP bus information
is made a pointer instead of being directly embedded in the struct.
In the case of the DT only the sensor specific information on the ISP bus
configuration is retained. The structs are renamed to reflect that.
After this change the structs needed to describe device configuration can be
allocated and accessed separately without those needed only in the case of
platform data. The platform data related structs can be later removed once
the support for platform data can be removed.
Signed-off-by: Sakari Ailus
Cc: Mike Rapoport
Cc: Igor Grinberg
---
arch/arm/mach-omap2/board-cm-t35.c | 57 +++---
drivers/media/platform/omap3isp/isp.c | 86 +--
drivers/media/platform/omap3isp/isp.h |2 +-
drivers/media/platform/omap3isp/ispccdc.c | 26
drivers/media/platform/omap3isp/ispccp2.c | 22 +++
drivers/media/platform/omap3isp/ispcsi2.c |8 +--
drivers/media/platform/omap3isp/ispcsiphy.c | 21 ---
include/media/omap3isp.h| 34 +--
8 files changed, 119 insertions(+), 137 deletions(-)
diff --git a/arch/arm/mach-omap2/board-cm-t35.c
b/arch/arm/mach-omap2/board-cm-t35.c
index 91738a1..b5dfbc1 100644
--- a/arch/arm/mach-omap2/board-cm-t35.c
+++ b/arch/arm/mach-omap2/board-cm-t35.c
@@ -492,51 +492,36 @@ static struct twl4030_platform_data cm_t35_twldata = {
#include
#include "devices.h"
-static struct i2c_board_info cm_t35_isp_i2c_boardinfo[] = {
+static struct isp_platform_subdev cm_t35_isp_subdevs[] = {
{
- I2C_BOARD_INFO("mt9t001", 0x5d),
- },
- {
- I2C_BOARD_INFO("tvp5150", 0x5c),
- },
-};
-
-static struct isp_subdev_i2c_board_info cm_t35_isp_primary_subdevs[] = {
- {
- .board_info = &cm_t35_isp_i2c_boardinfo[0],
- .i2c_adapter_id = 3,
- },
- { NULL, 0, },
-};
-
-static struct isp_subdev_i2c_board_info cm_t35_isp_secondary_subdevs[] = {
- {
- .board_info = &cm_t35_isp_i2c_boardinfo[1],
+ .board_info = &(struct i2c_board_info){
+ I2C_BOARD_INFO("mt9t001", 0x5d)
+ },
.i2c_adapter_id = 3,
- },
- { NULL, 0, },
-};
-
-static struct isp_v4l2_subdevs_group cm_t35_isp_subdevs[] = {
- {
- .subdevs = cm_t35_isp_primary_subdevs,
- .interface = ISP_INTERFACE_PARALLEL,
- .bus = {
- .parallel = {
- .clk_pol = 1,
+ .bus = &(struct isp_bus_cfg){
+ .interface = ISP_INTERFACE_PARALLEL,
+ .bus = {
+ .parallel = {
+ .clk_pol = 1,
+ },
},
},
},
{
- .subdevs = cm_t35_isp_secondary_subdevs,
- .interface = ISP_INTERFACE_PARALLEL,
- .bus = {
- .parallel = {
- .clk_pol = 0,
+ .board_info = &(struct i2c_board_info){
+ I2C_BOARD_INFO("tvp5150", 0x5c),
+ },
+ .i2c_adapter_id = 3,
+ .bus = &(struct isp_bus_cfg){
+ .interface = ISP_INTERFACE_PARALLEL,
+ .bus = {
+ .parallel = {
+ .clk_pol = 0,
+ },
},
},
},
- { NULL, 0, },
+ { 0 },
};
static struct isp_platform_data cm_t35_isp_pdata = {
diff --git a/drivers/media/platform/omap3isp/isp.c
b/drivers/media/platform/omap3isp/isp.c
index b836bc8..1b5c6df 100644
--- a/drivers/media/platform/omap3isp/isp.c
+++ b/drivers/media/platform/omap3isp/isp.c
@@ -447,7 +447,7 @@ static void isp_core_init(struct isp_device *isp, int idle)
*/
void omap3isp_configure_bridge(struct isp_device *isp,
enum ccdc_input_entity input,
- const struct isp_parallel_platform_data *pdata,
+ const struct isp_parallel_cfg *parcfg,
unsigned int shift, unsigned int bridge)
{
u32 ispctrl_val;
@@ -462,8 +462,8 @@ void omap3isp_configure_bridge(struct isp_device *isp,
switch (input) {
case CCDC_INPUT_PARALLEL:
ispctrl_val |= ISPCTRL_PAR_SER_CLK_SEL_PARALLEL;
- ispctrl_val |= pdata->clk_pol << ISPCTRL_PAR_CLK_POL_SHIFT;
- shift += pdata->data_lane_shift * 2;
+ ispctrl_val |= parcfg->clk_pol << ISPCTRL_PAR_CLK_P
[RFC 10/18] omap3isp: Move the syscon register out of the ISP register maps
The syscon register isn't part of the ISP, use it through the syscom driver
regmap instead. The syscom block is considered to be from 343x on ISP
revision 2.0 whereas 15.0 is assumed to have 3630 syscon.
Signed-off-by: Sakari Ailus
---
arch/arm/boot/dts/omap3.dtsi|2 +-
arch/arm/mach-omap2/devices.c | 10 --
drivers/media/platform/omap3isp/isp.c | 19 +++
drivers/media/platform/omap3isp/isp.h | 19 +--
drivers/media/platform/omap3isp/ispcsiphy.c | 20 +---
5 files changed, 42 insertions(+), 28 deletions(-)
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index 01b7111..fe0b293 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -183,7 +183,7 @@
omap3_scm_general: tisyscon@48002270 {
compatible = "syscon";
- reg = <0x48002270 0x2f0>;
+ reg = <0x48002270 0x2f4>;
};
pbias_regulator: pbias_regulator {
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index 1afb50d..e945957 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -143,16 +143,6 @@ static struct resource omap3isp_resources[] = {
.flags = IORESOURCE_MEM,
},
{
- .start = OMAP343X_CTRL_BASE + OMAP343X_CONTROL_CSIRXFE,
- .end= OMAP343X_CTRL_BASE + OMAP343X_CONTROL_CSIRXFE
+ 3,
- .flags = IORESOURCE_MEM,
- },
- {
- .start = OMAP343X_CTRL_BASE +
OMAP3630_CONTROL_CAMERA_PHY_CTRL,
- .end= OMAP343X_CTRL_BASE +
OMAP3630_CONTROL_CAMERA_PHY_CTRL + 3,
- .flags = IORESOURCE_MEM,
- },
- {
.start = 24 + OMAP_INTC_START,
.flags = IORESOURCE_IRQ,
}
diff --git a/drivers/media/platform/omap3isp/isp.c
b/drivers/media/platform/omap3isp/isp.c
index 68d7edfc..4ff4bbd 100644
--- a/drivers/media/platform/omap3isp/isp.c
+++ b/drivers/media/platform/omap3isp/isp.c
@@ -51,6 +51,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -94,8 +95,9 @@ static const struct isp_res_mapping isp_res_maps[] = {
1 << OMAP3_ISP_IOMEM_RESZ |
1 << OMAP3_ISP_IOMEM_SBL |
1 << OMAP3_ISP_IOMEM_CSI2A_REGS1 |
- 1 << OMAP3_ISP_IOMEM_CSIPHY2 |
- 1 << OMAP3_ISP_IOMEM_343X_CONTROL_CSIRXFE,
+ 1 << OMAP3_ISP_IOMEM_CSIPHY2,
+ .syscon_offset = 0xdc,
+ .phy_type = ISP_PHY_TYPE_3430,
},
{
.isp_rev = ISP_REVISION_15_0,
@@ -112,8 +114,9 @@ static const struct isp_res_mapping isp_res_maps[] = {
1 << OMAP3_ISP_IOMEM_CSI2A_REGS2 |
1 << OMAP3_ISP_IOMEM_CSI2C_REGS1 |
1 << OMAP3_ISP_IOMEM_CSIPHY1 |
- 1 << OMAP3_ISP_IOMEM_CSI2C_REGS2 |
- 1 << OMAP3_ISP_IOMEM_3630_CONTROL_CAMERA_PHY_CTRL,
+ 1 << OMAP3_ISP_IOMEM_CSI2C_REGS2,
+ .syscon_offset = 0x2f0,
+ .phy_type = ISP_PHY_TYPE_3630,
},
};
@@ -2352,6 +2355,14 @@ static int isp_probe(struct platform_device *pdev)
}
}
+ isp->syscon = syscon_regmap_lookup_by_pdevname("syscon.0");
+ isp->syscon_offset = isp_res_maps[m].syscon_offset;
+ isp->phy_type = isp_res_maps[m].phy_type;
+ if (IS_ERR(isp->syscon)) {
+ ret = PTR_ERR(isp->syscon);
+ goto error_isp;
+ }
+
/* IOMMU */
ret = isp_attach_iommu(isp);
if (ret < 0) {
diff --git a/drivers/media/platform/omap3isp/isp.h
b/drivers/media/platform/omap3isp/isp.h
index 9535524..03d2129 100644
--- a/drivers/media/platform/omap3isp/isp.h
+++ b/drivers/media/platform/omap3isp/isp.h
@@ -59,8 +59,6 @@ enum isp_mem_resources {
OMAP3_ISP_IOMEM_CSI2C_REGS1,
OMAP3_ISP_IOMEM_CSIPHY1,
OMAP3_ISP_IOMEM_CSI2C_REGS2,
- OMAP3_ISP_IOMEM_343X_CONTROL_CSIRXFE,
- OMAP3_ISP_IOMEM_3630_CONTROL_CAMERA_PHY_CTRL,
OMAP3_ISP_IOMEM_LAST
};
@@ -93,14 +91,25 @@ enum isp_subclk_resource {
/* ISP2P: OMAP 36xx */
#define ISP_REVISION_15_0 0xF0
+#define ISP_PHY_TYPE_3430 0
+#define ISP_PHY_TYPE_3630 1
+
+struct regmap;
+
/*
* struct isp_res_mapping - Map ISP io resources to ISP revision.
* @isp_rev: ISP_REVISION_x_x
* @map: bitmap for enum isp_mem_resources
+ * @syscon_offset: offset of the syscon register for 343x / 3630
+ * (CONTROL_CSIRXFE / CONTROL_CAMERA_PHY_CTRL, respectively)
+ * from the syscon base address
+ * @phy_type: ISP_PHY_TYPE_{3430,3630}
*/
struc
[RFC 14/18] dt: bindings: Add bindings for omap3isp
Signed-off-by: Sakari Ailus
---
.../devicetree/bindings/media/ti,omap3isp.txt | 64
MAINTAINERS|1 +
2 files changed, 65 insertions(+)
create mode 100644 Documentation/devicetree/bindings/media/ti,omap3isp.txt
diff --git a/Documentation/devicetree/bindings/media/ti,omap3isp.txt
b/Documentation/devicetree/bindings/media/ti,omap3isp.txt
new file mode 100644
index 000..2059524
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/ti,omap3isp.txt
@@ -0,0 +1,64 @@
+OMAP 3 ISP Device Tree bindings
+===
+
+More documentation on these bindings is available in
+video-interfaces.txt in the same directory.
+
+Required properties
+===
+
+compatible : "ti,omap3-isp"
+reg: a set of two register block physical addresses and
+ lengths
+interrupts : the interrupt number
+iommus : phandle of the IOMMU
+syscon : syscon phandle and register offset
+ti,phy-type: 0 -- 3430; 1 -- 3630
+#clock-cells : Must be 1 --- the ISP provides two external clocks,
+ cam_xclka and cam_xclkb, at indices 0 and 1,
+ respectively. Please find more information on common
+ clock bindings in ../clock/clock-bindings.txt.
+
+Port nodes (optional)
+-
+
+reg: The interface:
+ 0 - parallel (CCDC)
+ 1 - CSIPHY1 -- CSI2C / CCP2B on 3630;
+ CSI1 -- CSIb on 3430
+ 2 - CSIPHY2 -- CSI2A / CCP2B on 3630;
+ CSI2 -- CSIa on 3430
+
+Optional properties
+===
+
+vdd-csiphy1-supply : voltage supply of the CSI-2 PHY 1
+vdd-csiphy2-supply : voltage supply of the CSI-2 PHY 2
+
+Endpoint nodes
+--
+
+lane-polarity : lane polarity (required on CSI-2)
+ 0 -- not inverted; 1 -- inverted
+data-lanes : an array of data lanes from 1 to 3. The length can
+ be either 1 or 2. (required CSI-2)
+clock-lanes: the clock lane (from 1 to 3). (required on CSI-2)
+
+
+Example
+===
+
+ omap3_isp: omap3_isp@480bc000 {
+ compatible = "ti,omap3-isp";
+ reg = <0x480bc000 0x12fc
+ 0x480bd800 0x0600>;
+ interrupts = <24>;
+ iommus = <&mmu_isp>;
+ syscon = <&omap3_scm_general 0x2f0>;
+ ti,phy-type = <1>;
+ #clock-cells = <1>;
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+ };
diff --git a/MAINTAINERS b/MAINTAINERS
index ddc5a8c..cdeef39 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -7079,6 +7079,7 @@ L:linux-me...@vger.kernel.org
S: Maintained
F: drivers/media/platform/omap3isp/
F: drivers/staging/media/omap4iss/
+F: Documentation/devicetree/bindings/media/ti,omap3isp.txt
OMAP USB SUPPORT
M: Felipe Balbi
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC 01/18] omap3isp: Fix error handling in probe
The mutex was not destroyed correctly if dma_coerce_mask_and_coherent() failed for some reason. Signed-off-by: Sakari Ailus --- drivers/media/platform/omap3isp/isp.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/media/platform/omap3isp/isp.c b/drivers/media/platform/omap3isp/isp.c index deca809..fb193b6 100644 --- a/drivers/media/platform/omap3isp/isp.c +++ b/drivers/media/platform/omap3isp/isp.c @@ -2252,7 +2252,7 @@ static int isp_probe(struct platform_device *pdev) ret = dma_coerce_mask_and_coherent(isp->dev, DMA_BIT_MASK(32)); if (ret) - return ret; + goto error; platform_set_drvdata(pdev, isp); -- 1.7.10.4 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC 00/18] Device tree support for omap3isp, N9[50] primary camera
Hi folks, I've had this patchset hanging around for a long, long time, and now it's time to send it out to linux-media. For OMAP 3, first there are a few patches for random and tiny bugfixes and then preparation for DT support (including compile tested rework of cm-t35 board code). The lane-polarity DT binding is added to video-interfaces.txt for this, I believe, is hardly specific to the OMAP 3 ISP. The same property is read by the V4L2 OF parser as well. ISP DT support is added for both OMAP 34xx and 36xx, but it remains tested on 3630 only. The primary camera support is added for both N950 and N9, the latter of which is tested. The differences are quite small between the two in both of the cases, but still testing definitely wouldn't hurt. The secondary camera support is still lacking primarily due to the I2C address conflict: both of the cameras have the same I2C address. It'd also require CCP2 bus support, which is relatively trivial to add. Effects of Philipp Zabel's patch "of: Decrement refcount of previous endpoint in of_graph_get_next_endpoint" aren't yet taken into account in this series. I'll address this in the next set if changes (small I presume) are needed. -- Kind regards, Sakari -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC 09/18] omap3isp: Replace mmio_base_phys array with the histogram block base
Only the histogram sub-block driver uses the physical address. Do not store
it for other sub-blocks.
Signed-off-by: Sakari Ailus
---
drivers/media/platform/omap3isp/isp.c |3 ++-
drivers/media/platform/omap3isp/isp.h |6 +++---
drivers/media/platform/omap3isp/isphist.c |2 +-
3 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/media/platform/omap3isp/isp.c
b/drivers/media/platform/omap3isp/isp.c
index c045318..68d7edfc 100644
--- a/drivers/media/platform/omap3isp/isp.c
+++ b/drivers/media/platform/omap3isp/isp.c
@@ -2247,7 +2247,8 @@ static int isp_map_mem_resource(struct platform_device
*pdev,
if (IS_ERR(isp->mmio_base[res]))
return PTR_ERR(isp->mmio_base[res]);
- isp->mmio_base_phys[res] = mem->start;
+ if (res == OMAP3_ISP_IOMEM_HIST)
+ isp->mmio_hist_base_phys = mem->start;
return 0;
}
diff --git a/drivers/media/platform/omap3isp/isp.h
b/drivers/media/platform/omap3isp/isp.h
index b932a6f..9535524 100644
--- a/drivers/media/platform/omap3isp/isp.h
+++ b/drivers/media/platform/omap3isp/isp.h
@@ -138,8 +138,8 @@ struct isp_xclk {
* @irq_num: Currently used IRQ number.
* @mmio_base: Array with kernel base addresses for ioremapped ISP register
* regions.
- * @mmio_base_phys: Array with physical L4 bus addresses for ISP register
- * regions.
+ * @mmio_hist_base_phys: Physical L4 bus address for ISP hist block register
+ * region.
* @mapping: IOMMU mapping
* @stat_lock: Spinlock for handling statistics
* @isp_mutex: Mutex for serializing requests to ISP.
@@ -175,7 +175,7 @@ struct isp_device {
unsigned int irq_num;
void __iomem *mmio_base[OMAP3_ISP_IOMEM_LAST];
- unsigned long mmio_base_phys[OMAP3_ISP_IOMEM_LAST];
+ unsigned long mmio_hist_base_phys;
struct dma_iommu_mapping *mapping;
diff --git a/drivers/media/platform/omap3isp/isphist.c
b/drivers/media/platform/omap3isp/isphist.c
index ce822c3..3bb9c4f 100644
--- a/drivers/media/platform/omap3isp/isphist.c
+++ b/drivers/media/platform/omap3isp/isphist.c
@@ -70,7 +70,7 @@ static void hist_dma_config(struct ispstat *hist)
hist->dma_config.sync_mode = OMAP_DMA_SYNC_ELEMENT;
hist->dma_config.frame_count = 1;
hist->dma_config.src_amode = OMAP_DMA_AMODE_CONSTANT;
- hist->dma_config.src_start = isp->mmio_base_phys[OMAP3_ISP_IOMEM_HIST]
+ hist->dma_config.src_start = isp->mmio_hist_base_phys
+ ISPHIST_DATA;
hist->dma_config.dst_amode = OMAP_DMA_AMODE_POST_INC;
hist->dma_config.src_or_dst_synch = OMAP_DMA_SRC_SYNC;
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] Input: add support for Semtech SX8654 I2C touchscreen controller
On Sat, Mar 07, 2015 at 01:32:25PM +0100, Paul Bolle wrote:
> Dmitry Torokhov schreef op vr 06-03-2015 om 16:57 [-0800]:
> > Applied with some cosmetic edits and DT bindings folded into this patch.
>
> Was one of these cosmetic edits perhaps an edit to use
> MODULE_LICENSE("GPL v2");
>
> in sx8654.c?
No it wasn't.
> That would make that macro match the license stated in the
> comment at the top of that file.
I am not sure if anyone cares about exact version of GPL in module
information (2 only vs 2+) since it only used to figure out if the
module taints kernel or not. In fact there are more modules that are v2
only that claim GPL than the ones claiming GPL v2.
dtor@dtor-ws:~/kernel/master$ for file in `grep -r -l 'MODULE_LICENSE("GPL")'`;
do grep -H '2 as published' $file; done | wc -l
259
dtor@dtor-ws:~/kernel/master$ for file in `grep -r -l 'MODULE_LICENSE("GPL
v2")'`; do grep -H '2 as published' $file; do ne | wc -l
150
Also:
dtor@dtor-ws:~/kernel/master$ for file in `grep -r -l 'MODULE_LICENSE("GPL
v2")'`; do grep -H '2 or ' $file; done | wc -l
68
dtor@dtor-ws:~/kernel/master$ for file in `grep -r -l 'MODULE_LICENSE("GPL")'`;
do grep -H '2 or ' $file; done | wc -l
237
Thanks.
--
Dmitry
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 4/5] Input: add haptic drvier on max77843
Hi, On Wed, Mar 04, 2015 at 02:47:42PM -0800, Dmitry Torokhov wrote: > [...] > > >Do you want it to go through my or MFD tree? > > Other drivers merged in each maintainers git. Actually only Lee took PATCH 1 so far. > > If you don`t hava a problem, please merge your input git tree. > > Applied, thank you. Patches 2-4 depend on linux/mfd/max77843-private.h from Patch 1, so taking them independently will introduce build problems. > [...] > > >>+++ b/drivers/input/misc/max77843-haptic.c > > >>[...] > > >>+#include > > >>[...] -- Sebastian signature.asc Description: Digital signature
Re: [PATCH v7 3/5] power: max77843_battery: Add Max77843 fuel gauge device driver
Hi, On Mon, Mar 02, 2015 at 07:10:36PM +0900, Jaewon Kim wrote: > From: Beomho Seo > > This patch adds device driver of max77843 fuel gauge. > The driver support for battery fuel gauge in Maxim Max77843. > It is fuel-gauge systems for lithuum-ion batteries in handled and > portable devices. > > Cc: Sebastian Reichel > Signed-off-by: Beomho Seo Reviewed-By: Sebastian Reichel I can't take it as is, since it depends on the private header file of PATCH 1. -- Sebastian signature.asc Description: Digital signature
Re: [PATCH v7 2/5] power: max77843_charger: Add Max77843 charger device driver
On Mon, Mar 02, 2015 at 07:10:35PM +0900, Jaewon Kim wrote: > From: Beomho Seo > > This patch adds device driver of max77843 charger. This driver provide > initialize each charging mode(e.g. fast charge, top-off mode and constant > charging mode so on.). Additionally, control charging paramters to use > i2c interface. > > Cc: Sebastian Reichel > Signed-off-by: Beomho Seo Reviewed-By: Sebastian Reichel I can't take it as is, since it depends on the private header file of PATCHv1. -- Sebastian signature.asc Description: Digital signature
Re: [RFC/PATCHv2 2/3] dt-binding: spi: spi-dw: Select 16b or 32b access for Designware SPI
On Sat, Mar 7, 2015 at 1:46 AM, wrote: > From: Thor Thayer > > Altera's Arria10 architecture requires a 32bit write accesses for > APB peripherals. The current spi-dw driver uses 16bit accesses in > some locations. This patch updated the bindings with an optional > field in the devicetree to select 32bit accesses. > One comment below. > Signed-off-by: Thor Thayer > --- > Documentation/devicetree/bindings/spi/spi-dw.txt |1 + > 1 file changed, 1 insertion(+) > > diff --git a/Documentation/devicetree/bindings/spi/spi-dw.txt > b/Documentation/devicetree/bindings/spi/spi-dw.txt > index 7b63ed6..034dbdd 100644 > --- a/Documentation/devicetree/bindings/spi/spi-dw.txt > +++ b/Documentation/devicetree/bindings/spi/spi-dw.txt > @@ -11,6 +11,7 @@ Required properties: > > Optional properties: > - cs-gpios: see spi-bus.txt > +- 32bit_access : use 32 bit register accesses > The most big issue for my opinion with DT is an absence of the standard for naming properties. So, why underscore? May be it's a time to append a generic description of this field to Documentation/devicetree/… -- With Best Regards, Andy Shevchenko -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v1 0/3 RESEND] NI Ettus Research USRP E3x0 soft-poweroff.
Hi, Please CC linux-pm. On Wed, Mar 04, 2015 at 02:25:46PM -0800, Moritz Fischer wrote: > This patchset adds support for the NI Ettus Research USRP E3x0 SDR's poweroff > functionality. I would prefer to have a generic driver like syscon-reboot does for system reset. -- Sebastian signature.asc Description: Digital signature
Re: [RFC/PATCHv2 3/3] spi: dw-spi: Pointers select 16b vs. 32b DesignWare access
On Sat, Mar 7, 2015 at 1:46 AM, wrote:
> From: Thor Thayer
>
> Altera's Arria10 SoC interconnect requires a 32 bit write for APB
> peripherals. The current spi-dw driver uses 16bit accesses in
> some locations. Use function pointers to support 32 bit accesses
> but retain legacy 16 bit access.
>
Thanks for this version. My comments below.
> Signed-off-by: Thor Thayer
> ---
> drivers/spi/spi-dw-mmio.c |7 ++-
> drivers/spi/spi-dw.c | 29 +
> drivers/spi/spi-dw.h | 12
> 3 files changed, 35 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/spi/spi-dw-mmio.c b/drivers/spi/spi-dw-mmio.c
> index eb03e12..c4fe9e9 100644
> --- a/drivers/spi/spi-dw-mmio.c
> +++ b/drivers/spi/spi-dw-mmio.c
> @@ -76,8 +76,13 @@ static int dw_spi_mmio_probe(struct platform_device *pdev)
>
> num_cs = 4;
>
> - if (pdev->dev.of_node)
> + if (pdev->dev.of_node) {
> of_property_read_u32(pdev->dev.of_node, "num-cs", &num_cs);
> + if (of_property_read_bool(pdev->dev.of_node, "32bit_access"))
> {
> + dws->read_w = dw_readw32;
> + dws->write_w = dw_writew32;
Can we use just readw/writew (w/o underscores) as names for the accessors?
> + }
> + }
>
> dws->num_cs = num_cs;
>
> diff --git a/drivers/spi/spi-dw.c b/drivers/spi/spi-dw.c
> index c5fa2be..d008791 100644
> --- a/drivers/spi/spi-dw.c
> +++ b/drivers/spi/spi-dw.c
> @@ -157,7 +157,7 @@ static inline u32 tx_max(struct dw_spi *dws)
> u32 tx_left, tx_room, rxtx_gap;
>
> tx_left = (dws->tx_end - dws->tx) / dws->n_bytes;
> - tx_room = dws->fifo_len - dw_readw(dws, DW_SPI_TXFLR);
> + tx_room = dws->fifo_len - dws->read_w(dws, DW_SPI_TXFLR);
>
> /*
> * Another concern is about the tx/rx mismatch, we
> @@ -178,7 +178,7 @@ static inline u32 rx_max(struct dw_spi *dws)
> {
> u32 rx_left = (dws->rx_end - dws->rx) / dws->n_bytes;
>
> - return min_t(u32, rx_left, dw_readw(dws, DW_SPI_RXFLR));
> + return min_t(u32, rx_left, dws->read_w(dws, DW_SPI_RXFLR));
> }
>
> static void dw_writer(struct dw_spi *dws)
> @@ -194,7 +194,7 @@ static void dw_writer(struct dw_spi *dws)
> else
> txw = *(u16 *)(dws->tx);
> }
> - dw_writew(dws, DW_SPI_DR, txw);
> + dws->write_w(dws, DW_SPI_DR, txw);
> dws->tx += dws->n_bytes;
> }
> }
> @@ -205,7 +205,7 @@ static void dw_reader(struct dw_spi *dws)
> u16 rxw;
>
> while (max--) {
> - rxw = dw_readw(dws, DW_SPI_DR);
> + rxw = dws->read_w(dws, DW_SPI_DR);
> /* Care rx only if the transfer's original "rx" is not null */
> if (dws->rx_end - dws->len) {
> if (dws->n_bytes == 1)
> @@ -254,11 +254,11 @@ static void int_error_stop(struct dw_spi *dws, const
> char *msg)
>
> static irqreturn_t interrupt_transfer(struct dw_spi *dws)
> {
> - u16 irq_status = dw_readw(dws, DW_SPI_ISR);
> + u16 irq_status = dws->read_w(dws, DW_SPI_ISR);
>
> /* Error handling */
> if (irq_status & (SPI_INT_TXOI | SPI_INT_RXOI | SPI_INT_RXUI)) {
> - dw_readw(dws, DW_SPI_ICR);
> + dws->read_w(dws, DW_SPI_ICR);
> int_error_stop(dws, "interrupt_transfer: fifo
> overrun/underrun");
> return IRQ_HANDLED;
> }
> @@ -283,7 +283,7 @@ static irqreturn_t dw_spi_irq(int irq, void *dev_id)
> {
> struct spi_master *master = dev_id;
> struct dw_spi *dws = spi_master_get_devdata(master);
> - u16 irq_status = dw_readw(dws, DW_SPI_ISR) & 0x3f;
> + u16 irq_status = dws->read_w(dws, DW_SPI_ISR) & 0x3f;
>
> if (!irq_status)
> return IRQ_NONE;
> @@ -379,7 +379,7 @@ static int dw_spi_transfer_one(struct spi_master *master,
> cr0 |= (chip->tmode << SPI_TMOD_OFFSET);
> }
>
> - dw_writew(dws, DW_SPI_CTRL0, cr0);
> + dws->write_w(dws, DW_SPI_CTRL0, cr0);
>
> /* Check if current transfer is a DMA transaction */
> dws->dma_mapped = map_dma_buffers(master, spi, transfer);
> @@ -393,7 +393,7 @@ static int dw_spi_transfer_one(struct spi_master *master,
> */
> if (!dws->dma_mapped && !chip->poll_mode) {
> txlevel = min_t(u16, dws->fifo_len / 2, dws->len /
> dws->n_bytes);
> - dw_writew(dws, DW_SPI_TXFLTR, txlevel);
> + dws->write_w(dws, DW_SPI_TXFLTR, txlevel);
>
> /* Set the interrupt mask */
> imask |= SPI_INT_TXEI | SPI_INT_TXOI |
> @@ -516,11 +516,11 @@ static void spi_hw_init(struct device *dev, struct
> dw_spi *dws)
> u32 fifo;
>
> for (fifo = 1; fifo < 256; fifo++) {
> - dw_writew(dws, DW_SPI_TXFLTR, fi
Re: [RFC/PATCHv2 1/3] spi: dw-spi: Single Register read to clear IRQs
On Sat, Mar 7, 2015 at 1:46 AM, wrote:
> From: Thor Thayer
>
> Instead of clearing the RxU, RxO, and TxO IRQs individually with
> 3 register reads, a single read of the ICR register will do the
> same thing.
>
> Signed-off-by: Thor Thayer
> Signed-off-by: Andy Shevchenko
Rather Suggested-by: …
Otherwise,
Acked-by: Andy Shevchenko
> ---
> drivers/spi/spi-dw.c |4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/drivers/spi/spi-dw.c b/drivers/spi/spi-dw.c
> index 950bc50..c5fa2be 100644
> --- a/drivers/spi/spi-dw.c
> +++ b/drivers/spi/spi-dw.c
> @@ -258,9 +258,7 @@ static irqreturn_t interrupt_transfer(struct dw_spi *dws)
>
> /* Error handling */
> if (irq_status & (SPI_INT_TXOI | SPI_INT_RXOI | SPI_INT_RXUI)) {
> - dw_readw(dws, DW_SPI_TXOICR);
> - dw_readw(dws, DW_SPI_RXOICR);
> - dw_readw(dws, DW_SPI_RXUICR);
> + dw_readw(dws, DW_SPI_ICR);
> int_error_stop(dws, "interrupt_transfer: fifo
> overrun/underrun");
> return IRQ_HANDLED;
> }
> --
> 1.7.9.5
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-spi" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
With Best Regards,
Andy Shevchenko
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4] spi: qup: Add DMA capabilities
On Sat, Mar 7, 2015 at 1:21 PM, Mark Brown wrote: > On Wed, Mar 04, 2015 at 12:02:05PM +0200, Stanimir Varbanov wrote: >> From: Andy Gross >> >> This patch adds DMA capabilities to the spi-qup driver. If DMA channels are >> present, the QUP will use DMA instead of block mode for transfers to/from SPI >> peripherals for transactions larger than the length of a block. > > Applied, but why is there no devm_dma_request_slave_channel_reason()? I suppose the answer would be "we have a lot of slightly different cases and we have to get rid of current mess with legacy API calls". The most problematic stuff now inside DMA slave subsystem is so called "filter function". It's a main impediment right now as I understand. -- With Best Regards, Andy Shevchenko -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v10 0/2] drivers/gpio: Altera soft IP GPIO driver
On Tue, Feb 24, 2015 at 10:53 AM, wrote: > From: Tien Hock Loh > > Adds a new device tree binding and driver for Altera soft GPIO IP. > The driver is able to do read/write and allows GPIO to be a interrupt > controller. > > Tested on Altera GHRD on interrupt handling and IO. > > v10: > Updated conflicting device tree parameters > Removed unused headers > Used macro instead of magic numbers for ngpio > Code readability cleanup using ?: and temporal variables > Removed leftover garbage and unnecessary function calls > Checked bgpio_init but unusable because Altera GPIO may not be a multiple of > 8 bits This v10 patch applied. Any remaining issues can certainly be resolved by additional patches in-tree. Good patience and good work, the driver looks really really neat now. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/7] ARM: dts: sun4i: Enable tablet keys on Chuwi V7 CW0825
Enable the lradc controlled tablet keys on the Chuwi V7 CW0825 tablet.
Signed-off-by: Hans de Goede
---
arch/arm/boot/dts/sun4i-a10-chuwi-v7-cw0825.dts | 27 +
1 file changed, 27 insertions(+)
diff --git a/arch/arm/boot/dts/sun4i-a10-chuwi-v7-cw0825.dts
b/arch/arm/boot/dts/sun4i-a10-chuwi-v7-cw0825.dts
index 58214f2..97fca89 100644
--- a/arch/arm/boot/dts/sun4i-a10-chuwi-v7-cw0825.dts
+++ b/arch/arm/boot/dts/sun4i-a10-chuwi-v7-cw0825.dts
@@ -49,6 +49,7 @@
#include "sun4i-a10.dtsi"
#include "sunxi-common-regulators.dtsi"
#include
+#include
/ {
model = "Chuwi V7 CW0825";
@@ -74,6 +75,32 @@
};
};
+&lradc {
+ vref-supply = <®_vcc3v0>;
+ status = "okay";
+
+ button@800 {
+ label = "Volume Up";
+ linux,code = ;
+ channel = <0>;
+ voltage = <80>;
+ };
+
+ button@1000 {
+ label = "Volume Down";
+ linux,code = ;
+ channel = <0>;
+ voltage = <100>;
+ };
+
+ button@1200 {
+ label = "Back";
+ linux,code = ;
+ channel = <0>;
+ voltage = <120>;
+ };
+};
+
&mmc0 {
pinctrl-names = "default";
pinctrl-0 = <&mmc0_pins_a>, <&mmc0_cd_pin_reference_design>;
--
2.3.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 6/7] ARM: dts: sun7i: Add OOB irq support to boards with broadcom sdio wifi
Signed-off-by: Hans de Goede
---
arch/arm/boot/dts/sun7i-a20-cubietruck.dts | 11 +++
arch/arm/boot/dts/sun7i-a20-i12-tvbox.dts | 11 +++
2 files changed, 22 insertions(+)
diff --git a/arch/arm/boot/dts/sun7i-a20-cubietruck.dts
b/arch/arm/boot/dts/sun7i-a20-cubietruck.dts
index 0c219a4..8111b0c 100644
--- a/arch/arm/boot/dts/sun7i-a20-cubietruck.dts
+++ b/arch/arm/boot/dts/sun7i-a20-cubietruck.dts
@@ -167,12 +167,23 @@
};
&mmc3 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
pinctrl-names = "default";
pinctrl-0 = <&mmc3_pins_a>;
vmmc-supply = <®_vmmc3>;
bus-width = <4>;
non-removable;
status = "okay";
+
+ brcmf: bcrmf@1 {
+ reg = <1>;
+ compatible = "brcm,bcm4329-fmac";
+ interrupt-parent = <&pio>;
+ interrupts = <10 8>; /* PH10 / EINT10 */
+ interrupt-names = "host-wake";
+ };
};
&mmc3_pins_a {
diff --git a/arch/arm/boot/dts/sun7i-a20-i12-tvbox.dts
b/arch/arm/boot/dts/sun7i-a20-i12-tvbox.dts
index baee563..4a8defd 100644
--- a/arch/arm/boot/dts/sun7i-a20-i12-tvbox.dts
+++ b/arch/arm/boot/dts/sun7i-a20-i12-tvbox.dts
@@ -164,12 +164,23 @@
};
&mmc3 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
pinctrl-names = "default";
pinctrl-0 = <&mmc3_pins_a>;
vmmc-supply = <®_vmmc3>;
bus-width = <4>;
non-removable;
status = "okay";
+
+ brcmf: bcrmf@1 {
+ reg = <1>;
+ compatible = "brcm,bcm4329-fmac";
+ interrupt-parent = <&pio>;
+ interrupts = <10 8>; /* PH10 / EINT10 */
+ interrupt-names = "host-wake";
+ };
};
&mmc3_pins_a {
--
2.3.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/7] ARM: dts: sun5i: Stop using different compatibles for ehci/ohci on a13 vs a10s
The A13 and the A10s use the same die (this has been confirmed by Allwinner),
as such there is no need to differentiate between the ehci/ohci parts of both,
the only reasons there were different allwinner,sun5i-a*-foo compatible
between these 2 parts is costemetically and because we could when we still
had 2 completely different dtsi files.
The allwinner,sun5i-a*-foo compatible strings are not used for binding at all,
the actual driver binds to the generic-?hci compatible, so we can safely remove
this cosmetical difference and simplify the dtsi files.
Signed-off-by: Hans de Goede
---
arch/arm/boot/dts/sun5i-a10s.dtsi | 8
arch/arm/boot/dts/sun5i-a13.dtsi | 8
arch/arm/boot/dts/sun5i.dtsi | 2 ++
3 files changed, 2 insertions(+), 16 deletions(-)
diff --git a/arch/arm/boot/dts/sun5i-a10s.dtsi
b/arch/arm/boot/dts/sun5i-a10s.dtsi
index ef516db..a78c95d 100644
--- a/arch/arm/boot/dts/sun5i-a10s.dtsi
+++ b/arch/arm/boot/dts/sun5i-a10s.dtsi
@@ -157,14 +157,6 @@
};
};
-&ehci0 {
- compatible = "allwinner,sun5i-a10s-ehci", "generic-ehci";
-};
-
-&ohci0 {
- compatible = "allwinner,sun5i-a10s-ohci", "generic-ohci";
-};
-
&pio {
compatible = "allwinner,sun5i-a10s-pinctrl";
diff --git a/arch/arm/boot/dts/sun5i-a13.dtsi b/arch/arm/boot/dts/sun5i-a13.dtsi
index 5d9ce84..136158f 100644
--- a/arch/arm/boot/dts/sun5i-a13.dtsi
+++ b/arch/arm/boot/dts/sun5i-a13.dtsi
@@ -153,14 +153,6 @@
cooling-max-level = <6>;
};
-&ehci0 {
- compatible = "allwinner,sun5i-a13-ehci", "generic-ehci";
-};
-
-&ohci0 {
- compatible = "allwinner,sun5i-a13-ohci", "generic-ohci";
-};
-
&pio {
compatible = "allwinner,sun5i-a13-pinctrl";
diff --git a/arch/arm/boot/dts/sun5i.dtsi b/arch/arm/boot/dts/sun5i.dtsi
index 610ea18..416c4de 100644
--- a/arch/arm/boot/dts/sun5i.dtsi
+++ b/arch/arm/boot/dts/sun5i.dtsi
@@ -392,6 +392,7 @@
};
ehci0: usb@01c14000 {
+ compatible = "allwinner,sun5i-a13-ehci", "generic-ehci";
reg = <0x01c14000 0x100>;
interrupts = <39>;
clocks = <&ahb_gates 1>;
@@ -401,6 +402,7 @@
};
ohci0: usb@01c14400 {
+ compatible = "allwinner,sun5i-a13-ohci", "generic-ohci";
reg = <0x01c14400 0x100>;
interrupts = <40>;
clocks = <&usb_clk 6>, <&ahb_gates 2>;
--
2.3.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/7] ARM: dts: sun5i: Add new Auxtek-t004 board
The auxtek-t004:
http://www.fasttech.com/products/1110/10004200/1318603-auxtek-t004-allwinner-a10s-single-core-android-ics
Is an Allwinner A10s based hdmi tv stick with with 512M RAM, 4G nand flash,
toc9002 (bcm43362) sdio wifi, 1 USB host ports using an USB-A receptacle and
a 2 micro-usb receptacles, one for power and one for USB OTG.
The sdio wifi appears to not have an oob irq hooked up, so we rely on sdio-irq
support for it.
Signed-off-by: Hans de Goede
foo
---
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/sun5i-a10s-auxtek-t004.dts | 151 +++
2 files changed, 152 insertions(+)
create mode 100644 arch/arm/boot/dts/sun5i-a10s-auxtek-t004.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index beac15f..d824336 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -525,6 +525,7 @@ dtb-$(CONFIG_MACH_SUN4I) += \
sun4i-a10-olinuxino-lime.dtb \
sun4i-a10-pcduino.dtb
dtb-$(CONFIG_MACH_SUN5I) += \
+ sun5i-a10s-auxtek-t004.dtb \
sun5i-a10s-mk802.dtb \
sun5i-a10s-olinuxino-micro.dtb \
sun5i-a10s-r7-tv-dongle.dtb \
diff --git a/arch/arm/boot/dts/sun5i-a10s-auxtek-t004.dts
b/arch/arm/boot/dts/sun5i-a10s-auxtek-t004.dts
new file mode 100644
index 000..6c6fef7
--- /dev/null
+++ b/arch/arm/boot/dts/sun5i-a10s-auxtek-t004.dts
@@ -0,0 +1,151 @@
+/*
+ * Copyright 2015 Hans de Goede
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ * a) This file is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This file is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public
+ * License along with this file; if not, write to the Free
+ * Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston,
+ * MA 02110-1301 USA
+ *
+ * Or, alternatively,
+ *
+ * b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+#include "sun5i-a10s.dtsi"
+#include "sunxi-common-regulators.dtsi"
+#include
+#include
+
+/ {
+ model = "Auxtek t004 A10s hdmi tv-stick";
+ compatible = "allwinner,auxtek-t004", "allwinner,sun5i-a10s";
+
+ leds {
+ compatible = "gpio-leds";
+ pinctrl-names = "default";
+ pinctrl-0 = <&led_pins_t004>;
+
+ red {
+ label = "t004-tv-dongle:red:usr";
+ gpios = <&pio 1 2 GPIO_ACTIVE_HIGH>; /* PB2 */
+ default-state = "on";
+ };
+ };
+
+ reg_vmmc1: vmmc1 {
+ compatible = "regulator-fixed";
+ pinctrl-names = "default";
+ pinctrl-0 = <&mmc1_vcc_en_pin_t004>;
+ regulator-name = "vmmc1";
+ regulator-min-microvolt = <330>;
+ regulator-max-microvolt = <330>;
+ enable-active-high;
+ gpio = <&pio 1 18 GPIO_ACTIVE_HIGH>; /* PB18 */
+ };
+};
+
+&ehci0 {
+ status = "okay";
+};
+
+&mmc0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&mmc0_pins_a>, <&mmc0_cd_pin_t004>;
+ vmmc-supply = <®_vcc3v3>;
+ bus-width = <4>;
+ cd-gpios = <&pio 6 1 GPIO_ACTIVE_HIGH>; /* PG1 */
+ cd-inverted;
+ status = "okay";
[PATCH 5/7] ARM: dts: sun5i: Add new Utoo P66 board
The UTOO P66 is a 6" A13 tablet / lcd ereader. It features a 6" 480x800 ips
lcd screen, 512MB RAM & 4GB emmc.
Signed-off-by: Hans de Goede
---
arch/arm/boot/dts/Makefile | 3 +-
arch/arm/boot/dts/sun5i-a13-utoo-p66.dts | 203 +++
2 files changed, 205 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/boot/dts/sun5i-a13-utoo-p66.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index d824336..f97c5d3 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -531,7 +531,8 @@ dtb-$(CONFIG_MACH_SUN5I) += \
sun5i-a10s-r7-tv-dongle.dtb \
sun5i-a13-hsg-h702.dtb \
sun5i-a13-olinuxino.dtb \
- sun5i-a13-olinuxino-micro.dtb
+ sun5i-a13-olinuxino-micro.dtb \
+ sun5i-a13-utoo-p66.dtb
dtb-$(CONFIG_MACH_SUN6I) += \
sun6i-a31-app4-evb1.dtb \
sun6i-a31-colombus.dtb \
diff --git a/arch/arm/boot/dts/sun5i-a13-utoo-p66.dts
b/arch/arm/boot/dts/sun5i-a13-utoo-p66.dts
new file mode 100644
index 000..0f0a411
--- /dev/null
+++ b/arch/arm/boot/dts/sun5i-a13-utoo-p66.dts
@@ -0,0 +1,203 @@
+/*
+ * Copyright 2015 Hans de Goede
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ * a) This file is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This file is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public
+ * License along with this file; if not, write to the Free
+ * Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston,
+ * MA 02110-1301 USA
+ *
+ * Or, alternatively,
+ *
+ * b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+#include "sun5i-a13.dtsi"
+#include "sunxi-common-regulators.dtsi"
+#include
+#include
+#include
+
+/ {
+ model = "Utoo P66";
+ compatible = "utoo,p66", "allwinner,sun5i-a13";
+
+ i2c_lcd: i2c@0 {
+ /* The lcd panel i2c interface is hooked up via gpios */
+ compatible = "i2c-gpio";
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c_lcd_pins>;
+ gpios = <&pio 6 12 GPIO_ACTIVE_HIGH>, /* PG12, sda */
+ <&pio 6 10 GPIO_ACTIVE_HIGH>; /* PG10, scl */
+ i2c-gpio,delay-us = <5>;
+ };
+};
+
+&cpu0 {
+ cpu-supply = <®_dcdc2>;
+};
+
+&ehci0 {
+ status = "okay";
+};
+
+&i2c0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c0_pins_a>;
+ status = "okay";
+
+ axp209: pmic@34 {
+ reg = <0x34>;
+ interrupts = <0>;
+ };
+};
+
+#include "axp209.dtsi"
+
+&i2c1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c1_pins_a>;
+ status = "okay";
+
+ pcf8563: rtc@51 {
+ compatible = "nxp,pcf8563";
+ reg = <0x51>;
+ };
+};
+
+&lradc {
+ vref-supply = <®_ldo2>;
+ status = "okay";
+
+ button@200 {
+ label = "Volume Up";
+ linux,code = ;
+ channel = <0>;
+ voltage = <20>;
+ };
+
+ button@400 {
+ label = "Volume Down";
+ linux,code = ;
+ channel = <0>;
+ voltage = <40>;
+ };
+};
+
+&mmc0 {
+ pinctr
[PATCH 7/7] ARM: dts: sun7i: Enable cap-sdio-irq for bananapro sdio wifi
The sdio wifi on the Banana Pro does not appear to have an oob irq hooked up, so enable sdio-irq support to avoid unnecessary polling. Signed-off-by: Hans de Goede --- arch/arm/boot/dts/sun7i-a20-bananapro.dts | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/boot/dts/sun7i-a20-bananapro.dts b/arch/arm/boot/dts/sun7i-a20-bananapro.dts index fb89fe7..d0cd78f 100644 --- a/arch/arm/boot/dts/sun7i-a20-bananapro.dts +++ b/arch/arm/boot/dts/sun7i-a20-bananapro.dts @@ -164,6 +164,7 @@ vmmc-supply = <®_vmmc3>; bus-width = <4>; non-removable; + cap-sdio-irq; status = "okay"; }; -- 2.3.1 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/7] ARM: dts: sun5i: Add mmc2 pinmux settings
Add A13 mmc2 pinmux settings, note these are for a 8bit bus.
Signed-off-by: Hans de Goede
---
arch/arm/boot/dts/sun5i.dtsi | 9 +
1 file changed, 9 insertions(+)
diff --git a/arch/arm/boot/dts/sun5i.dtsi b/arch/arm/boot/dts/sun5i.dtsi
index 416c4de..244d896 100644
--- a/arch/arm/boot/dts/sun5i.dtsi
+++ b/arch/arm/boot/dts/sun5i.dtsi
@@ -469,6 +469,15 @@
allwinner,drive = ;
allwinner,pull = ;
};
+
+ mmc2_pins_a: mmc2@0 {
+ allwinner,pins = "PC6", "PC7", "PC8", "PC9",
+ "PC10", "PC11", "PC12", "PC13",
+ "PC14", "PC15";
+ allwinner,function = "mmc2";
+ allwinner,drive = ;
+ allwinner,pull = ;
+ };
};
timer@01c20c00 {
--
2.3.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 0/8] imx25 adc and touchscreen driver
On 03/03/15 07:58, Markus Pargmann wrote: > Hi, > > This series adds a driver for the Freescale i.MX25 SoC internal ADC unit which > is used for touchscreen and ADC. The driver consists of three parts, the MFD > driver which handles interrupts and some central configuration registers, the > ADC driver and the touchscreen driver. > > v7 has some modifications in the probe functions to use devres irq requests. > irq checks were fixed to check for irqs <= 0. The header was cleaned up to > have > a more uniform presentation of the bit fields. Detailed changelogs are > attached > to the according mails. > > Best Regards, > > Markus Almost there as far as I am concerned. Just that one unbalanced regulator_enable that needs dealing with. The bindings are pretty simple so whilst a device-tree ack would of course be great I guess it could be taken without. This wants to go via mfd or I suppose the freescale/arm-soc tree. Either is fine with me. Jonathan > > > Denis Carikli (2): > ARM: dts: imx25: Add TSC and ADC support > ARM: imx_v4_v5_defconfig: Add I.MX25 Touchscreen controller and ADC > support. > > Markus Pargmann (6): > ARM: dt: Binding documentation for imx25 ADC/TSC > ARM: dt: Binding documentation for imx25 GCQ > ARM: dt: Binding documentation for imx25 touchscreen controller > mfd: fsl imx25 Touchscreen ADC driver > iio: adc: fsl,imx25-gcq driver > input: touchscreen: imx25 tcq driver > > .../devicetree/bindings/iio/adc/fsl,imx25-gcq.txt | 54 ++ > .../bindings/input/touchscreen/fsl-mx25-tcq.txt| 29 + > .../devicetree/bindings/mfd/fsl-imx25-tsadc.txt| 46 ++ > arch/arm/boot/dts/imx25.dtsi | 30 +- > arch/arm/configs/imx_v4_v5_defconfig | 4 + > drivers/iio/adc/Kconfig| 7 + > drivers/iio/adc/Makefile | 1 + > drivers/iio/adc/fsl-imx25-gcq.c| 356 + > drivers/input/touchscreen/Kconfig | 6 + > drivers/input/touchscreen/Makefile | 1 + > drivers/input/touchscreen/fsl-imx25-tcq.c | 593 > + > drivers/mfd/Kconfig| 10 + > drivers/mfd/Makefile | 2 + > drivers/mfd/fsl-imx25-tsadc.c | 164 ++ > include/dt-bindings/iio/adc/fsl-imx25-gcq.h| 18 + > include/linux/mfd/imx25-tsadc.h| 141 + > 16 files changed, 1459 insertions(+), 3 deletions(-) > create mode 100644 > Documentation/devicetree/bindings/iio/adc/fsl,imx25-gcq.txt > create mode 100644 > Documentation/devicetree/bindings/input/touchscreen/fsl-mx25-tcq.txt > create mode 100644 Documentation/devicetree/bindings/mfd/fsl-imx25-tsadc.txt > create mode 100644 drivers/iio/adc/fsl-imx25-gcq.c > create mode 100644 drivers/input/touchscreen/fsl-imx25-tcq.c > create mode 100644 drivers/mfd/fsl-imx25-tsadc.c > create mode 100644 include/dt-bindings/iio/adc/fsl-imx25-gcq.h > create mode 100644 include/linux/mfd/imx25-tsadc.h > -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 1/8] ARM: dt: Binding documentation for imx25 ADC/TSC
On 05/03/15 07:12, Markus Pargmann wrote:
> Hi,
>
> On Tue, Mar 03, 2015 at 10:02:12AM +0100, Arnd Bergmann wrote:
>> On Tuesday 03 March 2015 08:58:11 Markus Pargmann wrote:
>>> +Example:
>>> + tscadc: tscadc@5003 {
>>> + compatible = "fsl,imx25-tsadc";
>>> + reg = <0x5003 0xc>;
>>> + interrupts = <46>;
>>> + clocks = <&clks 119>;
>>> + clock-names = "ipg";
>>> + interrupt-controller;
>>> + #interrupt-cells = <1>;
>>> + #address-cells = <1>;
>>> + #size-cells = <1>;
>>> + ranges;
>>> +
>>> + tsc: tcq@50030400 {
>>> + compatible = "fsl,imx25-tcq";
>>> + reg = <0x50030400 0x60>;
>>> + ...
>>> + };
>>> +
>>> + adc: gcq@50030800 {
>>> + compatible = "fsl,imx25-gcq";
>>> + reg = <0x50030800 0x60>;
>>> + ...
>>> + };
>>> + };
>>>
>>
>> I wonder if we should just treat this MFD as a single IIO device
>> that also registers to the input layer.
>>
>> Are there any other registers in the 0x5003-0x50031000
>> range, or could the fsl,imx25-tcq and fsl,imx25-gcq devices
>> be reused outside of a fsl,imx25-tsadc device?
>
> There are no other registers in this range. The tcq and gcq devices can
> not be used outside of the tsadc. gcq and tcq are identical units so it
> may work to use both of them as gcq for example but nothing else.
>
> It may work to have this as single IIO device. However this would be a
> major rework of this series. There are a lot less users of imx25 than
> imx6 for example. And of these users barely anyone uses this unit at
> all. I really would like to get these drivers mainline so others can use
> it. But after 1 year and 7 versions of this series I don't want to put
> a lot of work into these drivers. I think there are other components in
> the kernel where the time is better used.
>
> Best Regards,
>
> Markus
>
I was pretty much against the IIO driver registering with input at least
where it was vaguely separable. Pushed a few drivers in this direction.
Slightly more code, but often these devices are pretty separable (even
if like here it's two identical hardware blocks) and we normally get
a whole chunk of touch screen specific magic hardware that isn't of
general use.
It would be lovely to try and generalize some of this stuff and have
the touchscreen driver act as a client of IIO, but the
hardware is too fiddly for it to be obvious how to do it so far.
Jonathan
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 5/8] iio: adc: fsl,imx25-gcq driver
On 03/03/15 07:58, Markus Pargmann wrote:
> This is a conversion queue driver for the mx25 SoC. It uses the central
> ADC which is used by two seperate independent queues. This driver
> prepares different conversion configurations for each possible input.
> For a conversion it creates a conversionqueue of one item with the
> correct configuration for the chosen channel. It then executes the queue
> once and disables the conversion queue afterwards.
>
> The reference voltages are configurable through devicetree subnodes,
> depending on the connections of the ADC inputs.
>
> Signed-off-by: Markus Pargmann
> Signed-off-by: Denis Carikli
> Signed-off-by: Markus Pargmann
There's an unbalanced regulator_enable that needs fixing.
Deal with that in both the remove and the error cases
and I'm happy.
> ---
>
> Notes:
> Changes in v7:
> - Remove separate functions mx25_gcq_disable/enable_eoq() as they were
> used at
>only one position
> - Enforce an external reference regulator if one of the conversions uses
> it as
>reference. The devm_regulator_get() call was moved into
>mx25_gcq_setup_cfgs() to be able to acquire the reference regulator
> when
>necessary.
> - Store indio_dev as platform driver data instead of the private data.
> This
>was changed in probe() and remove().
>
> Changes in v6:
> - Added defines for a complete list of references in the dt binding
> macros
>
> drivers/iio/adc/Kconfig | 7 +
> drivers/iio/adc/Makefile| 1 +
> drivers/iio/adc/fsl-imx25-gcq.c | 356
>
> include/dt-bindings/iio/adc/fsl-imx25-gcq.h | 18 ++
> 4 files changed, 382 insertions(+)
> create mode 100644 drivers/iio/adc/fsl-imx25-gcq.c
> create mode 100644 include/dt-bindings/iio/adc/fsl-imx25-gcq.h
>
> diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
> index 202daf889be2..947805d03d6c 100644
> --- a/drivers/iio/adc/Kconfig
> +++ b/drivers/iio/adc/Kconfig
> @@ -154,6 +154,13 @@ config EXYNOS_ADC
> of SoCs for drivers such as the touchscreen and hwmon to use to share
> this resource.
>
> +config FSL_MX25_ADC
> + tristate "Freescale MX25 ADC driver"
> + depends on MFD_MX25_TSADC
> + help
> + Generic Conversion Queue driver used for general purpose ADC in the
> + MX25. This driver supports single measurements using the MX25 ADC.
> +
> config LP8788_ADC
> tristate "LP8788 ADC driver"
> depends on MFD_LP8788
> diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile
> index 0315af640866..409583975ba0 100644
> --- a/drivers/iio/adc/Makefile
> +++ b/drivers/iio/adc/Makefile
> @@ -17,6 +17,7 @@ obj-$(CONFIG_AT91_ADC) += at91_adc.o
> obj-$(CONFIG_AXP288_ADC) += axp288_adc.o
> obj-$(CONFIG_CC10001_ADC) += cc10001_adc.o
> obj-$(CONFIG_EXYNOS_ADC) += exynos_adc.o
> +obj-$(CONFIG_FSL_MX25_ADC) += fsl-imx25-gcq.o
> obj-$(CONFIG_LP8788_ADC) += lp8788_adc.o
> obj-$(CONFIG_MAX1027) += max1027.o
> obj-$(CONFIG_MAX1363) += max1363.o
> diff --git a/drivers/iio/adc/fsl-imx25-gcq.c b/drivers/iio/adc/fsl-imx25-gcq.c
> new file mode 100644
> index ..18c21888aa4e
> --- /dev/null
> +++ b/drivers/iio/adc/fsl-imx25-gcq.c
> @@ -0,0 +1,356 @@
> +/*
> + * Copyright (C) 2014-2015 Pengutronix, Markus Pargmann
> + *
> + * 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.
> + *
> + * This is the driver for the imx25 GCQ (Generic Conversion Queue)
> + * connected to the imx25 ADC.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#define MX25_GCQ_TIMEOUT (msecs_to_jiffies(2000))
> +
> +enum mx25_gcq_cfgs {
> + MX25_CFG_XP = 0,
> + MX25_CFG_YP,
> + MX25_CFG_XN,
> + MX25_CFG_YN,
> + MX25_CFG_WIPER,
> + MX25_CFG_INAUX0,
> + MX25_CFG_INAUX1,
> + MX25_CFG_INAUX2,
> + MX25_NUM_CFGS,
> +};
> +
> +struct mx25_gcq_priv {
> + struct regmap *regs;
> + struct completion completed;
> + unsigned int settling_time;
> + struct clk *clk;
> + int irq;
> + struct regulator *ext_vref;
> + u32 channel_vref_mv[MX25_NUM_CFGS];
> +};
> +
> +#define MX25_CQG_CHAN(chan, id) {\
> + .type = IIO_VOLTAGE,\
> + .indexed = 1,\
> + .channel = chan,\
> + .info_mask_separate = BIT(IIO_CHAN_INFO_RAW),\
> + .info_mask_shared_by_type = BIT(IIO_CHAN_INFO_SCALE),\
> + .datasheet_name = id,\
> +}
> +
> +static const struct iio_chan_spec mx25_gcq_channels[MX25_NUM_CFGS] = {
> + MX25_CQG_CHAN(0, "xp"),
> + MX25_CQG_CHAN(1, "yp"),
> + MX25_CQG_CHAN(2, "xn"),
> + MX25_CQG_CHAN(3, "yn"),
> + MX25_CQG_CHAN(4, "wiper"),
> + MX25_CQG_CHAN(5, "inaux0"),
> + MX25_CQG_CHAN(6, "inaux1"),
> + MX25_
Re: [PATCH v7 4/8] mfd: fsl imx25 Touchscreen ADC driver
On 03/03/15 07:58, Markus Pargmann wrote:
> This is the core driver for imx25 touchscreen/adc driver. The module
> has one shared ADC and two different conversion queues which use the
> ADC. The two queues are identical. Both can be used for general purpose
> ADC but one is meant to be used for touchscreens.
>
> This driver is the core which manages the central components and
> registers of the TSC/ADC unit. It manages the IRQs and forwards them to
> the correct components.
>
> Signed-off-by: Markus Pargmann
> Signed-off-by: Denis Carikli
> Acked-by: Jonathan Cameron
hehe. Read it again (backwards so only just found my Ack).
Anyhow, one really minor comment inline. Feel free
to ignore it. Ack still stands.
> ---
>
> Notes:
> Changes in v7:
> - Cleanup bit defines in header files to be more readable
> - Fix irq check to return with an error for irq <= 0
> - Add COMPILE_TEST in Kconfig file
>
> Changes in v5:
> - Remove ifdef CONFIG_OF as this driver is only for DT usage
> - Remove module owner
> - Add Kconfig dependencies ARCH_MX25 and OF
>
> @Jonathan Cameron:
> I left your acked-by on the patch as these were small changes. If it
> should be
> removed, please say so. Thanks
>
> drivers/mfd/Kconfig | 10 +++
> drivers/mfd/Makefile| 2 +
> drivers/mfd/fsl-imx25-tsadc.c | 164
>
> include/linux/mfd/imx25-tsadc.h | 141 ++
> 4 files changed, 317 insertions(+)
> create mode 100644 drivers/mfd/fsl-imx25-tsadc.c
> create mode 100644 include/linux/mfd/imx25-tsadc.h
>
> diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
> index 38356e39adba..c0036aef61d7 100644
> --- a/drivers/mfd/Kconfig
> +++ b/drivers/mfd/Kconfig
> @@ -244,6 +244,16 @@ config MFD_MC13XXX_I2C
> help
> Select this if your MC13xxx is connected via an I2C bus.
>
> +config MFD_MX25_TSADC
> + tristate "Freescale i.MX25 integrated Touchscreen and ADC unit"
> + select REGMAP_MMIO
> + depends on SOC_IMX25 || COMPILE_TEST
> + depends on OF
> + help
> + Enable support for the integrated Touchscreen and ADC unit of the
> + i.MX25 processors. They consist of a conversion queue for general
> + purpose ADC and a queue for Touchscreens.
> +
> config MFD_HI6421_PMIC
> tristate "HiSilicon Hi6421 PMU/Codec IC"
> depends on OF
> diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
> index 19f3d744e3bd..acfe639e147c 100644
> --- a/drivers/mfd/Makefile
> +++ b/drivers/mfd/Makefile
> @@ -78,6 +78,8 @@ obj-$(CONFIG_TWL4030_POWER)+= twl4030-power.o
> obj-$(CONFIG_MFD_TWL4030_AUDIO) += twl4030-audio.o
> obj-$(CONFIG_TWL6040_CORE) += twl6040.o
>
> +obj-$(CONFIG_MFD_MX25_TSADC) += fsl-imx25-tsadc.o
> +
> obj-$(CONFIG_MFD_MC13XXX)+= mc13xxx-core.o
> obj-$(CONFIG_MFD_MC13XXX_SPI)+= mc13xxx-spi.o
> obj-$(CONFIG_MFD_MC13XXX_I2C)+= mc13xxx-i2c.o
> diff --git a/drivers/mfd/fsl-imx25-tsadc.c b/drivers/mfd/fsl-imx25-tsadc.c
> new file mode 100644
> index ..c4a3e15001ea
> --- /dev/null
> +++ b/drivers/mfd/fsl-imx25-tsadc.c
> @@ -0,0 +1,164 @@
> +/*
> + * Copyright (C) 2014-2015 Pengutronix, Markus Pargmann
> + *
> + * 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
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +static struct regmap_config mx25_tsadc_regmap_config = {
> + .fast_io = true,
> + .max_register = 8,
> + .reg_bits = 32,
> + .val_bits = 32,
> + .reg_stride = 4,
> +};
> +
> +static void mx25_tsadc_irq_handler(u32 irq, struct irq_desc *desc)
> +{
> + struct mx25_tsadc *tsadc = irq_desc_get_handler_data(desc);
> + struct irq_chip *chip = irq_get_chip(irq);
> + u32 status;
> +
> + chained_irq_enter(chip, desc);
> +
> + regmap_read(tsadc->regs, MX25_TSC_TGSR, &status);
> +
> + if (status & MX25_TGSR_GCQ_INT)
> + generic_handle_irq(irq_find_mapping(tsadc->domain, 1));
> +
> + if (status & MX25_TGSR_TCQ_INT)
> + generic_handle_irq(irq_find_mapping(tsadc->domain, 0));
> +
> + chained_irq_exit(chip, desc);
> +}
> +
> +static int mx25_tsadc_domain_map(struct irq_domain *d, unsigned int irq,
> + irq_hw_number_t hwirq)
> +{
> + struct mx25_tsadc *tsadc = d->host_data;
> +
> + irq_set_chip_data(irq, tsadc);
> + irq_set_chip_and_handler(irq, &dummy_irq_chip,
> + handle_level_irq);
> + set_irq_flags(irq, IRQF_VALID);
> +
> + return 0;
> +}
> +
> +static struct irq_domain_ops mx25_tsadc_domain_ops = {
> + .map = mx25_tsadc_domain_map,
> + .xlate = irq_domain_xlate_
Re: [PATCH 3/3] mtd: nand: add NAND driver for Broadcom STB NAND controller
On 7 March 2015 at 02:18, Brian Norris wrote: > This core originated in Set-Top Box chips (BCM7xxx) but is used in a > variety of other Broadcom chips, including some BCM63xxx, BCM33xx, and > iProc/Cygnus. It's been used only on ARM and MIPS SoCs, so restrict it > to those architectures. > > There are multiple revisions of this core throughout the years, and > almost every version broke register compatibility in some small way, but > with some effort, this driver is able to support v4.0, v5.0, v6.x, v7.0, > and v7.1. It's been tested on v5.0, v6.0, v7.0, and v7.1 recently, so > there hopefully are no more lurking inconsistencies. Unfortunately, it seems I can't make this driver work with my BCM4708 based router. This is a SoC with 6.01 controller. Sometimes I get this: [0.478443] brcmstb_nand 18028000.nand: timeout waiting for command 255 (9) [0.485385] brcmstb_nand 18028000.nand: intfc status f000 [0.588393] brcmstb_nand 18028000.nand: timeout waiting for command 144 (7) [0.595326] brcmstb_nand 18028000.nand: intfc status f000 [0.698392] brcmstb_nand 18028000.nand: timeout waiting for command 144 (7) [0.705322] brcmstb_nand 18028000.nand: intfc status f000 [0.711051] nand: second ID read did not match 20,20 against 20,00 [0.717197] nand: No NAND device found Other time: [0.478441] brcmstb_nand 18028000.nand: timeout waiting for command 255 (9) [0.485385] brcmstb_nand 18028000.nand: intfc status f000 [0.588396] brcmstb_nand 18028000.nand: timeout waiting for command 144 (7) [0.595327] brcmstb_nand 18028000.nand: intfc status f000 [0.698393] brcmstb_nand 18028000.nand: timeout waiting for command 144 (7) [0.705321] brcmstb_nand 18028000.nand: intfc status f000 [0.808394] brcmstb_nand 18028000.nand: timeout waiting for command 144 (7) [0.815326] brcmstb_nand 18028000.nand: intfc status f000 [0.918392] brcmstb_nand 18028000.nand: timeout waiting for command 144 (7) [0.925322] brcmstb_nand 18028000.nand: intfc status f000 [0.931047] nand: No NAND device found (Btw. I guess you could use 0x%x instead of %d for printing commands). It seems that brcmnand_ctlrdy_irq never fires on my device. Just like controller was never generating any IRQ. I started comparing your driver with OpenWrt's bcm_nand.c (which should be very similar to Broadcom's SDK NAND driver for ARM). Below are few things I've noticed. 1) In bcm_nand.c IRQ handler also doesn't seem to be fired (or very rarely). 2) In brcmnand_waitfunc you seem to be always waiting for an interrupt. This is different from OpenWrt's driver and Broadcom's reference code. In bcm_nand.c in bcmnand_wait_cmd we first check BIT(31) of IRQ STATUS (0x6c / 0x14 / BRCMNAND_INTFC_STATUS). If it's set, we assume command was already completed. 3) In bcm_nand.c in IRQ waiting function bcmnand_wait_interrupt we ack/enable/disable NANDC_IRQ_CONTROLLER_RDY (nand_ctlrdy) IRQ. I don't see that in your code, not sure if it's important. 4) It seems bcm_nand.c also uses some extra register 0x500 and its bit 0x1 (we call it NANDC_IDM_IO_CTRL_RDY). It this bit it set, we don't ever care about NANDC_IRQ_CONTROLLER_RDY (nand_ctlrdy) IRQ. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 3/8] ARM: dt: Binding documentation for imx25 touchscreen controller
On 03/03/15 07:58, Markus Pargmann wrote:
> This is the touchscreen conversion queue binding documentation. It uses
> the shared imx25 ADC.
>
> Signed-off-by: Markus Pargmann
Looks fine, one more general binding approach comment though.
A lot of the vendor specific elements in here are awfully generic.
Does it not make sense to have them as standard attributes for
touch screen drivers?
> ---
>
> Notes:
> Changes in v5:
> - Fix signed/unsigned comparison
> - Fix unused variable settling_time by putting it in the correct
> argument list
> - Use continous conversion queue with the repeat feature and a proper
>repeat-wait. Previously the touchscreen caused massive number of
> interrupts.
>
> .../bindings/input/touchscreen/fsl-mx25-tcq.txt| 29
> ++
> 1 file changed, 29 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/input/touchscreen/fsl-mx25-tcq.txt
>
> diff --git
> a/Documentation/devicetree/bindings/input/touchscreen/fsl-mx25-tcq.txt
> b/Documentation/devicetree/bindings/input/touchscreen/fsl-mx25-tcq.txt
> new file mode 100644
> index ..4214a99d197a
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/input/touchscreen/fsl-mx25-tcq.txt
> @@ -0,0 +1,29 @@
> +Freescale mx25 TS conversion queue module
> +
> +mx25 touchscreen conversion queue module which controls the ADC unit of the
> +mx25 for attached touchscreens.
> +
> +Required properties:
> + - compatible: Should be "fsl,imx25-tcq".
> + - reg: Memory range of the device.
> + - interrupts: Should be the interrupt number associated with this module
> within
> + the tscadc unit (<0>).
> + - interrupt-parent: Should be a phandle to the tscadc unit.
> + - fsl,wires: Should be '<4>' or '<5>'
> +
> +Optional properties:
> + - fsl,pen-debounce: Pen debounce time.
> + - fsl,pen-threshold: Pen-down threshold for the touchscreen.
> + - fsl,settling-time: Settling time in nanoseconds.
Obviously it's up to Dmitry etc, but are these not standard enough attributes to
not be vendor specific? I'd expect say touch-pen-debouce and
touch-pen-threshold
etc to be standard binding elements for touch screens.
> +
> +This device includes two conversion queues which can be added as subnodes.
> +The first queue is for the touchscreen, the second for general purpose ADC.
> +
> +Example:
> + tsc: tcq@50030400 {
> + compatible = "fsl,imx25-tcq";
> + reg = <0x50030400 0x60>;
> + interrupt-parent = <&tscadc>;
> + interrupts = <0>;
> + fsl,wires = <4>;
> + };
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 2/8] ARM: dt: Binding documentation for imx25 GCQ
On 03/03/15 07:58, Markus Pargmann wrote:
> The documentation describes the bindings for the imx25 GCQ unit which is
> essentially a generic conversion queue using the imx25 ADC.
>
> Signed-off-by: Markus Pargmann
Looks good to me, though ideally these would get a devicetree maintainer
ack.
Acked-by: Jonathan Cameron
> ---
>
> Notes:
> Changes in v6:
> - Changed bindings to use adc-refp and adc-refn. Also a bit of cleanup
> in the
>setup routine.
>
> Changes in v5:
> - Fixed locking
> - Removed module owner
>
> .../devicetree/bindings/iio/adc/fsl,imx25-gcq.txt | 54
> ++
> 1 file changed, 54 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/iio/adc/fsl,imx25-gcq.txt
>
> diff --git a/Documentation/devicetree/bindings/iio/adc/fsl,imx25-gcq.txt
> b/Documentation/devicetree/bindings/iio/adc/fsl,imx25-gcq.txt
> new file mode 100644
> index ..9f7c08990034
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/iio/adc/fsl,imx25-gcq.txt
> @@ -0,0 +1,54 @@
> +Freescale i.MX25 ADC GCQ device
> +
> +This is a generic conversion queue device that can convert any of the
> +analog inputs using the ADC unit of the i.MX25.
> +
> +Required properties:
> + - compatible: Should be "fsl,imx25-gcq".
> + - reg: Should be the register range of the module.
> + - interrupts: Should be the interrupt number of the module.
> + Typically this is <1>.
> + - interrupt-parent: phandle to the tsadc module of the i.MX25.
> + - #address-cells: Should be <1> (setting for the subnodes)
> + - #size-cells: Should be <0> (setting for the subnodes)
> +
> +Optional properties:
> + - vref-supply: The regulator supplying the ADC reference voltage.
> + Required when at least one subnode uses the external reference.
> +
> +Sub-nodes:
> +Optionally you can define subnodes which define the reference voltage
> +for the analog inputs.
> +
> +Required properties for subnodes:
> + - reg: Should be the number of the analog input.
> + 0: xp
> + 1: yp
> + 2: xn
> + 3: yn
> + 4: wiper
> + 5: inaux0
> + 6: inaux1
> + 7: inaux2
> +Optional properties for subnodes:
> + - fsl,adc-refp: specifies the positive reference input as defined in
> +
> + - fsl,adc-refn: specifies the negative reference input as defined in
> +
> +
> +Example:
> +
> + adc: adc@50030800 {
> + compatible = "fsl,imx25-gcq";
> + reg = <0x50030800 0x60>;
> + interrupt-parent = <&tscadc>;
> + interrupts = <1>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + inaux@5 {
> + reg = <5>;
> + fsl,adc-refp = ;
> + fsl,adc-refn = ;
> + };
> + };
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 1/8] ARM: dt: Binding documentation for imx25 ADC/TSC
On 03/03/15 07:58, Markus Pargmann wrote:
> This documentation describes the devicetree bindings for the
> ADC/Touchscreen unit of the i.MX25 SoC.
>
> Signed-off-by: Markus Pargmann
Straight forward and sensible.
Acked-by: Jonathan Cameron
> ---
>
> Notes:
> Changes in v6:
> - Removed adc-ref property and replaced it with refp and refn for
> positive and
>negative references. The properties are optional now as the default
>behaviour is a positive internal reference voltage and ADC GND as
> negative
>reference.
>
> .../devicetree/bindings/mfd/fsl-imx25-tsadc.txt| 46
> ++
> 1 file changed, 46 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/mfd/fsl-imx25-tsadc.txt
>
> diff --git a/Documentation/devicetree/bindings/mfd/fsl-imx25-tsadc.txt
> b/Documentation/devicetree/bindings/mfd/fsl-imx25-tsadc.txt
> new file mode 100644
> index ..a857af0eb68c
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mfd/fsl-imx25-tsadc.txt
> @@ -0,0 +1,46 @@
> +Freescale mx25 ADC/TSC multifunction device
> +
> +This device combines two general purpose conversion queues one used for
> general
> +ADC and the other used for touchscreens.
> +
> +Required properties:
> + - compatible: Should be "fsl,imx25-tsadc".
> + - reg: Memory range of the device.
> + - interrupts: Interrupt for this device as described in
> + interrupts/interrupts.txt
> + - clocks: An 'ipg' clock defined as described in clocks/clock.txt
> + - interrupt-controller: This device is an interrupt controller. It controls
> + the interrupts of both conversion queues.
> + - #interrupt-cells: Should be '<1>'.
> + - #address-cells: Should be '<1>'.
> + - #size-cells: Should be '<1>'.
> + - ranges
> +
> +This device includes two conversion queues which can be added as subnodes.
> +The first queue is for the touchscreen, the second for general purpose ADC.
> +
> +Example:
> + tscadc: tscadc@5003 {
> + compatible = "fsl,imx25-tsadc";
> + reg = <0x5003 0xc>;
> + interrupts = <46>;
> + clocks = <&clks 119>;
> + clock-names = "ipg";
> + interrupt-controller;
> + #interrupt-cells = <1>;
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges;
> +
> + tsc: tcq@50030400 {
> + compatible = "fsl,imx25-tcq";
> + reg = <0x50030400 0x60>;
> + ...
> + };
> +
> + adc: gcq@50030800 {
> + compatible = "fsl,imx25-gcq";
> + reg = <0x50030800 0x60>;
> + ...
> + };
> + };
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/2] regulator: act8865: add input supply handling
On Sat, Mar 07, 2015 at 04:33:53PM +0100, Heiko Stuebner wrote: > The act88600/act8846/act8865 regulators have a number of input supplies > supplying the individual regulators. This may even be recursively like on > most Rockchip boards using the act8846 where REG4 is most of the time > connected to the inl1-supply. Applied, thanks. The recursive supplies are very common - DCDCs are vastly more efficient than LDOs so if you've got the capacity and care about power it's much better to drop your main supply voltage down to something near the LDO headroom with a DCDC in order to improve system performance. signature.asc Description: Digital signature
Re: [PATCH][ASoC]Add DT bindings for generic ASoC AC97 CODEC driver
On Sat, Mar 07, 2015 at 04:33:12PM +0100, Maciej S. Szmigiero wrote: > W dniu 07.03.2015 15:34, Mark Brown pisze: > > That's true, and it's something it's easy to get away with with board > > files, but that doesn't mean it's something we should be doing for > > device tree where we're not just finding an expedient way to load things > > but rather defining an ABI. > Do you recommend then putting AC'97 bus/mixer attach in > simple-card/fsl-asoc-card or controller driver instead? It's tricky. For the vast majority of AC'97 systems we probably want to just do things from the bus controller but there are some funky AC'97 embedded systems out there which need quirks to varying degrees, and in some cases the ASoC AC'97 drivers do a much better job on things like power. For those we'd need to do something different to just doing a standard AC'97 instantiation but what exactly we do in a DT world (quirk on machine compatible?) isn't clear. If the platform you're working on isn't one that commonly got fancy AC'97 subsystems then it's possibly best to just do the common case and only worry about what to do about the complex case if anyone has a need. signature.asc Description: Digital signature
[PATCH 1/1] OMAPDSS: Correct video ports description file path in DT binding doc
The doc refers to Documentation/devicetree/bindings/video/video-ports.txt which does not exist. The documentation seems to be outdated and wants to refer to Documentation/devicetree/bindings/graph.txt instead. Suggested-by: Tomi Valkeinen Signed-off-by: Javier Martinez Canillas --- Documentation/devicetree/bindings/video/ti,omap-dss.txt | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Documentation/devicetree/bindings/video/ti,omap-dss.txt b/Documentation/devicetree/bindings/video/ti,omap-dss.txt index d5f1a3fe3109..e1ef29569338 100644 --- a/Documentation/devicetree/bindings/video/ti,omap-dss.txt +++ b/Documentation/devicetree/bindings/video/ti,omap-dss.txt @@ -25,8 +25,8 @@ Video Ports --- The DSS Core and the encoders have video port outputs. The structure of the -video ports is described in Documentation/devicetree/bindings/video/video- -ports.txt, and the properties for the ports and endpoints for each encoder are +video ports is described in Documentation/devicetree/bindings/graph.txt, +and the properties for the ports and endpoints for each encoder are described in the SoC's DSS binding documentation. The video ports are used to describe the connections to external hardware, like -- 2.1.4 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 1/2] regulator: act8865: add input supply handling
The act88600/act8846/act8865 regulators have a number of input supplies
supplying the individual regulators. This may even be recursively like on
most Rockchip boards using the act8846 where REG4 is most of the time
connected to the inl1-supply.
Therefore add the ability to specify the input supplies for the individual
inputs.
The input-names are taken from the datasheets of act8600, act8846 and act8865.
On the act8600 some regulators do not have separate input supplies.
Signed-off-by: Heiko Stuebner
---
changes since v1:
adapt to newly added act8600 support. In contrast to the previous 2 chips some
regulators of the act8600 do not seem to have separate input supplies.
.../bindings/regulator/act8865-regulator.txt | 22 +
drivers/regulator/act8865-regulator.c | 55 +++---
2 files changed, 50 insertions(+), 27 deletions(-)
diff --git a/Documentation/devicetree/bindings/regulator/act8865-regulator.txt
b/Documentation/devicetree/bindings/regulator/act8865-regulator.txt
index e170df2..e91485d 100644
--- a/Documentation/devicetree/bindings/regulator/act8865-regulator.txt
+++ b/Documentation/devicetree/bindings/regulator/act8865-regulator.txt
@@ -9,6 +9,28 @@ Optional properties:
- system-power-controller: Telling whether or not this pmic is controlling
the system power. See
Documentation/devicetree/bindings/power/power-controller.txt .
+Optional input supply properties:
+- for act8600:
+ - vp1-supply: The input supply for DCDC_REG1
+ - vp2-supply: The input supply for DCDC_REG2
+ - vp3-supply: The input supply for DCDC_REG3
+ - inl-supply: The input supply for LDO_REG5, LDO_REG6, LDO_REG7 and LDO_REG8
+ SUDCDC_REG4, LDO_REG9 and LDO_REG10 do not have separate supplies.
+- for act8846:
+ - vp1-supply: The input supply for REG1
+ - vp2-supply: The input supply for REG2
+ - vp3-supply: The input supply for REG3
+ - vp4-supply: The input supply for REG4
+ - inl1-supply: The input supply for REG5, REG6 and REG7
+ - inl2-supply: The input supply for REG8 and LDO_REG9
+ - inl3-supply: The input supply for REG10, REG11 and REG12
+- for act8865:
+ - vp1-supply: The input supply for DCDC_REG1
+ - vp2-supply: The input supply for DCDC_REG2
+ - vp3-supply: The input supply for DCDC_REG3
+ - inl45-supply: The input supply for LDO_REG1 and LDO_REG2
+ - inl67-supply: The input supply for LDO_REG3 and LDO_REG4
+
Any standard regulator properties can be used to configure the single
regulator.
The valid names for regulators are:
diff --git a/drivers/regulator/act8865-regulator.c
b/drivers/regulator/act8865-regulator.c
index 3781f6e..2ff73d7 100644
--- a/drivers/regulator/act8865-regulator.c
+++ b/drivers/regulator/act8865-regulator.c
@@ -173,9 +173,10 @@ static struct regulator_ops act8865_ldo_ops = {
.is_enabled = regulator_is_enabled_regmap,
};
-#define ACT88xx_REG(_name, _family, _id, _vsel_reg)\
+#define ACT88xx_REG(_name, _family, _id, _vsel_reg, _supply) \
[_family##_ID_##_id] = {\
.name = _name,\
+ .supply_name= _supply, \
.id = _family##_ID_##_id, \
.type = REGULATOR_VOLTAGE,\
.ops= &act8865_ops, \
@@ -190,9 +191,9 @@ static struct regulator_ops act8865_ldo_ops = {
}
static const struct regulator_desc act8600_regulators[] = {
- ACT88xx_REG("DCDC1", ACT8600, DCDC1, VSET),
- ACT88xx_REG("DCDC2", ACT8600, DCDC2, VSET),
- ACT88xx_REG("DCDC3", ACT8600, DCDC3, VSET),
+ ACT88xx_REG("DCDC1", ACT8600, DCDC1, VSET, "vp1"),
+ ACT88xx_REG("DCDC2", ACT8600, DCDC2, VSET, "vp2"),
+ ACT88xx_REG("DCDC3", ACT8600, DCDC3, VSET, "vp3"),
{
.name = "SUDCDC_REG4",
.id = ACT8600_ID_SUDCDC4,
@@ -207,10 +208,10 @@ static const struct regulator_desc act8600_regulators[] =
{
.enable_mask = ACT8865_ENA,
.owner = THIS_MODULE,
},
- ACT88xx_REG("LDO5", ACT8600, LDO5, VSET),
- ACT88xx_REG("LDO6", ACT8600, LDO6, VSET),
- ACT88xx_REG("LDO7", ACT8600, LDO7, VSET),
- ACT88xx_REG("LDO8", ACT8600, LDO8, VSET),
+ ACT88xx_REG("LDO5", ACT8600, LDO5, VSET, "inl"),
+ ACT88xx_REG("LDO6", ACT8600, LDO6, VSET, "inl"),
+ ACT88xx_REG("LDO7", ACT8600, LDO7, VSET, "inl"),
+ ACT88xx_REG("LDO8", ACT8600, LDO8, VSET, "inl"),
{
.name = "LDO_REG9",
.id = ACT8600_ID_LDO9,
@@ -236,28 +237,28 @@ static const struct regulator_desc act8600_regulators[] =
{
};
static const struct regulator_desc act8846_regulators[] = {
- ACT88xx_REG("REG1", ACT8846, REG1, VSET),
- ACT88xx_REG("REG2", ACT8846, REG2, VSET0),
- ACT88xx_REG("REG3
Re: [PATCH][ASoC]Add DT bindings for generic ASoC AC97 CODEC driver
W dniu 07.03.2015 15:34, Mark Brown pisze: > On Sat, Mar 07, 2015 at 02:58:53PM +0100, Maciej S. Szmigiero wrote: >> W dniu 07.03.2015 11:52, Mark Brown pisze: >>> On Fri, Mar 06, 2015 at 07:55:26PM +0100, Maciej S. Szmigiero wrote: > >>> AC'97 shouldn't need DT bindings for the CODEC, it's an enumerable bus. > >> What this driver did / does is essentially to allow attaching AC'97 bus >> to ASoC AC'97 controllers which don't do it on its own (from what I can >> see only board files do it). > > That's true, and it's something it's easy to get away with with board > files, but that doesn't mean it's something we should be doing for > device tree where we're not just finding an expedient way to load things > but rather defining an ABI. Do you recommend then putting AC'97 bus/mixer attach in simple-card/fsl-asoc-card or controller driver instead? >> This driver originally constrained rates to 8000, 11025, 22050, 44100, >> 48000. > >> An alternative would be to remove this constraint at all from this >> driver and leave such constraining for controller and AC'97 bus code. > > That's a much better approach. > >> But since this driver was originally limited to these rates I think it >> would be safer to do it only when instantiated via OF. > > Again, DT is defining an ABI. Best regards, Maciej Szmigiero -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[no subject]
Seeking Your Assistance In A Business Proposal get back to me if interested via email:mrjohn.w...@yahoo.com This email was scanned by BitDefender. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3] media: i2c: add support for omnivision's ov2659 sensor
From: Benoit Parrot
this patch adds support for omnivision's ov2659
sensor, the driver supports following features:
1: Asynchronous probing
2: DT support
3: Media controller support
Signed-off-by: Benoit Parrot
Signed-off-by: Lad, Prabhakar
---
Changes for v3:
a: Fixed review comments pointed by Sakari.
v2: https://patchwork.kernel.org/patch/5859801/
v1: https://patchwork.linuxtv.org/patch/27919/
.../devicetree/bindings/media/i2c/ov2659.txt | 38 +
MAINTAINERS| 10 +
drivers/media/i2c/Kconfig | 11 +
drivers/media/i2c/Makefile |1 +
drivers/media/i2c/ov2659.c | 1495
include/media/ov2659.h | 33 +
6 files changed, 1588 insertions(+)
create mode 100644 Documentation/devicetree/bindings/media/i2c/ov2659.txt
create mode 100644 drivers/media/i2c/ov2659.c
create mode 100644 include/media/ov2659.h
diff --git a/Documentation/devicetree/bindings/media/i2c/ov2659.txt
b/Documentation/devicetree/bindings/media/i2c/ov2659.txt
new file mode 100644
index 000..01d8d59
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/i2c/ov2659.txt
@@ -0,0 +1,38 @@
+* OV2659 1/5-Inch 2Mp SOC Camera
+
+The Omnivision OV2659 is a 1/5-inch SOC camera, with an active array size of
+1632H x 1212V. It is programmable through a SCCB. The OV2659 sensor supports
+multiple resolutions output, such as UXGA, SVGA, 720p. It also can support
+YUV422, RGB565/555 or raw RGB output formats.
+
+Required Properties:
+- compatible: Must be "ovti,ov2659"
+- reg: I2C slave address
+- clocks: reference to the xvclk input clock.
+- clock-names: should be "xvclk".
+- pixel-clock-frequency: Pixel clock frequency.
+
+For further reading on port node refer to
+Documentation/devicetree/bindings/media/video-interfaces.txt.
+
+Example:
+
+ i2c0@1c22000 {
+ ...
+ ...
+ov2659@30 {
+ compatible = "ovti,ov2659";
+ reg = <0x30>;
+
+ clocks = <&clk_ov2659 0>;
+ clock-names = "xvclk";
+
+ port {
+ ov2659_0: endpoint {
+ remote-endpoint = <&vpfe_ep>;
+ pixel-clock-frequency = <7000>;
+ };
+ };
+ };
+ ...
+ };
diff --git a/MAINTAINERS b/MAINTAINERS
index ddc5a8c..4006cc8 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -8910,6 +8910,16 @@ T: git
git://linuxtv.org/mhadli/v4l-dvb-davinci_devices.git
S: Maintained
F: drivers/media/platform/am437x/
+OV2659 OMNIVISION SENSOR DRIVER
+M: Lad, Prabhakar
+L: linux-me...@vger.kernel.org
+W: http://linuxtv.org/
+Q: http://patchwork.linuxtv.org/project/linux-media/list/
+T: git git://linuxtv.org/mhadli/v4l-dvb-davinci_devices.git
+S: Maintained
+F: drivers/media/i2c/ov2659.c
+F: include/media/ov2659.h
+
SIS 190 ETHERNET DRIVER
M: Francois Romieu
L: net...@vger.kernel.org
diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
index da58c9b..6f30ea7 100644
--- a/drivers/media/i2c/Kconfig
+++ b/drivers/media/i2c/Kconfig
@@ -466,6 +466,17 @@ config VIDEO_APTINA_PLL
config VIDEO_SMIAPP_PLL
tristate
+config VIDEO_OV2659
+ tristate "OmniVision OV2659 sensor support"
+ depends on VIDEO_V4L2 && I2C
+ depends on MEDIA_CAMERA_SUPPORT
+ ---help---
+ This is a Video4Linux2 sensor-level driver for the OmniVision
+ OV2659 camera.
+
+ To compile this driver as a module, choose M here: the
+ module will be called ov2659.
+
config VIDEO_OV7640
tristate "OmniVision OV7640 sensor support"
depends on I2C && VIDEO_V4L2
diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile
index 98589001..f165fae 100644
--- a/drivers/media/i2c/Makefile
+++ b/drivers/media/i2c/Makefile
@@ -77,3 +77,4 @@ obj-$(CONFIG_VIDEO_SMIAPP_PLL)+= smiapp-pll.o
obj-$(CONFIG_VIDEO_AK881X) += ak881x.o
obj-$(CONFIG_VIDEO_IR_I2C) += ir-kbd-i2c.o
obj-$(CONFIG_VIDEO_ML86V7667) += ml86v7667.o
+obj-$(CONFIG_VIDEO_OV2659) += ov2659.o
diff --git a/drivers/media/i2c/ov2659.c b/drivers/media/i2c/ov2659.c
new file mode 100644
index 000..98c8a18
--- /dev/null
+++ b/drivers/media/i2c/ov2659.c
@@ -0,0 +1,1495 @@
+/*
+ * Omnivision OV2659 CMOS Image Sensor driver
+ *
+ * Copyright (C) 2015 Texas Instruments, Inc.
+ *
+ * Benoit Parrot
+ * Lad, Prabhakar
+ *
+ * This program is free software; you may redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; version 2 of the License.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPL
Re: [PATCH 5/5] dts: mt8173: Add iommu/smi nodes for mt8173
Hi Yong,
On Fri, Mar 6, 2015 at 6:48 PM, wrote:
> From: Yong Wu
>
> This patch add the iommu/larbs nodes for mt8173
>
> Signed-off-by: Yong Wu
> ---
> arch/arm64/boot/dts/mediatek/mt8173.dtsi | 60
> include/dt-bindings/iommu/mt8173-iommu-port.h | 127
> ++
> 2 files changed, 187 insertions(+)
> create mode 100644 include/dt-bindings/iommu/mt8173-iommu-port.h
>
> diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> index c2a057f..805a7cd 100644
> --- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> +++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> @@ -16,6 +16,7 @@
> #include
> #include "mt8173-pinfunc.h"
> #include
> +#include
>
> / {
> compatible = "mediatek,mt8173";
> @@ -249,6 +250,65 @@
> interrupts = <0 86 8>;
> clocks = <&uart_clk>;
> };
> +
> + iommu: mmsys_iommu@10205000 {
> + compatible = "mediatek,mt8173-iommu";
> + reg = <0 0x10205000 0 0x1000>;
> + interrupts = ;
> + clocks = <&infrasys INFRA_M4U>;
> + clock-names = "infra_m4u";
> + larb = <&larb0 &larb1 &larb2 &larb3 &larb4 &larb5>;
> + #iommu-cells = <1>;
> + };
> +
> + larb0:larb@14021000 {
> + compatible = "mediatek,mt8173-smi-larb";
> + reg = <0 0x14021000 0 0x1000>;
> + clocks = <&mmsys MM_SMI_COMMON>, <&mmsys
> MM_SMI_LARB0>;
> + clock-names = "larb_sub0", "larb_sub1";
> + };
> +
> + larb1:larb@1601 {
> + compatible = "mediatek,mt8173-smi-larb";
> + reg = <0 0x1601 0 0x1000>;
> + clocks = <&mmsys MM_SMI_COMMON>,
> + <&vdecsys VDEC_CKEN>,
> + <&vdecsys VDEC_LARB_CKEN>;
> + clock-names = "larb_sub0", "larb_sub1", "larb_sub2";
> + };
> +
> + larb2:larb@1601 {
I think this one should be:
larb2: larb@15001000 {
Also, I am not a devicetree expert, but I believe nodes are usually
arranged in register order.
If that is the case, the order, as unfortunate as this looks, should be:
larb0: larb@14021000
larb4: larb@14027000
larb2: larb@15001000
larb1: larb@1601
larb3: larb@18001000
larb5: larb@19001000
-Dan
> + compatible = "mediatek,mt8173-smi-larb";
> + reg = <0 0x15001000 0 0x1000>;
> + clocks = <&mmsys MM_SMI_COMMON>,
> + <&imgsys IMG_LARB2_SMI>;
> + clock-names = "larb_sub0", "larb_sub1";
> + };
> +
> + larb3:larb@18001000 {
> + compatible = "mediatek,mt8173-smi-larb";
> + reg = <0 0x18001000 0 0x1000>;
> + clocks = <&mmsys MM_SMI_COMMON>,
> + <&vencsys VENC_CKE0>,
> + <&vencsys VENC_CKE1>;
> + clock-names = "larb_sub0", "larb_sub1", "larb_sub2";
> + };
> +
> + larb4:larb@14027000 {
> + compatible = "mediatek,mt8173-smi-larb";
> + reg = <0 0x14027000 0 0x1000>;
> + clocks = <&mmsys MM_SMI_COMMON>, <&mmsys
> MM_SMI_LARB4>;
> + clock-names = "larb_sub0", "larb_sub1";
> + };
> +
> + larb5:larb@19001000 {
> + compatible = "mediatek,mt8173-smi-larb";
> + reg = <0 0x19001000 0 0x1000>;
> + clocks = <&mmsys MM_SMI_COMMON>,
> + <&vencltsys VENCLT_CKE0>,
> + <&vencltsys VENCLT_CKE1>;
> + clock-names = "larb_sub0", "larb_sub1", "larb_sub2";
> + };
> };
>
> };
> diff --git a/include/dt-bindings/iommu/mt8173-iommu-port.h
> b/include/dt-bindings/iommu/mt8173-iommu-port.h
> new file mode 100644
> index 000..e9e6569
> --- /dev/null
> +++ b/include/dt-bindings/iommu/mt8173-iommu-port.h
> @@ -0,0 +1,127 @@
> +/*
> + * Copyright (c) 2014-2015 MediaTek Inc.
> + * Author: Yong Wu
> + *
> + * 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.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for
Re: [PATCH v1 1/6] eeprom: Add a simple EEPROM framework for eeprom providers
On Thu, Mar 05, 2015 at 09:45:41AM +, Srinivas Kandagatla wrote:
> +
> + return eeprom;
> +}
> +EXPORT_SYMBOL(eeprom_register);
This framework uses regmap but regmap is EXPORT_SYMBOL_GPL() and this is
using EXPORT_SYMBOL().
> +int eeprom_unregister(struct eeprom_device *eeprom)
> +{
> + mutex_lock(&eeprom_mutex);
> + if (atomic_read(&eeprom->users)) {
> + mutex_unlock(&eeprom_mutex);
Atomic reads and a mutex - isn't the mutex enough? Atomics are
generally a recipie for bugs due to the complexity in using them.
signature.asc
Description: Digital signature
Re: [PATCH 1/2] regulator: act8865: add input supply handling
On Sat, Mar 07, 2015 at 03:28:54PM +0100, Heiko Stuebner wrote: > The act8846/act8865 regulators have a number of input supplies supplying the > individual regulators. This may even be recursively like on most Rockchip > boards This doesn't apply against current code, please check and resend. signature.asc Description: Digital signature
Re: [PATCH][ASoC]Add DT bindings for generic ASoC AC97 CODEC driver
On Sat, Mar 07, 2015 at 02:58:53PM +0100, Maciej S. Szmigiero wrote: > W dniu 07.03.2015 11:52, Mark Brown pisze: > > On Fri, Mar 06, 2015 at 07:55:26PM +0100, Maciej S. Szmigiero wrote: > > AC'97 shouldn't need DT bindings for the CODEC, it's an enumerable bus. > What this driver did / does is essentially to allow attaching AC'97 bus > to ASoC AC'97 controllers which don't do it on its own (from what I can > see only board files do it). That's true, and it's something it's easy to get away with with board files, but that doesn't mean it's something we should be doing for device tree where we're not just finding an expedient way to load things but rather defining an ABI. > This driver originally constrained rates to 8000, 11025, 22050, 44100, > 48000. > An alternative would be to remove this constraint at all from this > driver and leave such constraining for controller and AC'97 bus code. That's a much better approach. > But since this driver was originally limited to these rates I think it > would be safer to do it only when instantiated via OF. Again, DT is defining an ABI. signature.asc Description: Digital signature
[PATCH 2/2] ARM: dts: rockchip: add input supplies for the act8846 on Radxa Rock
On the Radxa Rock board most supplies come from the static 5v vsys supply, but
the inl1-supply comes from the REG4 of the act8846 itself. Model this dependency
using the added supply-handling to make sure the supplying regulator gets
handled
correctly and not accidentially turned off.
Signed-off-by: Heiko Stuebner
---
I'll apply this one to my dts branch myself, if patch 1/2 is accepted
arch/arm/boot/dts/rk3188-radxarock.dts | 16
1 file changed, 16 insertions(+)
diff --git a/arch/arm/boot/dts/rk3188-radxarock.dts
b/arch/arm/boot/dts/rk3188-radxarock.dts
index 9a09579..bdf8570 100644
--- a/arch/arm/boot/dts/rk3188-radxarock.dts
+++ b/arch/arm/boot/dts/rk3188-radxarock.dts
@@ -103,6 +103,14 @@
regulator-always-on;
regulator-boot-on;
};
+
+ vsys: vsys-regulator {
+ compatible = "regulator-fixed";
+ regulator-name = "vsys";
+ regulator-min-microvolt = <500>;
+ regulator-max-microvolt = <500>;
+ regulator-boot-on;
+ };
};
&emac {
@@ -148,6 +156,14 @@
pinctrl-names = "default";
pinctrl-0 = <&act8846_dvs0_ctl>;
+ vp1-supply = <&vsys>;
+ vp2-supply = <&vsys>;
+ vp3-supply = <&vsys>;
+ vp4-supply = <&vsys>;
+ inl1-supply = <&vcc_io>;
+ inl2-supply = <&vsys>;
+ inl3-supply = <&vsys>;
+
regulators {
vcc_ddr: REG1 {
regulator-name = "VCC_DDR";
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] regulator: act8865: add input supply handling
The act8846/act8865 regulators have a number of input supplies supplying the
individual regulators. This may even be recursively like on most Rockchip boards
using the act8846 where REG4 is most of the time connected to the inl1-supply.
Therefore add the ability to specify the input supplies for the individual
inputs.
The input-names are taken from the datasheets of both act8846 and act8865.
Signed-off-by: Heiko Stuebner
---
.../bindings/regulator/act8865-regulator.txt | 16 +
drivers/regulator/act8865-regulator.c | 41 +++---
2 files changed, 37 insertions(+), 20 deletions(-)
diff --git a/Documentation/devicetree/bindings/regulator/act8865-regulator.txt
b/Documentation/devicetree/bindings/regulator/act8865-regulator.txt
index dad6358..45028bb 100644
--- a/Documentation/devicetree/bindings/regulator/act8865-regulator.txt
+++ b/Documentation/devicetree/bindings/regulator/act8865-regulator.txt
@@ -9,6 +9,22 @@ Optional properties:
- system-power-controller: Telling whether or not this pmic is controlling
the system power. See
Documentation/devicetree/bindings/power/power-controller.txt .
+Optional input supply properties:
+- for act8846:
+ - vp1-supply: The input supply for REG1
+ - vp2-supply: The input supply for REG2
+ - vp3-supply: The input supply for REG3
+ - vp4-supply: The input supply for REG4
+ - inl1-supply: The input supply for REG5, REG6 and REG7
+ - inl2-supply: The input supply for REG8 and LDO_REG9
+ - inl3-supply: The input supply for REG10, REG11 and REG12
+- for act8865:
+ - vp1-supply: The input supply for DCDC_REG1
+ - vp2-supply: The input supply for DCDC_REG2
+ - vp3-supply: The input supply for DCDC_REG3
+ - inl45-supply: The input supply for LDO_REG1 and LDO_REG2
+ - inl67-supply: The input supply for LDO_REG3 and LDO_REG4
+
Any standard regulator properties can be used to configure the single
regulator.
The valid names for regulators are:
diff --git a/drivers/regulator/act8865-regulator.c
b/drivers/regulator/act8865-regulator.c
index 9eec453..a4a85cd 100644
--- a/drivers/regulator/act8865-regulator.c
+++ b/drivers/regulator/act8865-regulator.c
@@ -126,9 +126,10 @@ static struct regulator_ops act8865_ops = {
.is_enabled = regulator_is_enabled_regmap,
};
-#define ACT88xx_REG(_name, _family, _id, _vsel_reg)\
+#define ACT88xx_REG(_name, _family, _id, _vsel_reg, _supply) \
[_family##_ID_##_id] = {\
.name = _name,\
+ .supply_name= _supply, \
.id = _family##_ID_##_id, \
.type = REGULATOR_VOLTAGE,\
.ops= &act8865_ops, \
@@ -143,28 +144,28 @@ static struct regulator_ops act8865_ops = {
}
static const struct regulator_desc act8846_regulators[] = {
- ACT88xx_REG("REG1", ACT8846, REG1, VSET),
- ACT88xx_REG("REG2", ACT8846, REG2, VSET0),
- ACT88xx_REG("REG3", ACT8846, REG3, VSET0),
- ACT88xx_REG("REG4", ACT8846, REG4, VSET0),
- ACT88xx_REG("REG5", ACT8846, REG5, VSET),
- ACT88xx_REG("REG6", ACT8846, REG6, VSET),
- ACT88xx_REG("REG7", ACT8846, REG7, VSET),
- ACT88xx_REG("REG8", ACT8846, REG8, VSET),
- ACT88xx_REG("REG9", ACT8846, REG9, VSET),
- ACT88xx_REG("REG10", ACT8846, REG10, VSET),
- ACT88xx_REG("REG11", ACT8846, REG11, VSET),
- ACT88xx_REG("REG12", ACT8846, REG12, VSET),
+ ACT88xx_REG("REG1", ACT8846, REG1, VSET, "vp1"),
+ ACT88xx_REG("REG2", ACT8846, REG2, VSET0, "vp2"),
+ ACT88xx_REG("REG3", ACT8846, REG3, VSET0, "vp3"),
+ ACT88xx_REG("REG4", ACT8846, REG4, VSET0, "vp4"),
+ ACT88xx_REG("REG5", ACT8846, REG5, VSET, "inl1"),
+ ACT88xx_REG("REG6", ACT8846, REG6, VSET, "inl1"),
+ ACT88xx_REG("REG7", ACT8846, REG7, VSET, "inl1"),
+ ACT88xx_REG("REG8", ACT8846, REG8, VSET, "inl2"),
+ ACT88xx_REG("REG9", ACT8846, REG9, VSET, "inl2"),
+ ACT88xx_REG("REG10", ACT8846, REG10, VSET, "inl3"),
+ ACT88xx_REG("REG11", ACT8846, REG11, VSET, "inl3"),
+ ACT88xx_REG("REG12", ACT8846, REG12, VSET, "inl3"),
};
static const struct regulator_desc act8865_regulators[] = {
- ACT88xx_REG("DCDC_REG1", ACT8865, DCDC1, VSET1),
- ACT88xx_REG("DCDC_REG2", ACT8865, DCDC2, VSET1),
- ACT88xx_REG("DCDC_REG3", ACT8865, DCDC3, VSET1),
- ACT88xx_REG("LDO_REG1", ACT8865, LDO1, VSET),
- ACT88xx_REG("LDO_REG2", ACT8865, LDO2, VSET),
- ACT88xx_REG("LDO_REG3", ACT8865, LDO3, VSET),
- ACT88xx_REG("LDO_REG4", ACT8865, LDO4, VSET),
+ ACT88xx_REG("DCDC_REG1", ACT8865, DCDC1, VSET1, "vp1"),
+ ACT88xx_REG("DCDC_REG2", ACT8865, DCDC2, VSET1, "vp2"),
+ ACT88xx_REG("DCDC_REG3", ACT8865, DCDC3, VS
Re: [PATCH][ASoC]Add DT bindings for generic ASoC AC97 CODEC driver
Thanks for looking into the patch. W dniu 07.03.2015 11:52, Mark Brown pisze: > On Fri, Mar 06, 2015 at 07:55:26PM +0100, Maciej S. Szmigiero wrote: > >> Add and document DT bindings for generic ASoC AC97 CODEC driver, >> make it selectable in config. > > AC'97 shouldn't need DT bindings for the CODEC, it's an enumerable bus. What this driver did / does is essentially to allow attaching AC'97 bus to ASoC AC'97 controllers which don't do it on its own (from what I can see only board files do it). > >> + - playback-rates : A list of supported playback rates. >> + >> + - capture-rates : A list of supported capture rates. > > Why would we need these properties - the sample rate support is defined > by the standard, and any extensions can be enumerated from the device. This driver originally constrained rates to 8000, 11025, 22050, 44100, 48000. An alternative would be to remove this constraint at all from this driver and leave such constraining for controller and AC'97 bus code. But since this driver was originally limited to these rates I think it would be safer to do it only when instantiated via OF. Best regards, Maciej Szmigiero -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] mtd: nand: add NAND driver for Broadcom STB NAND controller
On 7 March 2015 at 02:18, Brian Norris wrote: > + /* NAND register range */ > + res = platform_get_resource(pdev, IORESOURCE_MEM, 0); > + ctrl->nand_base = devm_ioremap_resource(dev, res); > + if (!ctrl->nand_base) > + return -ENODEV; This is what I got during my first test: brcmstb_nand 11315e0.nand: can't request region for resource [mem 0x011315e0-0x011325df] Unable to handle kernel paging request at virtual address fff0 (not sure why yet). Hint: devm_ioremap_resource does never return NULL -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC PATCH] dts: Add am335x-wega-rdk.dtb sources for phyBOARD-Wega-AM335x
The following patch is to support Phytec phyBOARD-Wega-AM335x device.
The patch consists of the commits taken from
git://git.phytec.de/linux-ti
and ported to upstream kernel with small modifications,
i.e. &ctrl_mod renamed to &usb_ctrl_mod.
The code has been written by the following developers:
Christian Arlt
Stefan Müller-Klieser
Teresa Gámez
Wadim Egorov
Tested-by: Matwey V. Kornilov
Signed-off-by: Matwey V. Kornilov
---
The patch has been tested on 3.19.0 with openSUSE Factory on
phyBOARD-Wega-AM335x kit. The board successfully boots, ethernet works.
arch/arm/boot/dts/Makefile | 3 +-
arch/arm/boot/dts/am335x-phycore-som.dtsi | 275 +
arch/arm/boot/dts/am335x-phytec-lcd-018.dtsi | 109 ++
arch/arm/boot/dts/am335x-wega-peb-av-01.dtsi | 71 +++
arch/arm/boot/dts/am335x-wega-peb-av-02.dtsi | 44
arch/arm/boot/dts/am335x-wega-peb-eval-01.dtsi | 54 +
arch/arm/boot/dts/am335x-wega-rdk.dts | 136
arch/arm/boot/dts/am335x-wega.dtsi | 209 +++
8 files changed, 900 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/boot/dts/am335x-phycore-som.dtsi
create mode 100644 arch/arm/boot/dts/am335x-phytec-lcd-018.dtsi
create mode 100644 arch/arm/boot/dts/am335x-wega-peb-av-01.dtsi
create mode 100644 arch/arm/boot/dts/am335x-wega-peb-av-02.dtsi
create mode 100644 arch/arm/boot/dts/am335x-wega-peb-eval-01.dtsi
create mode 100644 arch/arm/boot/dts/am335x-wega-rdk.dts
create mode 100644 arch/arm/boot/dts/am335x-wega.dtsi
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index a1c776b..aa05ae4 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -401,7 +401,8 @@ dtb-$(CONFIG_SOC_AM33XX) += \
am335x-evmsk.dtb \
am335x-nano.dtb \
am335x-pepper.dtb \
- am335x-lxm.dtb
+ am335x-lxm.dtb \
+ am335x-wega-rdk.dts
dtb-$(CONFIG_ARCH_OMAP4) += \
omap4-duovero-parlor.dtb \
omap4-panda.dtb \
diff --git a/arch/arm/boot/dts/am335x-phycore-som.dtsi
b/arch/arm/boot/dts/am335x-phycore-som.dtsi
new file mode 100644
index 000..aa7826d
--- /dev/null
+++ b/arch/arm/boot/dts/am335x-phycore-som.dtsi
@@ -0,0 +1,275 @@
+/*
+ * Copyright (C) 2014 Teresa Gámez Phytec Messtechnik GmbH
+ *
+ * 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 "am33xx.dtsi"
+
+/ {
+ model = "Phytec AM335x phyCORE";
+ compatible = "phytec,am335x-phycore-som", "ti,am33xx";
+
+ aliases {
+ rtc0 = &i2c_rtc;
+ rtc1 = &rtc;
+ };
+
+ cpus {
+ cpu@0 {
+ cpu0-supply = <&vdd1_reg>;
+ };
+ };
+
+ /* This is a dummy node. Will be set by a bootloader */
+ memory {
+ device_type = "memory";
+ reg = <0x8000 0x2000>; /* 512 MB */
+ };
+
+ vcc5v: fixedregulator@0 {
+ compatible = "regulator-fixed";
+ };
+};
+
+/* Crypto Module */
+&aes {
+ status = "okay";
+};
+
+&sham {
+ status = "okay";
+};
+
+/* Ethernet */
+&am33xx_pinmux {
+ ethernet0_pins: pinmux_ethernet0 {
+ pinctrl-single,pins = <
+ 0x10c (PIN_INPUT_PULLDOWN | MUX_MODE1) /*
mii1_crs.rmii1_crs_dv */
+ 0x110 (PIN_INPUT_PULLDOWN | MUX_MODE1) /*
mii1_rxerr.rmii1_rxerr */
+ 0x114 (PIN_OUTPUT | MUX_MODE1) /*
mii1_txen.rmii1_txen */
+ 0x124 (PIN_OUTPUT | MUX_MODE1) /*
mii1_txd1.rmii1_txd1 */
+ 0x128 (PIN_OUTPUT | MUX_MODE1) /*
mii1_txd0.rmii1_txd0 */
+ 0x13c (PIN_INPUT_PULLDOWN | MUX_MODE1) /*
mii1_rxd1.rmii1_rxd1 */
+ 0x140 (PIN_INPUT_PULLDOWN | MUX_MODE1) /*
mii1_rxd0.rmii1_rxd0 */
+ 0x144 (PIN_INPUT_PULLDOWN | MUX_MODE0) /*
rmii1_refclk.rmii1_refclk */
+ >;
+ };
+
+ mdio_pins: pinmux_mdio {
+ pinctrl-single,pins = <
+ /* MDIO */
+ 0x148 (PIN_INPUT_PULLUP | SLEWCTRL_FAST | MUX_MODE0)
/* mdio_data.mdio_data */
+ 0x14c (PIN_OUTPUT_PULLUP | MUX_MODE0)
/* mdio_clk.mdio_clk */
+ >;
+ };
+};
+
+&cpsw_emac0 {
+ phy_id = <&davinci_mdio>, <0>;
+ phy-mode = "rmii";
+ dual_emac_res_vlan = <1>;
+ status = "disabled";
+};
+
+&cpsw_emac1 {
+ status = "disabled";
+};
+
+&davinci_mdio {
+ pinctrl-names = "default";
+ pinctrl-0 = <&mdio_pins>;
+ status = "disabled";
+};
+
+&mac {
+ slaves = <1>;
+ pinctrl-names = "default";
+ pinctrl-0 = <ðernet0_pins>;
+};
+
+&phy_sel {
+
Re: [PATCH 3/3] mtd: nand: add NAND driver for Broadcom STB NAND controller
Only a license nit.
Brian Norris schreef op vr 06-03-2015 om 17:18 [-0800]:
> --- /dev/null
> +++ b/drivers/mtd/nand/brcmstb_nand.c
> @@ -0,0 +1,2182 @@
> +/*
> + * Copyright © 2010-2015 Broadcom Corporation
> + *
> + * 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.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + */
This states the license is GPL v2.
> +MODULE_LICENSE("GPL");
So you probably want
MODULE_LICENSE("GPL v2");
here.
Paul Bolle
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
