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 linux-omap" 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 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: [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 linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: twl4030_charger: need changes to get probed?
Hi, On Fri, Mar 06, 2015 at 10:24:17PM +0100, Pavel Machek wrote: > According to n900 dts, twl4030-bci (aka charger) should be > included. its part of twl, but not used on N900 afaik. > (But it does not seem to do anything useful on n900. I was hoping for > measurement of input voltage, but .. no.) check for rx51-battery. > Any ideas why the patch below is needed? platform_driver_probe() does not support deferred probing. Neil, can you take this patch into your series for the next round? -- Sebastian > Signed-off-by: Pavel Machek > > diff --git a/drivers/power/twl4030_charger.c b/drivers/power/twl4030_charger.c > index d35b83e..96bbbe9 100644 > --- a/drivers/power/twl4030_charger.c > +++ b/drivers/power/twl4030_charger.c > @@ -714,6 +722,7 @@ static const struct of_device_id twl_bci_of_match[] = { > MODULE_DEVICE_TABLE(of, twl_bci_of_match); > > static struct platform_driver twl4030_bci_driver = { > + .probe = twl4030_bci_probe, > .driver = { > .name = "twl4030_bci", > .of_match_table = of_match_ptr(twl_bci_of_match), > @@ -721,7 +730,7 @@ static struct platform_driver twl4030_bci_driver = { > .remove = __exit_p(twl4030_bci_remove), > }; > > -module_platform_driver_probe(twl4030_bci_driver, twl4030_bci_probe); > +module_platform_driver(twl4030_bci_driver); > > MODULE_AUTHOR("Gražvydas Ignotas"); > MODULE_DESCRIPTION("TWL4030 Battery Charger Interface driver"); signature.asc Description: Digital signature
Re: [PATCH 09/15] twl4030_charger: allow max_current to be managed via sysfs.
Hi, On Thu, Mar 05, 2015 at 05:26:00PM +1100, NeilBrown wrote: > [...] > +What: /sys/class/power_supply/twl4030_ac/max_current > + /sys/class/power_supply/twl4030_usb/max_current > +Description: > + Read/Write limit on current which which may > + be drawn from the ac (Accessory Charger) or > + USB port. > + > + Value is in micro-Amps. > + > + Value is set automatically to an appropriate > + value when a cable is plugged on unplugged. ^^ s/on/or -- Sebastian signature.asc Description: Digital signature
Re: [PATCH 07/15] twl4030_charger: allow fine control of charger current.
Hi Pavel, On Wed, Mar 04, 2015 at 11:24:15AM +0100, Pavel Machek wrote: > (Now I'd need to study the datasheets... and figure out how to enable > this on N900). The N900 uses bq24150a for charging ;) -- Sebastian signature.asc Description: Digital signature
Re: [PATCH 03/15] twl4030_charger: use devres for power_supply_register and kzalloc.
Hi, On Tue, Feb 24, 2015 at 03:33:50PM +1100, NeilBrown wrote: > [...] > @@ -667,13 +667,6 @@ static int __init twl4030_bci_probe(struct > platform_device *pdev) > return 0; > > fail: > - power_supply_unregister(&bci->usb); > -fail_register_usb: > - power_supply_unregister(&bci->ac); > -fail_register_ac: > -fail_no_battery: > - kfree(bci); > - > return ret; > } Please replace "goto fail" with "return ret", goto is no longer needed. -- Sebastian signature.asc Description: Digital signature
Re: twl4030_charger: need changes to get probed?
On Saturday 07 March 2015 16:56:01 Grazvydas Ignotas wrote: > N900's old board files specify 5030, but .dts does not. I would guess this is bug and DTS file needs to be fixed. -- Pali Rohár pali.ro...@gmail.com signature.asc Description: This is a digitally signed message part.
Re: twl4030_charger: need changes to get probed?
On Sat, Mar 7, 2015 at 12:56 AM, Pali Rohár wrote: > On Friday 06 March 2015 23:40:34 Pavel Machek wrote: >> On Sat 2015-03-07 00:12:07, Grazvydas Ignotas wrote: >> > On Fri, Mar 6, 2015 at 11:57 PM, Pali Rohár >> > wrote: >> > > On Friday 06 March 2015 22:24:17 Pavel Machek wrote: >> > >> Hi! >> > >> >> > >> According to n900 dts, twl4030-bci (aka charger) should >> > >> be included. >> > > >> > > AFAIK it is not present on n900... >> > >> > Right, it uses twl5030 variant without the charger, charging >> > on n900 is provided by separate chip and for a good reason >> > as twl's charger is not that good. Forcing the driver to >> > load just ends up with it accessing non-existent registers >> > over i2c. >> >> Ok, but: >> >> 1) Why is the twl4030-bci enabled in n900's dts, then >> > > maybe it is bug in n900 dts... > > Grazvydas, is there some runtime check if twl4030/twl5030 chip > has charger or not? or do we need to explicitly disable device > twl4030-bci in DT? Actually from looking at the schematics, it looks like the charger pins are still there but all connected to ground. So it probably has the charger after all, it's just not connected or used. I'm not aware or any registers for direct detection, and indirect detection is difficult because BCI mostly disables itself when no charger is connected and most registers read as 0 or have old values from last charging session (which will never happen on n900). There is IDCODE register on twl4030 itself, but it's documented as not meaningful when accessed over i2c (when is it meaningful then??). drivers/mfd/twl-core.c has a i2c_device_id table of various twl4030 variants, some of which have no charger. N900 has GAIA/twl5030, which differs from twl4030 only by vaux2 regulator according to that file. N900's old board files specify 5030, but .dts does not. Gražvydas -- To unsubscribe from this list: send the line "unsubscribe linux-omap" 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 { +