* [PATCH v4 07/10] ARM: dts: Add camera to node exynos4.dtsi
From: Sylwester Nawrocki @ 2013-02-01 19:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359745771-23684-1-git-send-email-s.nawrocki@samsung.com>
This patch adds common FIMC device nodes for all Exynos4 SoCs.
Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
---
arch/arm/boot/dts/exynos4.dtsi | 64 ++++++++++++++++++++++++++++++++++++++++
1 file changed, 64 insertions(+)
diff --git a/arch/arm/boot/dts/exynos4.dtsi b/arch/arm/boot/dts/exynos4.dtsi
index e1347fc..75c388b 100644
--- a/arch/arm/boot/dts/exynos4.dtsi
+++ b/arch/arm/boot/dts/exynos4.dtsi
@@ -36,6 +36,12 @@
i2c5 = &i2c_5;
i2c6 = &i2c_6;
i2c7 = &i2c_7;
+ csis0 = &csis_0;
+ csis1 = &csis_1;
+ fimc0 = &fimc_0;
+ fimc1 = &fimc_1;
+ fimc2 = &fimc_2;
+ fimc3 = &fimc_3;
};
pd_mfc: mfc-power-domain at 10023C40 {
@@ -82,6 +88,64 @@
reg = <0x10440000 0x1000>;
};
+ camera {
+ compatible = "samsung,fimc", "simple-bus";
+ status = "disabled";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ fimc_0: fimc at 11800000 {
+ compatible = "samsung,exynos4210-fimc";
+ reg = <0x11800000 0x1000>;
+ interrupts = <0 84 0>;
+ samsung,power-domain = <&pd_cam>;
+ status = "disabled";
+ };
+
+ fimc_1: fimc at 11810000 {
+ compatible = "samsung,exynos4210-fimc";
+ reg = <0x11810000 0x1000>;
+ interrupts = <0 85 0>;
+ samsung,power-domain = <&pd_cam>;
+ status = "disabled";
+ };
+
+ fimc_2: fimc at 11820000 {
+ compatible = "samsung,exynos4210-fimc";
+ reg = <0x11820000 0x1000>;
+ interrupts = <0 86 0>;
+ samsung,power-domain = <&pd_cam>;
+ status = "disabled";
+ };
+
+ fimc_3: fimc at 11830000 {
+ compatible = "samsung,exynos4210-fimc";
+ reg = <0x11830000 0x1000>;
+ interrupts = <0 87 0>;
+ samsung,power-domain = <&pd_cam>;
+ status = "disabled";
+ };
+
+ csis_0: csis at 11880000 {
+ compatible = "samsung,exynos4210-csis";
+ reg = <0x11880000 0x4000>;
+ interrupts = <0 78 0>;
+ bus-width = <4>;
+ samsung,power-domain = <&pd_cam>;
+ status = "disabled";
+ };
+
+ csis_1: csis at 11890000 {
+ compatible = "samsung,exynos4210-csis";
+ reg = <0x11890000 0x4000>;
+ interrupts = <0 80 0>;
+ bus-width = <2>;
+ samsung,power-domain = <&pd_cam>;
+ status = "disabled";
+ };
+ };
+
watchdog at 10060000 {
compatible = "samsung,s3c2410-wdt";
reg = <0x10060000 0x100>;
--
1.7.9.5
^ permalink raw reply related
* [PATCH v4 08/10] ARM: dts: Add ISP power domain node for Exynos4x12
From: Sylwester Nawrocki @ 2013-02-01 19:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359745771-23684-1-git-send-email-s.nawrocki@samsung.com>
The ISP power domain is a common power domain for fimc-lite
and fimc-is (ISP) devices.
Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
---
arch/arm/boot/dts/exynos4x12.dtsi | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/exynos4x12.dtsi b/arch/arm/boot/dts/exynos4x12.dtsi
index 179a62e..9c809b72 100644
--- a/arch/arm/boot/dts/exynos4x12.dtsi
+++ b/arch/arm/boot/dts/exynos4x12.dtsi
@@ -28,6 +28,11 @@
pinctrl3 = &pinctrl_3;
};
+ pd_isp: isp-power-domain at 10023CA0 {
+ compatible = "samsung,exynos4210-pd";
+ reg = <0x10023CA0 0x20>;
+ };
+
combiner:interrupt-controller at 10440000 {
interrupts = <0 0 0>, <0 1 0>, <0 2 0>, <0 3 0>,
<0 4 0>, <0 5 0>, <0 6 0>, <0 7 0>,
--
1.7.9.5
^ permalink raw reply related
* [PATCH v4 09/10] ARM: dts: Add FIMC and MIPI CSIS device nodes for Exynos4x12
From: Sylwester Nawrocki @ 2013-02-01 19:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359745771-23684-1-git-send-email-s.nawrocki@samsung.com>
Add common camera node and fimc nodes specific to Exynos4212 and
Exynos4412 SoCs. fimc-is is a node for the Exynos4x12 FIMC-IS
subsystem and fimc-lite nodes are created as its child nodes,
among others due to FIMC-LITE device dependencies on FIMC-IS
related clocks.
Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
---
arch/arm/boot/dts/exynos4x12.dtsi | 47 +++++++++++++++++++++++++++++++++++++
1 file changed, 47 insertions(+)
diff --git a/arch/arm/boot/dts/exynos4x12.dtsi b/arch/arm/boot/dts/exynos4x12.dtsi
index 9c809b72..59b2b8e 100644
--- a/arch/arm/boot/dts/exynos4x12.dtsi
+++ b/arch/arm/boot/dts/exynos4x12.dtsi
@@ -26,6 +26,8 @@
pinctrl1 = &pinctrl_1;
pinctrl2 = &pinctrl_2;
pinctrl3 = &pinctrl_3;
+ fimc-lite0 = &fimc_lite_0;
+ fimc-lite1 = &fimc_lite_1;
};
pd_isp: isp-power-domain at 10023CA0 {
@@ -71,4 +73,49 @@
reg = <0x106E0000 0x1000>;
interrupts = <0 72 0>;
};
+
+ camera {
+ fimc_0: fimc at 11800000 {
+ compatible = "samsung,exynos4212-fimc";
+ };
+
+ fimc_1: fimc at 11810000 {
+ compatible = "samsung,exynos4212-fimc";
+ };
+
+ fimc_2: fimc at 11820000 {
+ compatible = "samsung,exynos4212-fimc";
+ };
+
+ fimc_3: fimc at 11830000 {
+ compatible = "samsung,exynos4212-fimc";
+ };
+
+ fimc_is: fimc-is at 12000000 {
+ compatible = "samsung,exynos4212-fimc-is", "simple-bus";
+ reg = <0x12000000 0x260000>;
+ interrupts = <0 90 0>, <0 95 0>;
+ samsung,power-domain = <&pd_isp>;
+ status = "disabled";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ fimc_lite_0: fimc-lite at 12390000 {
+ compatible = "samsung,exynos4212-fimc-lite";
+ reg = <0x12390000 0x1000>;
+ interrupts = <0 105 0>;
+ samsung,power-domain = <&pd_isp>;
+ status = "disabled";
+ };
+
+ fimc_lite_1: fimc-lite at 123A0000 {
+ compatible = "samsung,exynos4212-fimc-lite";
+ reg = <0x123A0000 0x1000>;
+ interrupts = <0 106 0>;
+ samsung,power-domain = <&pd_isp>;
+ status = "disabled";
+ };
+ };
+ };
};
--
1.7.9.5
^ permalink raw reply related
* [PATCH v4 10/10] ARM: dts: Correct camera pinctrl nodes for Exynos4x12 SoCs
From: Sylwester Nawrocki @ 2013-02-01 19:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359745771-23684-1-git-send-email-s.nawrocki@samsung.com>
Add separate nodes for the CAMCLK pin and turn off pull-up on camera
ports A, B. The video bus pins and the clock output (CAMCLK) pin need
separate nodes since full camera port is not used in some configurations,
e.g. for MIPI CSI-2 bus on CAMCLK is required and data/clock signal
use separate dedicated pins.
Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Changes since v3:
- corrected camera port B part and removed entries for
"inactive" state
---
arch/arm/boot/dts/exynos4x12-pinctrl.dtsi | 26 +++++++++++++++++++-------
1 file changed, 19 insertions(+), 7 deletions(-)
diff --git a/arch/arm/boot/dts/exynos4x12-pinctrl.dtsi b/arch/arm/boot/dts/exynos4x12-pinctrl.dtsi
index 8e6115a..4c3a2c3 100644
--- a/arch/arm/boot/dts/exynos4x12-pinctrl.dtsi
+++ b/arch/arm/boot/dts/exynos4x12-pinctrl.dtsi
@@ -401,15 +401,21 @@
samsung,pin-drv = <0>;
};
- cam_port_a: cam-port-a {
+ cam_port_a_io: cam-port-a-io {
samsung,pins = "gpj0-0", "gpj0-1", "gpj0-2", "gpj0-3",
"gpj0-4", "gpj0-5", "gpj0-6", "gpj0-7",
- "gpj1-0", "gpj1-1", "gpj1-2", "gpj1-3",
- "gpj1-4";
+ "gpj1-0", "gpj1-1", "gpj1-2", "gpj1-4";
samsung,pin-function = <2>;
- samsung,pin-pud = <3>;
+ samsung,pin-pud = <0>;
samsung,pin-drv = <0>;
};
+
+ cam_port_a_clk_active: cam-port-a-clk-active {
+ samsung,pins = "gpj1-3";
+ samsung,pin-function = <2>;
+ samsung,pin-pud = <0>;
+ samsung,pin-drv = <3>;
+ };
};
pinctrl at 11000000 {
@@ -834,16 +840,22 @@
samsung,pin-drv = <0>;
};
- cam_port_b: cam-port-b {
+ cam_port_b_io: cam-port-b-io {
samsung,pins = "gpm0-0", "gpm0-1", "gpm0-2", "gpm0-3",
"gpm0-4", "gpm0-5", "gpm0-6", "gpm0-7",
- "gpm1-0", "gpm1-1", "gpm2-0", "gpm2-1",
- "gpm2-2";
+ "gpm1-0", "gpm1-1", "gpm2-0", "gpm2-1";
samsung,pin-function = <3>;
samsung,pin-pud = <3>;
samsung,pin-drv = <0>;
};
+ cam_port_b_clk_active: cam-port-b-clk-active {
+ samsung,pins = "gpm2-2";
+ samsung,pin-function = <3>;
+ samsung,pin-pud = <0>;
+ samsung,pin-drv = <3>;
+ };
+
eint0: ext-int0 {
samsung,pins = "gpx0-0";
samsung,pin-function = <0xf>;
--
1.7.9.5
^ permalink raw reply related
* [PATCH v4 4/4] drivers: usb: start using the control module driver
From: Tony Lindgren @ 2013-02-01 19:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130125102700.GO15886@arwen.pp.htv.fi>
* Felipe Balbi <balbi@ti.com> [130125 02:30]:
> Hi,
>
> On Fri, Jan 25, 2013 at 03:54:00PM +0530, Kishon Vijay Abraham I wrote:
> > Start using the control module driver for powering on the PHY and for
> > writing to the mailbox instead of writing to the control module
> > registers on their own.
> >
> > Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
> > ---
> > Documentation/devicetree/bindings/usb/omap-usb.txt | 4 ++
> > Documentation/devicetree/bindings/usb/usb-phy.txt | 7 +-
> > arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 13 ----
>
> I'm taking this patch but I'm leaving out the omap_hwmod_44xx_data.c
> change just to kill dependency. Can you send that single change as a
> separate patch which Tony can queue ?
For the USB patches, please also leave out patches touching
arch/arm/mach-omap2/devices.c. Those are almost guaranteed to
cause pointless merge conflicts with other branches.
I suggest you set up few immutable branches:
1. Minimal platform_data changes for all your USB changes
This should contain include/linux/platform_data changes and
changes to arch/arm/*omap* so me and Paul can merge it in too
to avoid merge conflicts.
2. The rest of the driver/usb changes
This can then be based on #1 branch above.
3. Changes for the .dts files for Benoit
These can be queued separately from #1 and #2 above.
Regards,
Tony
^ permalink raw reply
* [PATCH v2 2/4] ARM: OMAP: devices: create device for usb part of control module
From: Tony Lindgren @ 2013-02-01 19:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130123112422.GF29258@arwen.pp.htv.fi>
* Felipe Balbi <balbi@ti.com> [130123 03:27]:
> Hi,
>
> On Mon, Jan 21, 2013 at 07:38:26PM +0530, Kishon Vijay Abraham I wrote:
> > A seperate driver has been added to handle the usb part of control
> > module. A device for the above driver is created here, using the register
> > address information to be used by the driver for powering on the PHY and
> > for writing to the mailbox.
> >
> > Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
>
> Tony ? Without this we won't have the control module driver.
Looks OK to me, but please see my other reply regarding on
you setting up some immutable branches to avoid pointless
merge conflicts.
Regards,
Tony
^ permalink raw reply
* [PATCH v2 3/6] ARM: OMAP: USB: Add phy binding information
From: Tony Lindgren @ 2013-02-01 19:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359081206-5602-4-git-send-email-kishon@ti.com>
* Kishon Vijay Abraham I <kishon@ti.com> [130124 18:36]:
> This is w.r.t the changes in PHY library to support adding and getting
> multiple PHYs of the same type. In the new design, the
> binding information between the PHY and the USB controller should be
> specified in the platform specific initialization code. So it's been
> done here for OMAP platforms.
This looks OK to me, but should be queued by Felipe in his
minimal USB platform_data changes branch that I can pull in too
to avoid pointless merge conflicts.
Regards,
Tony
^ permalink raw reply
* [PATCH v2 19/27] pci: PCIe driver for Marvell Armada 370/XP systems
From: Jason Gunthorpe @ 2013-02-01 19:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <510C0200.5040505@wwwdotorg.org>
On Fri, Feb 01, 2013 at 10:57:20AM -0700, Stephen Warren wrote:
> > We have 20 windows on Armada XP if I remember correctly, and they are
> > not only used for PCIe, but also to map the BootROM (needed to boot
> > secondary CPUs), to map SPI flashes or NOR flashes, for example. So
> > they are really shared between many uses. In terms of PCIe, there are
> > only two types of windows: I/O and Memory, there is no notion of
> > Prefetchable Memory window as far as I could see.
>
> In Tegra, we end up having separate MMIO vs. Prefetchable MMIO
> chunks of our overall PCIe aperture. However, the HW setup appears
> the same for both of those. I'm not sure if it's a bug in the
> driver, or if it's just to separate the two address spaces so that
> the page tables can be configured for those two regions with large
> rather than small granularity. I need to go investigate that.
The only purpose of prefetchable space is for legacy PCI. When a P2P
bridge targets legacy PCI it has different behavior for its
prefetchable memory window compared to the non-prefetchable memory
window.
IIRC (though it has been a long time since I looked really close at
this) PCI-X and PCI-E did away with this special bridge behaviour but
kept the prefetchable memory space for compatibility.
These days it is typically used to mark cachable memory on an end
device.
>From a SOC perspective, there is no need to treat MMIO and prefetch
areas any differently. ARM's per-page cachability flags can be used to
deal with the differing caching requirements.
However, the bus tree downstream of each root port will require the
prefetch window to be contiguous. On Marvell, today, this means you
need to burn two mbus windows to get this. If the Linux pci core could
allocate the prefetch space for each root port bridge contiguously
with the mmio space for the same root port then this could be reduced
to one window covering both spaces for the port.
> So there are 10 PCIe interfaces (root ports). That's on the SoC itself
> right. Are all 10 (or a large number of them) actually used at once on
> any given board design? I suppose this must be the case, or Marvell
> wouldn't have wasted the silicon space on 10 root ports... Still, that's
> a rather large number of ports!
Agreed.. I have no idea what the target is for this..
> I think the only difference on the Marvell HW is:
>
> * The overall total size of the physical address space is dynamic rather
> than fixed, because it's programmed through windows rather than
> hard-coded into HW.
Is it hard coded on tegra? I thought there was a register set that was
used to set the overall PCI-E MMIO window location and size. I know
even on x86 the PCI window is set via register, though that typically
isn't disclosed except to bios writers..
Jason
^ permalink raw reply
* [PATCH v5 04/10] clk: tegra: Add new fields and PLL types for Tegra114
From: Rhyland Klein @ 2013-02-01 19:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359713962-16822-5-git-send-email-pdeschrijver@nvidia.com>
On 2/1/2013 5:18 AM, Peter De Schrijver wrote:
> Tegra114 introduces new PLL types. This requires new clocktypes as well
> as some new fields in the pll structure.
>
> Signed-off-by: Peter De Schrijver <pdeschrijver@nvidia.com>
> ---
> drivers/clk/tegra/clk-pll.c | 719 +++++++++++++++++++++++++++++++++++++++++++
> drivers/clk/tegra/clk.h | 47 +++
> 2 files changed, 766 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/clk/tegra/clk-pll.c b/drivers/clk/tegra/clk-pll.c
> index 87d2f34..50114b7 100644
> --- a/drivers/clk/tegra/clk-pll.c
> +++ b/drivers/clk/tegra/clk-pll.c
> [snip]
> +struct clk *tegra_clk_register_pllxc(const char *name, const char *parent_name,
> + void __iomem *clk_base, void __iomem *pmc,
> + unsigned long flags, unsigned long fixed_rate,
> + struct tegra_clk_pll_params *pll_params,
> + u32 pll_flags,
> + struct tegra_clk_pll_freq_table *freq_table,
> + spinlock_t *lock)
> +{
> + if (!pll_params->pdiv_tohw)
> + return -EINVAL;
> +
This will cause the following warning:
warning: return makes pointer from integer without a cast
Same with occurrences in tegra_clk_register_pllm and
tegra_clk_register_pllc.
Should this instead be returning NULL?
-rhyland
--
nvpublic
^ permalink raw reply
* [PATCH v2 19/27] pci: PCIe driver for Marvell Armada 370/XP systems
From: Jason Gunthorpe @ 2013-02-01 19:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201302011130.18442.arnd@arndb.de>
On Fri, Feb 01, 2013 at 11:30:18AM +0000, Arnd Bergmann wrote:
> IO Resources are always expressed in the kernel's view, so they are
> in the range from 0 to IO_SPACE_LIMIT. The idea is that you can have
> multiple buses that each have their own address space start at 0,
> but can put them into the kernel address space at a different
> address.
Sure, I see that.. and that seems reasonable as long as any IO bus
address aliases are put in separate PCI domains. It would be wonky if
devices on different PCI bus numbers in a single PCI domain had
overlaping IO addresses.
> > No, for *all* links. You use a mmap scheme with 4k granularity, I
> > explained in a past email, but to quickly review..
> >
> > - Each link gets 64k of reserved physical address space for IO,
> > this is just set aside, no MBUS windows are permantently assigned.
> > - Linux is told to use a 64k IO range with bus IO address 0->0xFFFF
> > - When the IO base/limit register in the link PCI-PCI bridge is programmed
> > the driver gets a 4k aligned region somewhere from 0->0xFFFF and then:
> > - Allocates a 64k MBUS window that translates physical address
> > 0xZZZZxxxx to IO bus address 0x0000xxxx (goes in the TLP) for
> > that link
> > - Uses pci_ioremap_io to map the fraction of the link's 64k MBUS window
> > allocated to that bridge to the correct offset in the
> > PCI_IO_VIRT_BASE region
>
> We'd have to change pci_ioremap_io to allow mapping less than 64k, but
> yes, that would work, too. I don't see an advantage to it though,
> other than having io_offset always be zero.
Erm, that is the whole point. No PCI device in the system, on any of
the 10 links, would be required to use a 32 bit IO address. All are 16
bit and there is no compatibility problem on any links. You don't need
to declare any one link as being 'io supporting' or something like
that, it just works out of the box.
Jason
^ permalink raw reply
* [PATCH v7 01/10] ARM: davinci: move private EDMA API to arm/common
From: Sergei Shtylyov @ 2013-02-01 19:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130201184915.GP2244@beef>
Hello.
On 02/01/2013 09:49 PM, Matt Porter wrote:
>>> Move mach-davinci/dma.c to common/edma.c so it can be used
>>> by OMAP (specifically AM33xx) as well.
>> I think this should rather go to drivers/dma/?
> No, this is the private EDMA API. It's the analogous thing to
> the private OMAP dma API that is in plat-omap/dma.c. The actual
> dmaengine driver is in drivers/dma/edma.c as a wrapper around
> this...same way OMAP DMA engine conversion is being done.
Keeps me wondering why we couldn't have the same with CPPI 4.1 when I proposed
that, instead of waiting indefinitely for TI to convert it to drivers/dma/
directly. We could have working MUSB DMA on OMAP-L1x/Sitara all this time... Sigh.
> -Matt
WBR, Sergei
^ permalink raw reply
* [PATCH v2 19/27] pci: PCIe driver for Marvell Armada 370/XP systems
From: Jason Gunthorpe @ 2013-02-01 19:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201302011745.29223.arnd@arndb.de>
On Fri, Feb 01, 2013 at 05:45:29PM +0000, Arnd Bergmann wrote:
> Yes, that was my point. I think in this case, the bug is in the new
> of_pci_process_ranges functions, which returns a 'struct resource'
> translated into IORESOURCE_MEM space, but with the type set
> to IORESOURCE_IO. This resource then gets passed to
> pci_add_resource_offset().
A standard way to express the required address translation from CPU
physical address to IO bus address might help other people avoid this
trap??
Jason
^ permalink raw reply
* [PATCH 00/15] OMAP SHAM & AES Crypto Updates
From: Mark A. Greer @ 2013-02-01 20:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.DEB.2.00.1302011722070.10853@utopia.booyaka.com>
On Fri, Feb 01, 2013 at 05:35:05PM +0000, Paul Walmsley wrote:
> Hi Mark
>
> On Mon, 28 Jan 2013, Mark A. Greer wrote:
>
> > On Thu, Jan 17, 2013 at 03:27:28PM -0700, Mark A. Greer wrote:
> > > On Thu, Jan 17, 2013 at 07:13:36PM +0000, Paul Walmsley wrote:
> > > > On Tue, 8 Jan 2013, Mark A. Greer wrote:
> > > >
> > > > > On Sun, Dec 23, 2012 at 08:40:43AM +0000, Paul Walmsley wrote:
> >
> > > > What do you think about adding an am35xx_es11plus_hwmod_ocp_ifs[] array to
> > > > omap_hwmod_3xxx_data.c for these secure hwmods? That carries the implicit
> > > > and possibly wrong assumption that it's likely to be ES1.0 devices that
> > > > are missing the SHAM/AES, but it seems unlikely that TI would have
> > > > multiple silicon revs running around claiming to be ES1.1? Or maybe I'm
> > > > just being na?ve.
> > >
> > > Something like that makes sense to me. I'll re-read my email, etc. and
> > > see if I can find something to help us figure it out.
> >
> > I couldn't find any information that helped with this so AFAIK there is no
> > good way to tell if a particular am35xx has the crypto hardware available
> > or not.
>
> I was thinking that we might assume that they are present on AM35xx
> ES1.1+. If the TI folks are saying that they aren't available on only a
> few early devices, I'd guess that means ES1.0. I personally have never
> seen an ES1.0 AM35xx device...
>
> Discriminating between ES1.0 and ES1.1+ should be pretty easy in the hwmod
> init...
>
> > At this point, I vote for moving 'omap3xxx_l4_core__sham' and
> > 'omap3xxx_l4_core__aes' from omap3xxx_gp_hwmod_ocp_ifs[] and putting them
> > in omap34xx_hwmod_ocp_ifs[] and omap36xx_hwmod_ocp_ifs[].
>
> I'm pretty sure that's going to break on HS OMAPs, like the HS OMAP3430 in
> the N900. I don't think those IP blocks are directly accessible from
> Linux on most HS setups, although this might vary by device. I'd feel
> more comfortable if you created an omap34xx_gp_hwmod_ocp_ifs[] list and an
> omap36xx_gp_hwmod_ocp_ifs[] list. We should probably get rid of
> omap3xxx_gp_hwmod_ocp_ifs[] altogether.
>
> > That should be safe in general and if someone with an am35xx wants to
> > use those modules, they can edit am35xx_hwmod_ocp_ifs[] locally.
>
> If you want to just leave them commented in am35xx_hwmod_ocp_ifs[], rather
> than enabling them for ES1.1+ AM35xx, that's fine with me too, since we
> don't know that they are ES-level-based. Maybe put a comment there that
> says that these are likely to be present, but no one seems to know for
> certain? Seems ludicrous, but I guess that's what we're reduced to!
Thanks Paul. I will have some patches early next week.
Mark
--
^ permalink raw reply
* [PATCH v4 00/13] ARM LPAE Fixes - Part 1
From: Subash Patel @ 2013-02-01 20:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359669512-31276-1-git-send-email-cyril@ti.com>
Hi Cyril,
Thanks for posting fixes patch set again. I have in fact used your
previous patch series on a real LPAE system with split memory banks in
both 32-bit and 36-bit physical addresses. I compared your below patches
with previous version, and don't see significant changes. Hence you can use
Tested By: Subash Patel <subash.rp@samsung.com>
for this series as well. In the meantime, I have used the pa/va patching
from v3, but haven't tested any performance numbers on it. But I will
wait for your next reworked version.
Regards,
Subash
On Thursday 31 January 2013 01:58 PM, Cyril Chemparathy wrote:
> This series is a repost of the LPAE related changes in preparation for the
> introduction of the Keystone sub-architecture. The original series has now
> been split, and this particular series excludes the earlier changes to the
> runtime code patching implementation. Earlier versions of this series can be
> found at [1], [2], [3] and [4].
>
> These patches are also available in git:
> git://git.kernel.org/pub/scm/linux/kernel/git/cchemparathy/linux-keystone.git upstream/keystone-lpae-v4
>
> [1] http://comments.gmane.org/gmane.linux.kernel/1341497
> [2] http://comments.gmane.org/gmane.linux.kernel/1332069
> [3] http://comments.gmane.org/gmane.linux.kernel/1356716
> [4] http://comments.gmane.org/gmane.linux.kernel/1362529
>
> Series changelog:
>
> [01/13] ARM: LPAE: use signed arithmetic for mask
> [02/13] ARM: LPAE: use phys_addr_t in alloc_init_pud()
> [03/13] ARM: LPAE: use phys_addr_t in free_memmap()
> (v4) unchanged from v3
> (v3) unchanged from v2
> (v2) unchanged from v1
>
> [04/13] ARM: LPAE: use phys_addr_t for initrd location
> (v4) unchanged from v3
> (v3) unchanged from v2
> (v2) revert to unsigned long for initrd size
>
> [05/13] ARM: LPAE: use phys_addr_t in switch_mm()
> (v4) collapse shift and or into a single instruction
> (v3) remove unnecessary handling for !LPAE in proc-v7-3level
> (v2) use phys_addr_t instead of u64 in switch_mm()
> (v2) revert on changes to v6 and v7-2level
> (v2) fix register mapping for big-endian in v7-3level
>
> [06/13] ARM: LPAE: use 64-bit accessors for TTBR registers
> (v4) remove unnecessary condition code clobber
> (v3) remove unnecessary condition code clobber
> (v2) restore comment in cpu_set_reserved_ttbr0()
>
> [07/13] ARM: LPAE: define ARCH_LOW_ADDRESS_LIMIT for
> (v4) unchanged from v3
> (v3) unchanged from v2
> (v2) unchanged from v1
>
> [08/13] ARM: LPAE: factor out T1SZ and TTBR1 computations
> (v4) cleanup and move code comments
> (v3) unchanged from v2
> (v2) unchanged from v1
>
> [09/13] ARM: LPAE: accomodate >32-bit addresses for page
> (v4) unchanged from v3
> (v3) unchanged from v2
> (v2) apply arch_pgd_shift only on lpae
> (v2) move arch_pgd_shift definition to asm/memory.h
> (v2) revert on changes to non-lpae procs
> (v2) add check to ensure that the pgd physical address is aligned at an
> ARCH_PGD_SHIFT boundary
>
> [10/13] ARM: mm: use physical addresses in highmem sanity
> [11/13] ARM: mm: cleanup checks for membank overlap with
> [12/13] ARM: mm: clean up membank size limit checks
> (v4) unchanged from v3
> (v3) unchanged from v2
> (v2) unchanged from v1
>
> [13/13] ARM: fix type of PHYS_PFN_OFFSET to unsigned long
> (v4) introduced here
>
>
> Cyril Chemparathy (10):
> ARM: LPAE: use signed arithmetic for mask definitions
> ARM: LPAE: use phys_addr_t in switch_mm()
> ARM: LPAE: use 64-bit accessors for TTBR registers
> ARM: LPAE: define ARCH_LOW_ADDRESS_LIMIT for bootmem
> ARM: LPAE: factor out T1SZ and TTBR1 computations
> ARM: LPAE: accomodate >32-bit addresses for page table base
> ARM: mm: use physical addresses in highmem sanity checks
> ARM: mm: cleanup checks for membank overlap with vmalloc area
> ARM: mm: clean up membank size limit checks
> ARM: fix type of PHYS_PFN_OFFSET to unsigned long
>
> Vitaly Andrianov (3):
> ARM: LPAE: use phys_addr_t in alloc_init_pud()
> ARM: LPAE: use phys_addr_t in free_memmap()
> ARM: LPAE: use phys_addr_t for initrd location
>
> arch/arm/include/asm/memory.h | 20 +++++++++-
> arch/arm/include/asm/page.h | 2 +-
> arch/arm/include/asm/pgtable-3level-hwdef.h | 20 ++++++++++
> arch/arm/include/asm/pgtable-3level.h | 6 +--
> arch/arm/include/asm/proc-fns.h | 26 +++++++++----
> arch/arm/kernel/head.S | 10 ++---
> arch/arm/kernel/smp.c | 11 +++++-
> arch/arm/mm/context.c | 9 +----
> arch/arm/mm/init.c | 19 +++++-----
> arch/arm/mm/mmu.c | 49 +++++++++----------------
> arch/arm/mm/proc-v7-3level.S | 53 ++++++++++++++-------------
> 11 files changed, 132 insertions(+), 93 deletions(-)
>
^ permalink raw reply
* [PATCH v2 19/27] pci: PCIe driver for Marvell Armada 370/XP systems
From: Stephen Warren @ 2013-02-01 20:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130201193935.GA19335@obsidianresearch.com>
On 02/01/2013 12:39 PM, Jason Gunthorpe wrote:
> On Fri, Feb 01, 2013 at 10:57:20AM -0700, Stephen Warren wrote:
...
>> I think the only difference on the Marvell HW is:
>>
>> * The overall total size of the physical address space is dynamic rather
>> than fixed, because it's programmed through windows rather than
>> hard-coded into HW.
>
> Is it hard coded on tegra? I thought there was a register set that was
> used to set the overall PCI-E MMIO window location and size. I know
> even on x86 the PCI window is set via register, though that typically
> isn't disclosed except to bios writers..
There is a fixed (in HW) 1 GiB physical address window dedicated to
PCIe. That window is divided between host controller registers, PCIe
root port registers (since our root ports don't respond to configuration
transactions), and regular PCIe accesses; config/MMIO/IO. There are
registers in the host controller that configure the division of this
space into config/MMIO/IO, so that can be dynamic. The DT bindings for
the driver Thierry proposed hard-code those divisions in DT.
^ permalink raw reply
* [PATCH v4 02/13] ARM: LPAE: use phys_addr_t in alloc_init_pud()
From: Subash Patel @ 2013-02-01 20:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.LFD.2.02.1302011310090.6300@xanadu.home>
On Friday 01 February 2013 10:14 AM, Nicolas Pitre wrote:
> On Fri, 1 Feb 2013, Subash Patel wrote:
>
>> Hi Nicolas,
>>
>> On Thursday 31 January 2013 07:35 PM, Nicolas Pitre wrote:
>>> On Fri, 1 Feb 2013, Hui Wang wrote:
>>>
>>>> Cyril Chemparathy wrote:
>>>>> From: Vitaly Andrianov <vitalya@ti.com>
>>>>>
>>>>> This patch fixes the alloc_init_pud() function to use phys_addr_t
>>>>> instead of
>>>>> unsigned long when passing in the phys argument.
>>>>>
>>>>> This is an extension to commit 97092e0c56830457af0639f6bd904537a150ea4a
>>>>> (ARM:
>>>>> pgtable: use phys_addr_t for physical addresses), which applied similar
>>>>> changes
>>>>> elsewhere in the ARM memory management code.
>>>>>
>>>>> Signed-off-by: Vitaly Andrianov <vitalya@ti.com>
>>>>> Signed-off-by: Cyril Chemparathy <cyril@ti.com>
>>>>> Acked-by: Nicolas Pitre <nico@linaro.org>
>>>>> Acked-by: Catalin Marinas <catalin.marinas@arm.com>
>>>>> ---
>>>>> arch/arm/mm/mmu.c | 3 ++-
>>>>> 1 file changed, 2 insertions(+), 1 deletion(-)
>>>>>
>>>>> diff --git a/arch/arm/mm/mmu.c b/arch/arm/mm/mmu.c
>>>>> index 9f06102..ef43689 100644
>>>>> --- a/arch/arm/mm/mmu.c
>>>>> +++ b/arch/arm/mm/mmu.c
>>>>> @@ -612,7 +612,8 @@ static void __init alloc_init_section(pud_t *pud,
>>>>> unsigned long addr,
>>>>> }
>>>>> static void __init alloc_init_pud(pgd_t *pgd, unsigned long addr,
>>>>> - unsigned long end, unsigned long phys, const struct mem_type *type)
>>>>> + unsigned long end, phys_addr_t phys,
>>>>> + const struct mem_type *type)
>>>>>
>>>> The change is correct but seems useless so far. This function only be
>>>> called
>>>> from map_lowmem and devicemaps_init, from i know neither lowmem nor device
>>>> io
>>>> registers of existing platforms exceed 32bit address.
>>>
>>> It is not because you are not aware of any existing platforms with RAM
>>> or device IO above the 4GB mark that they don't exist.
>>>
>>> For example, some LPAE systems have all their RAM located above the 4G
>>> physical address mark. A simple (potentially non DMA capable) alias
>>> exists in the low 32-bit address space to allow the system to boot and
>>> switch to the real physical RAM addresses once the MMU is turned on.
>>> Some of that RAM is still qualified as "low mem" i.e. the portion of RAM
>>> that the kernel keeps permanently mapped in the 32-bit virtual space
>>> even if all of it is above the 4G mark in physical space.
>>
>> I think he is right. You cannot have low_mem and devices in 36-bit areas.
>> Atleast this is what I saw in one of the platforms on which I tested these
>> patches. I am not sure what you mean by hardware address aliasing(as I have
>> real RAM), but we need 32-bit areas to boot the CPU and I have mapped them for
>> the LOW_MEM. But, I have used 36-bit areas for the HIGH_MEM. Since you said
>> about aliasing DDR area in 32-bits, and then switching to 36-bit RAM, does the
>> dma of the devices still use 32-bit aliased addresses?
>>
>> I haven't tested a configuration where LOW_MEM can have both 32-bit and 36-bit
>> DDR PA though. I think its not possible too.
>
> Don't get confused by the 36-bit supersections introduced with ARMv6.
> This patch series is about LPAE capable systems using a completely
> different page table format providing physical addressing beyond 36
> bits.
Yes, I mean LPAE capable MMU's introduced with Cortex-A15. Infact I have
programmed that MMU with 1G super-section for non-linux usage :) Cyril
explained his platform and aliasing. My platform has a real memory in
32-bit area, and we use it for 32-bit DMA's as well. So it looks we are
speaking of various configurations of LPAE systems here.
Regards,
Subash
>
>
> Nicolas
>
^ permalink raw reply
* [PATCH v7 01/10] ARM: davinci: move private EDMA API to arm/common
From: Sergei Shtylyov @ 2013-02-01 20:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130201185820.GE29898@arwen.pp.htv.fi>
Hello.
On 02/01/2013 09:58 PM, Felipe Balbi wrote:
>>>>> Move mach-davinci/dma.c to common/edma.c so it can be used
>>>>> by OMAP (specifically AM33xx) as well.
>>>> I think this should rather go to drivers/dma/?
>>> No, this is the private EDMA API. It's the analogous thing to
>>> the private OMAP dma API that is in plat-omap/dma.c. The actual
>>> dmaengine driver is in drivers/dma/edma.c as a wrapper around
>>> this...same way OMAP DMA engine conversion is being done.
>> Keeps me wondering why we couldn't have the same with CPPI 4.1 when I proposed
>> that, instead of waiting indefinitely for TI to convert it to drivers/dma/
>> directly. We could have working MUSB DMA on OMAP-L1x/Sitara all this time... Sigh.
> good point, do you wanna send some patches ?
I have already sent them countless times and even stuck CPPI 4.1 support (in
arch/arm/common/cppi41.c) in Russell's patch system. TI requested to remove the
patch. :-(
> I guess to make the MUSB side simpler we would need musb-dma-engine glue
> to map dmaengine to the private MUSB API. Then we would have some
> starting point to also move inventra (and anybody else) to dmaengine
> API.
Why? Inventra is a dedicated device's private DMA controller, why make
universal DMA driver for it?
> Once that's done, we drop MUSB's private API.
Don't think it's a good idea.
WBR, Sergei
^ permalink raw reply
* [PATCH v7 01/10] ARM: davinci: move private EDMA API to arm/common
From: Felipe Balbi @ 2013-02-01 20:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <510C2A47.1090607@mvista.com>
hi,
On Fri, Feb 01, 2013 at 11:49:11PM +0300, Sergei Shtylyov wrote:
> > good point, do you wanna send some patches ?
>
> I have already sent them countless times and even stuck CPPI 4.1 support (in
> arch/arm/common/cppi41.c) in Russell's patch system. TI requested to remove the
> patch. :-(
sticking into arch/arm/common/ wasn't a nice move. But then again, so
wasn't asking for the patch to be removed :-s
> > I guess to make the MUSB side simpler we would need musb-dma-engine glue
> > to map dmaengine to the private MUSB API. Then we would have some
> > starting point to also move inventra (and anybody else) to dmaengine
> > API.
>
> Why? Inventra is a dedicated device's private DMA controller, why make
> universal DMA driver for it?
because it doesn't make sense to support multiple DMA APIs. We can check
from MUSB's registers if it was configured with Inventra DMA support and
based on that we can register MUSB's own DMA Engine to dmaengine API.
> > Once that's done, we drop MUSB's private API.
>
> Don't think it's a good idea.
see above.
--
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130201/859fc0e0/attachment.sig>
^ permalink raw reply
* [PATCH v2 1/6] usb: otg: Add an API to bind the USB controller and PHY
From: Marc Kleine-Budde @ 2013-02-01 21:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359081206-5602-2-git-send-email-kishon@ti.com>
On 01/25/2013 03:33 AM, Kishon Vijay Abraham I wrote:
> In order to support platforms which has multiple PHY's (of same type) and
> which has multiple USB controllers, a new design is adopted wherin the binding
> information (between the PHY and the USB controller) should be passed to the
> PHY library from platform specific file (board file).
> So added a new API to pass the binding information.
>
> Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
> ---
> drivers/usb/otg/otg.c | 37 +++++++++++++++++++++++++++++++++++++
> include/linux/usb/phy.h | 22 ++++++++++++++++++++++
> 2 files changed, 59 insertions(+)
>
> diff --git a/drivers/usb/otg/otg.c b/drivers/usb/otg/otg.c
> index a30c041..8e756d9 100644
> --- a/drivers/usb/otg/otg.c
> +++ b/drivers/usb/otg/otg.c
> @@ -18,6 +18,7 @@
> #include <linux/usb/otg.h>
>
> static LIST_HEAD(phy_list);
> +static LIST_HEAD(phy_bind_list);
> static DEFINE_SPINLOCK(phy_lock);
>
> static struct usb_phy *__usb_find_phy(struct list_head *list,
> @@ -201,6 +202,42 @@ void usb_remove_phy(struct usb_phy *x)
> }
> EXPORT_SYMBOL(usb_remove_phy);
>
> +/**
> + * usb_bind_phy - bind the phy and the controller that uses the phy
> + * @dev_name: the device name of the device that will bind to the phy
> + * @index: index to specify the port number
> + * @phy_dev_name: the device name of the phy
> + *
> + * Fills the phy_bind structure with the dev_name and phy_dev_name. This will
> + * be used when the phy driver registers the phy and when the controller
> + * requests this phy.
> + *
> + * To be used by platform specific initialization code.
> + */
> +int __init usb_bind_phy(const char *dev_name, u8 index,
> + const char *phy_dev_name)
> +{
> + struct usb_phy_bind *phy_bind;
> + unsigned long flags;
> +
> + phy_bind = kzalloc(sizeof(*phy_bind), GFP_KERNEL);
> + if (!phy_bind) {
> + pr_err("phy_bind(): No memory for phy_bind");
> + return -ENOMEM;
> + }
> +
> + phy_bind->dev_name = dev_name;
> + phy_bind->phy_dev_name = phy_dev_name;
> + phy_bind->index = index;
> +
> + spin_lock_irqsave(&phy_lock, flags);
> + list_add_tail(&phy_bind->list, &phy_bind_list);
> + spin_unlock_irqrestore(&phy_lock, flags);
> +
> + return 0;
> +}
> +EXPORT_SYMBOL_GPL(usb_bind_phy);
> +
> const char *otg_state_string(enum usb_otg_state state)
> {
> switch (state) {
> diff --git a/include/linux/usb/phy.h b/include/linux/usb/phy.h
> index a29ae1e..e7eb429 100644
> --- a/include/linux/usb/phy.h
> +++ b/include/linux/usb/phy.h
> @@ -106,6 +106,21 @@ struct usb_phy {
> enum usb_device_speed speed);
> };
>
> +/**
> + * struct usb_phy_bind - represent the binding for the phy
> + * @dev_name: the device name of the device that will bind to the phy
> + * @phy_dev_name: the device name of the phy
> + * @index: used if a single controller uses multiple phys
> + * @phy: reference to the phy
> + * @list: to maintain a linked list of the binding information
> + */
> +struct usb_phy_bind {
> + const char *dev_name;
> + const char *phy_dev_name;
> + u8 index;
> + struct usb_phy *phy;
> + struct list_head list;
> +};
>
> /* for board-specific init logic */
> extern int usb_add_phy(struct usb_phy *, enum usb_phy_type type);
> @@ -151,6 +166,8 @@ extern struct usb_phy *devm_usb_get_phy(struct device *dev,
> enum usb_phy_type type);
> extern void usb_put_phy(struct usb_phy *);
> extern void devm_usb_put_phy(struct device *dev, struct usb_phy *x);
> +extern int usb_bind_phy(const char *dev_name, u8 index,
> + const char *phy_dev_name);
> #else
> static inline struct usb_phy *usb_get_phy(enum usb_phy_type type)
> {
> @@ -171,6 +188,11 @@ static inline void devm_usb_put_phy(struct device *dev, struct usb_phy *x)
> {
> }
>
> +static inline int usb_bind_phy(const char *dev_name, u8 index,
> + const char *phy_dev_name)
> +{
> + return NULL;
The return value looks bogus.
Marc
> +}
> #endif
>
> static inline int
>
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions | Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 263 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130201/7ccbeae2/attachment.sig>
^ permalink raw reply
* [PATCH v7 01/10] ARM: davinci: move private EDMA API to arm/common
From: Russell King - ARM Linux @ 2013-02-01 21:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130201205600.GA31762@arwen.pp.htv.fi>
On Fri, Feb 01, 2013 at 10:56:00PM +0200, Felipe Balbi wrote:
> hi,
>
> On Fri, Feb 01, 2013 at 11:49:11PM +0300, Sergei Shtylyov wrote:
> > > good point, do you wanna send some patches ?
> >
> > I have already sent them countless times and even stuck CPPI 4.1 support (in
> > arch/arm/common/cppi41.c) in Russell's patch system. TI requested to remove the
> > patch. :-(
>
> sticking into arch/arm/common/ wasn't a nice move. But then again, so
> wasn't asking for the patch to be removed :-s
Err, patches don't get removed, they get moved to 'discarded'.
> > > I guess to make the MUSB side simpler we would need musb-dma-engine glue
> > > to map dmaengine to the private MUSB API. Then we would have some
> > > starting point to also move inventra (and anybody else) to dmaengine
> > > API.
> >
> > Why? Inventra is a dedicated device's private DMA controller, why make
> > universal DMA driver for it?
>
> because it doesn't make sense to support multiple DMA APIs. We can check
> from MUSB's registers if it was configured with Inventra DMA support and
> based on that we can register MUSB's own DMA Engine to dmaengine API.
Hang on. This is one of the DMA implementations which is closely
coupled with the USB and only the USB? If it is...
I thought this had been discussed _extensively_ before. I thought the
resolution on it was:
1. It would not use the DMA engine API.
2. It would not live in arch/arm.
3. It would be placed nearby the USB driver it's associated with.
(1) because we don't use APIs just for the hell of it - think. Do we
use the DMA engine API for PCI bus mastering ethernet controllers? No.
Do we use it for PCI bus mastering SCSI controllers? No. Because the
DMA is integral to the rest of the device.
The DMA engine API only makes sense if the DMA engine is a shared
system resource.
^ permalink raw reply
* [PATCH 2/2] ARM: OMAP2: Fix GPMC memory initialisation
From: Tony Lindgren @ 2013-02-01 21:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359736726-10193-3-git-send-email-jon-hunter@ti.com>
Hi Jon,
* Jon Hunter <jon-hunter@ti.com> [130201 08:42]:
> --- a/arch/arm/mach-omap2/gpmc.c
> +++ b/arch/arm/mach-omap2/gpmc.c
> @@ -32,6 +32,7 @@
>
> #include "soc.h"
> #include "common.h"
> +#include "control.h"
> #include "omap_device.h"
> #include "gpmc.h"
>
> @@ -778,18 +779,26 @@ static void gpmc_mem_exit(void)
> static int gpmc_mem_init(void)
> {
> int cs, rc;
> - unsigned long boot_rom_space = 0;
>
> - /* never allocate the first page, to facilitate bug detection;
> - * even if we didn't boot from ROM.
> + /*
> + * The first 1MB of GPMC address space is mapped to the
> + * internal ROM. OMAP2 devices are an exception to this
> + * where the first 1MB may be mapped to the GPMC.
> */
> - boot_rom_space = BOOT_ROM_SPACE;
> - /* In apollon the CS0 is mapped as 0x0000 0000 */
> - if (machine_is_omap_apollon())
> - boot_rom_space = 0;
This part is going away anyways with the patch dropping apollon
board support from Kyungin.
> - gpmc_mem_root.start = GPMC_MEM_START + boot_rom_space;
> + gpmc_mem_root.start = GPMC_MEM_START + BOOT_ROM_SPACE;
> gpmc_mem_root.end = GPMC_MEM_END;
>
> + /*
> + * OMAP2 devices that boot from external memory devices, will
> + * map CS0 to the start of the GPMC address space (0x0). We can
> + * test this by checking if SYS_BOOT3 pin is set. If not set
> + * then CS0 is mapped to 0x0.
> + */
> + if (cpu_is_omap24xx())
> + if (!(omap_ctrl_readl(OMAP24XX_CONTROL_STATUS) &
> + OMAP2_SYSBOOT_3_MASK))
> + gpmc_mem_root.start = GPMC_MEM_START;
> +
> /* Reserve all regions that has been set up by bootloader */
> for (cs = 0; cs < GPMC_CS_NUM; cs++) {
> u32 base, size;
How about let's fix this properly to start with so we don't add
more blockers moving this code to drivers/bus?
Looks like gpmc_mem_init() gets called from gpmc_probe() so
we can pass that information in pdev.
Regards,
Tony
^ permalink raw reply
* [PATCH v2 2/6] usb: otg: utils: add facilities in phy lib to support multiple PHYs of same type
From: Marc Kleine-Budde @ 2013-02-01 21:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359081206-5602-3-git-send-email-kishon@ti.com>
On 01/25/2013 03:33 AM, Kishon Vijay Abraham I wrote:
> In order to add support for multipe PHY's of the same type, new API's
> for adding PHY and getting PHY has been added. Now the binding
> information for the PHY and controller should be done in platform file
> using usb_bind_phy API. And for getting a PHY, the device pointer of the
> USB controller and an index should be passed. Based on the binding
> information that is added in the platform file, usb_get_phy_dev will return the
> appropriate PHY.
> Already existing API's to add and get phy by type is not removed. These
> API's are deprecated and will be removed once all the platforms start to
> use the new API.
>
> Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
> ---
> drivers/usb/otg/otg.c | 118 ++++++++++++++++++++++++++++++++++++++++++++++-
> include/linux/usb/phy.h | 13 ++++++
> 2 files changed, 130 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/usb/otg/otg.c b/drivers/usb/otg/otg.c
> index 8e756d9..4bb4333 100644
> --- a/drivers/usb/otg/otg.c
> +++ b/drivers/usb/otg/otg.c
> @@ -36,6 +36,24 @@ static struct usb_phy *__usb_find_phy(struct list_head *list,
> return ERR_PTR(-ENODEV);
> }
>
> +static struct usb_phy *__usb_find_phy_dev(struct device *dev,
> + struct list_head *list, u8 index)
> +{
> + struct usb_phy_bind *phy_bind = NULL;
> +
> + list_for_each_entry(phy_bind, list, list) {
> + if (!(strcmp(phy_bind->dev_name, dev_name(dev))) &&
> + phy_bind->index == index) {
> + if (phy_bind->phy)
> + return phy_bind->phy;
> + else
> + return ERR_PTR(-EPROBE_DEFER);
> + }
> + }
> +
> + return ERR_PTR(-ENODEV);
> +}
> +
> static void devm_usb_phy_release(struct device *dev, void *res)
> {
> struct usb_phy *phy = *(struct usb_phy **)res;
> @@ -112,6 +130,69 @@ err0:
> EXPORT_SYMBOL(usb_get_phy);
>
> /**
> + * usb_get_phy_dev - find the USB PHY
> + * @dev - device that requests this phy
> + * @index - the index of the phy
> + *
> + * Returns the phy driver, after getting a refcount to it; or
> + * -ENODEV if there is no such phy. The caller is responsible for
> + * calling usb_put_phy() to release that count.
> + *
> + * For use by USB host and peripheral drivers.
> + */
> +struct usb_phy *usb_get_phy_dev(struct device *dev, u8 index)
> +{
> + struct usb_phy *phy = NULL;
> + unsigned long flags;
> +
> + spin_lock_irqsave(&phy_lock, flags);
> +
> + phy = __usb_find_phy_dev(dev, &phy_bind_list, index);
> + if (IS_ERR(phy)) {
You should probably lock the phy module in memory. See my patch "usb:
otg: use try_module_get in all usb_get_phy functions and add missing
module_put".
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions | Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 263 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130201/c716d5f4/attachment-0001.sig>
^ permalink raw reply
* [PATCH] ARM: OMAP: gpmc: Add device tree documentation for elm handle
From: Tony Lindgren @ 2013-02-01 21:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358485066-27495-1-git-send-email-avinashphilip@ti.com>
* Philip Avinash <avinashphilip@ti.com> [130117 21:00]:
> In case ELM module available, omap2 NAND driver can opt for hardware
> correction method for bit flip errors in NAND flash with BCH. Hence the
> detection of ELM module is done through devicetree population of elm_id.
> This patch update device tree documentation for gpmc-nand for elm-id
> data population.
>
> Signed-off-by: Philip Avinash <avinashphilip@ti.com>
> ---
> This patch based [1] and depends on [2]. As Artem suggested, this patch can
> go in omap_tree due to the dependency on [3].
> Discussion can found at [4]
>
> Tony,
> Can you accept this patch.
Thanks applying into omap-for-v3.9/gpmc.
Regards,
Tony
> 1. http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap.git;a=shortlog;h=refs/heads/omap-for-v3.9/gpmc
> 2. mtd: nand: omap2: Support for hardware BCH error correction
> http://git.infradead.org/users/dedekind/l2-mtd-2.6.git/commit/576daed18c3f27bb5d0e57e1df11e8f7b493dce8
> 3. ARM: OMAP: gpmc: add DT bindings for GPMC timings and NAND
> http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap.git;a=commit;h=bc6b1e7b86f5d8e4a6fc1c0189e64bba4077efe0
> 4. https://lkml.org/lkml/2013/1/17/167
>
> .../devicetree/bindings/mtd/gpmc-nand.txt | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/mtd/gpmc-nand.txt b/Documentation/devicetree/bindings/mtd/gpmc-nand.txt
> index 9f464f9..e7f8d7e 100644
> --- a/Documentation/devicetree/bindings/mtd/gpmc-nand.txt
> +++ b/Documentation/devicetree/bindings/mtd/gpmc-nand.txt
> @@ -29,6 +29,9 @@ Optional properties:
> "bch4" 4-bit BCH ecc code
> "bch8" 8-bit BCH ecc code
>
> + - elm_id: Specifies elm device node. This is required to support BCH
> + error correction using ELM module.
> +
> For inline partiton table parsing (optional):
>
> - #address-cells: should be set to 1
> @@ -46,6 +49,7 @@ Example for an AM33xx board:
> #address-cells = <2>;
> #size-cells = <1>;
> ranges = <0 0 0x08000000 0x2000>; /* CS0: NAND */
> + elm_id = <&elm>;
>
> nand at 0,0 {
> reg = <0 0 0>; /* CS0, offset 0 */
> --
> 1.7.9.5
>
^ permalink raw reply
* [PATCH] ARM: omap2: gpmc: Remove unneeded of_node_put()
From: Tony Lindgren @ 2013-02-01 21:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <51029423.2040106@ti.com>
* Jon Hunter <jon-hunter@ti.com> [130125 06:21]:
>
> On 01/25/2013 06:19 AM, Ezequiel Garcia wrote:
> > for_each_node_by_name() automatically calls of_node_put() on each
> > node passed; so don't do it explicitly unless there's an error.
> >
> > Reported-by: Mark Rutland <mark.rutland@arm.com>
> > Signed-off-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
> > ---
> > arch/arm/mach-omap2/gpmc.c | 5 +++--
> > 1 files changed, 3 insertions(+), 2 deletions(-)
> >
> > diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
> > index 01ce462..c6255f7 100644
> > --- a/arch/arm/mach-omap2/gpmc.c
> > +++ b/arch/arm/mach-omap2/gpmc.c
> > @@ -1271,9 +1271,10 @@ static int gpmc_probe_dt(struct platform_device *pdev)
> >
> > for_each_node_by_name(child, "nand") {
> > ret = gpmc_probe_nand_child(pdev, child);
> > - of_node_put(child);
> > - if (ret < 0)
> > + if (ret < 0) {
> > + of_node_put(child);
> > return ret;
> > + }
> > }
> >
> > return 0;
> >
>
> Acked-by: Jon Hunter <jon-hunter@ti.com>
Thanks applying into omap-for-v3.9/gpmc.
Tony
^ permalink raw reply
* [PATCH 1/4] arch: arm: gpmc: gpmc migration support
From: Tony Lindgren @ 2013-02-01 22:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358933176-12409-2-git-send-email-avinashphilip@ti.com>
* Philip Avinash <avinashphilip@ti.com> [130123 01:28]:
> With recent GPMC driver conversion, usage of gpmc_save/restore_context
> can done from gpmc driver itself. Hence removes the usage from pm34xx.c.
> Also removes the conditional compilation primitives ARCH_OMAP3 for
> gpmc_save/restore_context.
Hmm I think this will break GPMC for deeper idle modes. Note that we
need to save and restore the context every time hitting off-idle, not
just for suspend and resume. Or am I missing something here?
Regards,
Tony
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox