On Thursday 11 July 2013, Neil Zhang wrote:
> > > > To do this properly, the drivers are going to have to be compatible
> > > > with the old and the new names, and the binding docs updated to
> > > > reflect the legacy name and the preferred name.
> > >
> > > Properly would be as above. You can sto
On Saturday 13 July 2013, Gerhard Sittig wrote:
> [ MPC8308 knowledge required, see below ]
>
> On Sat, Jul 13, 2013 at 09:17 +0200, Arnd Bergmann wrote:
> >
> > On Friday 12 July 2013, Gerhard Sittig wrote:
> > > +++ b/include/dt-bindings/dma/mpc
On Friday 12 July 2013, Gerhard Sittig wrote:
> +++ b/include/dt-bindings/dma/mpc512x-dma.h
> @@ -0,0 +1,21 @@
> +/*
> + * This header file provides symbolic specifiers for DMA channels
> + * within the MPC512x SoC's DMA controller. Since requester lines
> + * directly map to channel numbers and n
On Tuesday 09 July 2013, Neil Zhang wrote:
> + soc {
> + compatible = "simple-bus";
> + #address-cells = <1>;
> + #size-cells = <1>;
> + interrupt-parent = <&gic>;
> + ranges;
> +
> + gic: interrupt-controller@d1dfe100 {
>
On Tuesday 09 July 2013, Thomas Petazzoni wrote:
> Dear Neil Zhang,
>
> On Tue, 9 Jul 2013 14:42:45 +0800, Neil Zhang wrote:
> > support CLOCKSOURCE OF DECLARE for mmp timer.
> >
> > Signed-off-by: Neil Zhang
> > ---
> > arch/arm/mach-mmp/mmp-dt.c |5 ++---
> > arch/arm/mach-mmp/mmp2-dt.c
On Monday 08 July 2013, Jonas Jensen wrote:
> Arnd suggested removing one (or many) of the options:
>
> CPU_ABRT_EV4T
> CPU_CACHE_V4WT
> CPU_COPY_V4WB
> CPU_TLB_V4WBI
>
> However boot is still broken after removing all including CPU_32v4T.
>
> Selecting CPU_SA1100 instead, it boots normally and
On Saturday 06 July 2013, Thomas Petazzoni wrote:
> Arnd, Jason, if you could confirm that you both agree with this DT
> binding soon, Ezequiel and I would quickly adapt the code accordingly,
> and hopefully converge towards a final patch set.
Looks all good from what I can tell.
Arnd
___
On Saturday 06 July 2013, Jason Gunthorpe wrote:
> This is a good try, but this coding doesn't work...
>
> Recall the long discussion that came up during the original
> development of this binding. The OF spec says this:
>
> In particular, the phys.hi fields of the child address spaces in the
>
On Friday 05 July 2013, Ezequiel Garcia wrote:
> See the previous version of this patchset for further context:
>
> http://www.mail-archive.com/devicetree-discuss@lists.ozlabs.org/msg35753.html
>
> This new proposal is an attempt to address some issues raised about the PCIe
> 'fake' windows mappi
On Thursday 04 July 2013, Mark Brown wrote:
> On Thu, Jul 04, 2013 at 06:56:24PM +0200, Daniel Mack wrote:
>
> > Unless I missed some recent discussion, this case is not easy to handle.
> > Yes, I know that these kind of things should be handled by a
> > next-generation bootloader, but in our case
; }
>
> The remainder is probably fully optimized out.
Ah, you are right, sorry for the confusion on my part.
I thought you had used do_div() rather than div_u64().
Everything's fine then, feel free to add my
Acked-by: Arnd Bergmann
to your patch.
Arnd
_
On Wednesday 03 July 2013, Christian Ruppert wrote:
> On Wed, Jul 03, 2013 at 04:20:03PM +0200, Arnd Bergmann wrote:
> > On Wednesday 03 July 2013, Christian Ruppert wrote:
> > > On Wed, Jul 03, 2013 at 01:43:11PM +0200, Arnd Bergmann wrote:
> > > > On Wednesday 26
On Wednesday 03 July 2013, Christian Ruppert wrote:
> On Wed, Jul 03, 2013 at 04:20:03PM +0200, Arnd Bergmann wrote:
> > On Wednesday 03 July 2013, Christian Ruppert wrote:
> > > On Wed, Jul 03, 2013 at 01:43:11PM +0200, Arnd Bergmann wrote:
> > > > On Wednesday 26
On Wednesday 03 July 2013, Christian Ruppert wrote:
> On Wed, Jul 03, 2013 at 01:43:11PM +0200, Arnd Bergmann wrote:
> > On Wednesday 26 June 2013, Wolfram Sang wrote:
> > > On Wed, Jun 26, 2013 at 10:55:06AM +0200, Christian Ruppert wrote:
> > > > This patch makes
On Wednesday 03 July 2013, Artem Bityutskiy wrote:
> On Wed, 2013-07-03 at 13:16 +, Gupta, Pekon wrote:
> > [Pekon]: Yes, I'm not seeing these build issues, as I'm cleanly
> > returning from probe with pr_err(), if the required libraries (/lib/bch.c)
> > are not build-in the system.
> > --
On Tuesday 02 July 2013, Pekon Gupta wrote:
> (+ CC: devicetree-discuss@lists.ozlabs.org)
>
> Changes v3 -> v4
> - [Patch 1/3] removed MTD_NAND_OMAP_BCH8 & MTD_NAND_OMAP_BCH4 from
> nand/Kconfig
> ECC scheme selectable via nand DT (nand-ecc-opt).
> - [*] rebased for l2-mtd.git
Do you also
t;
> > There's another pending issue. Arnd Bergmann has required to add a
> > property to specify the available space within the CPU address space
> > for decoding windows. This property would allow to support fully
> > dynamic mbus window allocation.
>
> I wonder
c_probe':
/git/arm-soc/drivers/i2c/busses/i2c-designware-platdrv.c:125: undefined
reference to `__udivdi3'
I suspect you want something like the change below.
Signed-off-by: Arnd Bergmann
diff --git a/drivers/i2c/busses/i2c-designware-platdrv.c
b/drivers/i2c/busses/i2c-designware-pl
On Tuesday 02 July 2013 10:11:55 Pratyush Anand wrote:
> On 7/2/2013 9:16 AM, Sean Cross wrote:
> >> >I may be wrong, but from these offset it seems to me that it is SNPS
> >> >controller. If yes, then please go through comments of
> >> >"[PATCH V1-10 0/4] PCIe support for Samsung Exynos5440 SoC"
>
plex mode.
> > >
> > > Signed-off-by: Surendranath Gurivireddy Balla
> > > Signed-off-by: Siva Reddy Kallam
> > > Signed-off-by: Jingoo Han
> > > Acked-by: Arnd Bergmann
> >
> > Acked-by: Bjorn Helgaas
> >
> > Please merge t
On Monday 24 June 2013, Joel A Fernandes wrote:
> >> Yes sure, right now they are defined as follows in include/linux/edma.h:
> >>
> >> #if defined(CONFIG_TI_EDMA) || defined(CONFIG_TI_EDMA_MODULE)
> >> bool edma_filter_fn(struct dma_chan *, void *);
> >> #else
> >> static inline bool edma_filter_
On Saturday 22 June 2013, Joel A Fernandes wrote:
>
> >> > config TI_EDMA
> >> > tristate "TI EDMA support"
> >> > default m if 'ARCH_DAVINCI || ARCH_OMAP1 || ARCH_OMAP2
> >> > select DMA_ENGINE
> >> > select DMA_VIRTUAL_CHANNELS
> >>
> >>
> >> MMC depends on EDMA s
On Monday 24 June 2013 16:49:08 zhangfei gao wrote:
>
> Dear Arnd & Vinod
>
> The suggestion of using dma_get_slave_channel instead of filter works here.
> Dma driver should modify accordingly.
The changes all look good to me, thanks a lot for following up!
However, you should really follow the
On Friday 21 June 2013, Joel A Fernandes wrote:
> Hi Arnd,
>
> On Fri, Jun 21, 2013 at 1:44 PM, Arnd Bergmann wrote:
> > On Friday 21 June 2013, Joel A Fernandes wrote:
> >> I think we are talking about different things, I agree the 'select
> >> DMADEVICE
On Friday 21 June 2013, Joel A Fernandes wrote:
> I think we are talking about different things, I agree the 'select
> DMADEVICES' can be dropped but lets please keep the default y option
> (not adding new select statements, just saying that if someone select
> DMADEVICES in menuconfig and if they'
On Friday 21 June 2013, Joe Perches wrote:
> On Fri, 2013-06-21 at 10:53 +, Alexey Brodkin wrote:
> > On 06/21/2013 02:32 PM, Joe Perches wrote:
> > > On Fri, 2013-06-21 at 11:20 +0400, Alexey Brodkin wrote:
> > >> Driver for non-standard on-chip ethernet device ARC EMAC 10/100,
> > >> instanti
On Friday 21 June 2013, Joel A Fernandes wrote:
> I haven't come across this problem but- are you saying there is a
> shortcoming in Kbuild/Kconfig that selects an option even if its
> dependency is not met?
Well, the shortcoming is that it lets you specify impossible
contraints. You get a warning
On Friday 21 June 2013, Jason Cooper wrote:
> On Fri, Jun 21, 2013 at 10:30:47AM +0200, Arnd Bergmann wrote:
> > On Friday 21 June 2013, Thomas Petazzoni wrote:
> > > I am by far not an expert on how to solve merge strategies and so on,
> > > but to avoid conflicts at
On Friday 21 June 2013, Tomasz Figa wrote:
> > To me, this new hook is strictly equivalent to init_irq. What do we gain
> > exactly? I didn't think init_irq was going away...
> >
> > I know init_irq is not pretty, and we tend to overload it with other
> > stuff, but I don't really see the point o
On Friday 21 June 2013, Joel A Fernandes wrote:
> >> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> >> index b1c66a4..7d58cd9 100644
> >> --- a/arch/arm/Kconfig
> >> +++ b/arch/arm/Kconfig
> >> @@ -841,6 +841,7 @@ config ARCH_DAVINCI
> >> select HAVE_IDE
> >> select NEED_MACH_GPIO_H
On Friday 21 June 2013, Vinod Koul wrote:
> On Mon, Jun 17, 2013 at 10:58:07PM +0200, Arnd Bergmann wrote:
> > On Monday 17 June 2013, Zhangfei Gao wrote:
> >
> > int dma_get_slave_channel(struct dma_chan *chan)
> > {
> > /* lock against __dma_reques
On Friday 21 June 2013, Thomas Petazzoni wrote:
> I am by far not an expert on how to solve merge strategies and so on,
> but to avoid conflicts at Linus's level while merging the arm-soc and
> pci trees, it would be better if this Samsung PCIe driver could go
> through arm-soc (with Bjorn ACK, of
On Friday 21 June 2013, Jingoo Han wrote:
> Changes between v9 and v10:
> * Changed the file name from 'pci-designware.c' to 'pcie-designware.c'
> guided by Pratyush Anand, because synopsis pcie and pci controllers
> are different.
> * Fixed the typos of document, reported by Sachin Kam
On Thursday 20 June 2013, Srinivas KANDAGATLA wrote:
> +static u64 gt_counter_read(void)
> +{
> + u64 counter;
> + u32 lower;
> + u32 upper, old_upper;
> +
> + upper = __raw_readl(gt_base + GT_COUNTER1);
> + do {
> + old_upper = upper;
> + l
ck. It supports Rx & Tx functionality.
> It support all industry standard baud rates.
>
> Signed-off-by: Srinivas Kandagatla
> CC: Stephen Gallimore
> CC: Stuart Menefy
> CC: Arnd Bergmann
> CC: Greg Kroah-Hartman
>From my point of view the series is ready
On Thursday 20 June 2013, Srinivas KANDAGATLA wrote:
> --- a/arch/arm/mach-sti/board-dt.c
> +++ b/arch/arm/mach-sti/board-dt.c
> @@ -11,6 +11,7 @@
> #include
> #include
> #include
> +#include
> #include
>
> #include "smp.h"
> @@ -42,6 +43,7 @@ static const char *stih41x_dt_match
On Thursday 20 June 2013, Jingoo Han wrote:
> diff --git a/Documentation/devicetree/bindings/pci/exynos-pcie.txt
> b/Documentation/devicetree/bindings/pci/exynos-pcie.txt
> new file mode 100644
> index 000..f71d835
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/pci/exynos-pcie.txt
On Thursday 20 June 2013, Jingoo Han wrote:
> 2. patch adding label to the pinctrl node (which is a prerequisite) and
> board-specific properties of PCIe nodes.
>[PATCH] ARM: dts: Add pcie controller node for exynos5440-ssdk5440
>
> arch/arm/boot/dts/exynos5440-ssdk5440.dts
> +
> + p
: Jingoo Han
The code looks good now.
Acked-by: Arnd Bergmann
> .../devicetree/bindings/pci/exynos-pcie.txt| 71 ++
> drivers/pci/host/Kconfig |5 +
> drivers/pci/host/Makefile |1 +
> drivers/pci/host/pci-exynos
On Thursday 20 June 2013, Jingoo Han wrote:
> Exynos5440 has two PCIe controllers which can be used as root complex
> for PCIe interface.
>
> Signed-off-by: Jingoo Han
Acked-by: Arnd Bergmann
___
devicetree-discuss mailing list
device
On Wednesday 19 June 2013, Ezequiel Garcia wrote:
> > > What happens is that any decoding window that was setup by the bootloader,
> > > is wiped and completely new windows are allocated using the translations
> > > in the DT, as described by this binding.
> > >
> > > This was the case from the st
On Wednesday 19 June 2013, Jason Gunthorpe wrote:
>
> Today 18:53:48
>
> On Wed, Jun 19, 2013 at 02:11:58PM +0200, Arnd Bergmann wrote:
>
> > > Mmm.. and why is this option acceptable?
> >
> > As I explained on IRC, there is no requirement to pick a spe
On Wednesday 19 June 2013, Pawel Moll wrote:
> > That would end up eliminating the sysreg driver, aside from maybe
> > a one-line change to the syscon driver to allow it to probe the
> > right device.
>
> ... but sysreg does more than just that. In particular it provides a
> pseudo-gpio controller
On Wednesday 19 June 2013, Jingoo Han wrote:
> Then, do you mean the following?
>
> static int __exit exynos_pcie_remove(struct platform_device *pdev)
> {
> struct pcie_port *pp = platform_get_drvdata(pdev);
>
> clk_disable_unprepare(pp->bus_clk);
> clk_disable_unprepare(p
On Wednesday 19 June 2013, Samuel Ortiz wrote:
> > 2. Move the vexpress-sysreg "platform management" functions into misc
> > (unless we get any better place for it)
> This is for Arnd and Greg to decide I suppose.
I think when vexpress-sysreg was created, we didn't have the syscon driver
yet, oth
On Wednesday 19 June 2013, Ezequiel Garcia wrote:
> Arnd,
>
> Going through this a couple questions came out...
>
> On Tue, Jun 18, 2013 at 11:35:50PM +0200, Arnd Bergmann wrote:
> > On Tuesday 18 June 2013, Ezequiel Garcia wrote:
> > > +
> &
On Tuesday 18 June 2013, Ezequiel Garcia wrote:
> Although I'd like the binding to take this into account, for there's no
> point in restricting it -a priori- I can't see any advantage on doing
> fully dynamic window configuration on devices that are fixed in the
> first place. It sounds like bloat
On Wednesday 19 June 2013, Ezequiel Garcia wrote:
> On Tue, Jun 18, 2013 at 06:16:26PM +0200, Arnd Bergmann wrote:
> > On Tuesday 18 June 2013, Ezequiel Garcia wrote:
> > >
> > > + devbus-bootcs {
> > > +
On Tuesday 18 June 2013, Ezequiel Garcia wrote:
> On Tue, Jun 18, 2013 at 06:14:33PM +0200, Arnd Bergmann wrote:
> > On Tuesday 18 June 2013, Ezequiel Garcia wrote:
> > > +Required properties:
> > > +
> > > +- compatible: Should be set to one of the
On Tuesday 18 June 2013, Ezequiel Garcia wrote:
> +
> + ranges =
> + <0x8200 0 0x40x0001 0x4 0
> 0x2000
> + 0x8200 0 0x80x0001 0x8 0
> 0x2000
> +
On Tuesday 18 June 2013, Jason Gunthorpe wrote:
> On Tue, Jun 18, 2013 at 08:22:08PM +0200, Arnd Bergmann wrote:
>
> > > > > Arnd, we've discussed this at length with you while getting the PCIe
> > > > > driver merged, and we've explained this to
On Tuesday 18 June 2013, Sebastian Hesselbarth wrote:
> On 06/18/2013 07:46 PM, Jason Gunthorpe wrote:
> > On Tue, Jun 18, 2013 at 08:25:28AM -0300, Ezequiel Garcia wrote:
> >> +
> >> +IIAA
> >> +
> >> +Where:
> >> + -- I = Marvell defined target ID for programmable windows
> >> + -- A = Marv
On Tuesday 18 June 2013, Thomas Petazzoni wrote:
> On Tue, 18 Jun 2013 19:18:58 +0200, Arnd Bergmann wrote:
>
> > > >ranges =
> > > > <0x8200 0 0x40x0
On Tuesday 18 June 2013, Thomas Petazzoni wrote:
> > To clarify my earlier comment, I think it would be nicer to write this as
> >
> >ranges =
> > <0x8200 0 0x40x0001 0x4 0
> > 0x2000
> >
On Tuesday 18 June 2013, Thomas Petazzoni wrote:
> Dear Arnd Bergmann,
>
> On Tue, 18 Jun 2013 18:14:33 +0200, Arnd Bergmann wrote:
>
> > Using 0x0002 as a placeholder for the pcie translation is definitely
> > better than 0x as you had before, but let me a
ll be passed to the driver from the SoC platform data, using the
> auxdata procedure.
>
> Signed-off-by: Guennadi Liakhovetski
Acked-by: Arnd Bergmann
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://list
On Tuesday 18 June 2013, Ezequiel Garcia wrote:
> + ranges =
> + <0x8200 0 0x40x0001 0x4 0
> 0x2000
> + 0x8200 0 0x80x0001 0x8 0
> 0x2000
> +
On Tuesday 18 June 2013, Ezequiel Garcia wrote:
>
> + devbus-bootcs {
> + compatible = "marvell,mvebu-devbus";
> + reg = <0x0001 0x10400 0x8>;
> + ranges = <0 MBUS_ID(0x01, 0x2f) 0 0x>;
> +
On Tuesday 18 June 2013, Ezequiel Garcia wrote:
> +Required properties:
> +
> +- compatible: Should be set to one of the following:
> + marvell,armada370-mbus
> + marvell,armadaxp-mbus
> +
> +- reg:Device's register space.
> + Two entri
On Tuesday 18 June 2013 22:22:17 zhangfei wrote:
> > With no need to have a filter function.
>
> Cool, then I would like to wait for the patch.
Maybe you can try to add the dma_get_slave_channel() function I proposed here
as a first patch and add your driver on top. There may be issues I missed,
On Tuesday 18 June 2013, Heiko Stübner wrote:
> > Side comment: I think it would be nice if the generic code did this
> > init if a l2x0 device node was in the device tree, since the only
> > reason to override init_machine is to do this call in addition to
> > of_platform_populate().
>
> Arnd sai
On Tuesday 18 June 2013, zhangfei gao wrote:
> On Tue, Jun 18, 2013 at 4:58 AM, Arnd Bergmann wrote:
> >
> >> +static struct of_dma_filter_info k3_dma_filter;
> >> +static bool k3_dma_filter_fn(struct dma_chan *chan, void *param)
> >> +{
> >>
On Tuesday 18 June 2013, Jingoo Han wrote:
> On Monday, June 17, 2013 9:45 PM, Arnd Bergmann wrote:
> > On Monday 17 June 2013 18:45:52 Jingoo Han wrote:
> > > On Friday, June 14, 2013 9:54 PM, Arnd Bergmann wrote:
> > > >
> > > > Please look up th
On Tuesday 18 June 2013, Guennadi Liakhovetski wrote:
> Hi Arnd
>
> On Mon, 17 Jun 2013, Arnd Bergmann wrote:
>
> > On Thursday 06 June 2013, Guennadi Liakhovetski wrote:
> > > +Required properties:
> > > +- dmas: a list of <[DMA controller
On Tuesday 18 June 2013, Guennadi Liakhovetski wrote:
> >
> > Hmm, you've clearly shown that this can work, but it feels like a really
> > odd way to
> > do this. I don't think we should do it this way, because it tries to be
> > really
> > generic but then cannot some of the interesting cases,
On Tuesday 18 June 2013, dingu...@altera.com wrote:
> @@ -476,27 +476,31 @@
> };
>
> timer0: timer0@ffc08000 {
> - compatible = "snps,dw-apb-timer-sp";
> + compatible = "snps,dw-apb-timer";
> inter
t; and be able mount to rootfs and boot till command prompt over MMC.
> Unless there are other pending review comments, I hope this series can
> make it into 3.11 merge window, the dependent series has been posted at [1]
> and completed review.
>
> Tested EDMA on AM1808 EVM and AM33XX B
Michal Simek wrote:
> >>>> Hi,
> >>>>
> >>>
> >>> Arnd can you take look on it again please
> >>>
> >>> I'll take a look on it next week
> >>
> >> Any u
On Monday 17 June 2013, Zhangfei Gao wrote:
> Add dmaengine driver for hisilicon k3 platform based on virt_dma
>
> Signed-off-by: Zhangfei Gao
> Tested-by: Kai Yang
Acked-by: Arnd Bergmann
> diff --git a/Documentation/devicetree/bindings/dma/k3dma.txt
> b/Documentation/d
On Thursday 06 June 2013, Guennadi Liakhovetski wrote:
> Documentation/devicetree/bindings/dma/dma.txt | 44
> +
> drivers/dma/of-dma.c | 31 +
> 2 files changed, 67 insertions(+), 8 deletions(-)
>
> diff --git a/Documentation/
On Monday 17 June 2013, Fernandes, Joel A wrote:
> [Joel] Thanks for the suggestion, I updated it and it looks like this now:
>
>
> Required properties:
On Wednesday 12 June 2013, Vinod Koul wrote:
> On Thu, Jun 06, 2013 at 05:47:22PM +0200, Guennadi Liakhovetski wrote:
> > Next re-send of an earlier work. This series adds support for multiple
> > compatible DMAC instances, capable of serving the same DMA slaves.
> > Currently to specify such a c
On Thursday 06 June 2013, Guennadi Liakhovetski wrote:
> +Required properties:
> +- dmas: a list of <[DMA controller phandle] [MID/RID value]>
> pairs
> +- dma-names: a list of DMA channel names, one per "dmas" entry
Looks ok to me, although it might be helpful to clarify what MID/RI
On Monday 17 June 2013 18:45:52 Jingoo Han wrote:
> On Friday, June 14, 2013 9:54 PM, Arnd Bergmann wrote:
> >
> > Please look up the documentation about inbound viewport and describe
> > in a code comment what it does. I /assume/ that this is how DMA accesses
> > from
On Friday 14 June 2013 21:32:47 Joel A Fernandes wrote:
>
> diff --git a/Documentation/devicetree/bindings/dma/ti-edma.txt
> b/Documentation/devicetree/bindings/dma/ti-edma.txt
> new file mode 100644
> index 000..ada0018
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/dma/ti-edma.tx
On Friday 14 June 2013 17:18:46 Jingoo Han wrote:
> On Thursday, June 13, 2013 11:14 PM, Arnd Bergmann wrote:
> > On Thursday 13 June 2013 22:22:31 Jingoo Han wrote:
> > > +struct pcie_port {
> > > + struct device *dev;
> > > + u8
On Friday 14 June 2013 12:53:11 Thierry Reding wrote:
>
> I think the biggest missing piece is pci_common_exit(), the counterpart
> of pci_common_init(), to cleanup a host bridge on ARM. I haven't looked
> in detail at the other architectures, but I suspect there must be some
> code to call when a
On Thursday 13 June 2013 22:18:50 Jingoo Han wrote:
> On Wednesday, June 12, 2013 8:23 PM, Arnd Bergmann wrote:
> > On Wednesday 12 June 2013 19:19:05 Jingoo Han wrote:
> > > +
> > > +/* synopsis specific PCIE configuration registers*/
> > > +#define PC
On Thursday 13 June 2013 22:22:31 Jingoo Han wrote:
> +struct pcie_port_info {
> + u32 cfg0_size;
> + u32 cfg1_size;
> + u32 io_size;
> + u32 mem_size;
> + phys_addr_t io_bus_addr;
> + phys_addr_t mem_bus_addr;
> +};
>
On Thursday 13 June 2013, Arnd Bergmann wrote:
> Yes, I realize that, which is why I said it depends on the actual sizes.
> If you have a lot of windows that are all the same size and nothing larger,
> the worst case isn't too bad.
Also, if the available space is a naturally a
On Thursday 13 June 2013, Jason Gunthorpe wrote:
> On Wed, Jun 12, 2013 at 11:52:32PM +0200, Arnd Bergmann wrote:
> > Whether that results in an optimum mapping or not depends on the actual
> > sizes for the child nodes. Since everything is a power-of-two size,
> > a first-f
On Wednesday 12 June 2013, Ezequiel Garcia wrote:
> Right. And just to confirm: this kernel side dynamic implementation
> will be completely independent of the MBus DT layout proposal.
> So I think it's best to agree on this binding first.
>
> I'll post a v2 with the progress I've made using the p
On Wednesday 12 June 2013, Ezequiel Garcia wrote:
> #define INTERNAL_REGS INTERNAL_REGS_ID 0
> #define DEVBUS_BOOTCS 0x012f 0
> #define BOOTROM 0x01e0 0
>
> #define INTERNAL_REGS_BASE 0 0xd000
> #define DEVBUS_BOOTCS_BASE 0 0xf000
> #define BOOTROM_BASE 0 0xfff0
> .
On Wednesday 12 June 2013, Grant Likely wrote:
> I think we should have almost everything needed already to do this.
> of_bus allows arbitrary mapping code to be used at any stage in the
> translation. We might need to add some glue so that of_busses[] can
> be assembled by the linker to allow an m
On Tuesday 11 June 2013, Jingoo Han wrote:
> > > + ranges = <0x0800 0 0x4000 0x4000 0 0x0020
> > > /* configuration space */
> > > + 0x8100 0 0 0x4020 0 0x4000
> > > /* downstream I/O */
> > > + 0x8200
On Wednesday 12 June 2013, Jingoo Han wrote:
> On Friday, June 07, 2013 7:53 PM, Arnd Bergmann wrote:
> > On Friday 07 June 2013 18:22:50 Jingoo Han wrote:
> >
> > > +- ranges: ranges for the PCI memory and I/O regions
> > > +- reset-gpio: gpio pin number of powe
On Wednesday 12 June 2013 12:54:59 Grant Likely wrote:
>
> > * These are SoC-wide registers including the UART and other things, not
> > just the mbus setup
> > * There are at least two different values used for the internal-regs
> > mapping address depending on the SoC and boot loader version
On Wednesday 12 June 2013 12:07:46 Grant Likely wrote:
>
> It actually seems a bit silly to put the internal regs into the ranges
> property at all. It's not like they need to be translated or provided to
> any child nodes. Just give the root node a reg property with the correct
> base for the int
On Wednesday 12 June 2013 19:19:05 Jingoo Han wrote:
> +
> +struct pcie_port {
> + struct device *dev;
> + u8 controller;
> + u8 root_bus_nr;
> + void __iomem*dbi_base;
> + void __iomem*elbi_base;
> +
Thanks for the update! A few comments again:
On Wednesday 12 June 2013 19:20:00 Jingoo Han wrote:
>
> diff --git a/arch/arm/boot/dts/exynos5440-ssdk5440.dts
> b/arch/arm/boot/dts/exynos5440-ssdk5440.dts
> index d55042b..efe7d39 100644
> --- a/arch/arm/boot/dts/exynos5440-ssdk5440.dts
> +++ b/arc
On Tuesday 11 June 2013 16:58:41 Jason Gunthorpe wrote:
> On Wed, Jun 12, 2013 at 12:34:14AM +0200, Arnd Bergmann wrote:
>
> > a significant waste of physical address space, because the (per-soc)
> > ranges property has to be set up for the largest possible external
> >
On Wednesday 12 June 2013 00:22:29 Sebastian Hesselbarth wrote:
>
> When removing size from marvell,mbus-target above, mbus driver could
> also probe for required max size from the reg properties of the child
> nodes. Arnd already said that mbus isn't "simple-bus" anymore, why
> can't it just walk
On Tuesday 11 June 2013 15:50:23 Jason Gunthorpe wrote:
> On Tue, Jun 11, 2013 at 05:26:47PM +0200, Arnd Bergmann wrote:
>
> > That looks ok to me, yes. If you have just one device under some of the
> > nodes
> > however, I think it's easier use an
On Tuesday 11 June 2013 10:57:38 Ezequiel Garcia wrote:
> Jason, Arnd:
>
> On Sat, Jun 08, 2013 at 07:45:06PM -0600, Jason Gunthorpe wrote:
> [...]
> >
> > This is the mangling I was referring to. It needs to be the offset
> > into the target, it can't be something else.
> >
>
> I see both of y
On Tuesday 11 June 2013 10:31:45 Ezequiel Garcia wrote:
> > > +
> > > + soc {
> > > + bootrom {
> > > + ranges = <0 0x01e0 0xfff0 0x10>;
> > > + };
> > > + };
> >
> > I think I'm a bit lost here. Is the "soc" node in this example the node
> > t
On Monday 10 June 2013, Jingoo Han wrote:
> On Saturday, June 08, 2013 2:43 AM, Arnd Bergmann wrote:
> For multiple domains, how can I fix the DT properties?
Domains are a Linux concept, you have to pick a new domain number for each
struct hw_pci you register.
> Current DT properti
On Monday 10 June 2013 14:52:38 Srinivas KANDAGATLA wrote:
> On 10/06/13 14:16, Linus Walleij wrote:
> > On Mon, Jun 10, 2013 at 11:22 AM, Srinivas KANDAGATLA
> > wrote:
> >
> >> This mfd driver provides higher level inialization routines for various
> >> IPs like Ethernet, USB, PCIE, SATA and so
On Monday 10 June 2013 10:27:05 Srinivas KANDAGATLA wrote:
> + soc {
> + pin-controller-sbc {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + compatible = "st,stih416-pinctrl", "simple-bus";
Why is this bot
On Sunday 09 June 2013 11:34:24 Ezequiel Garcia wrote:
> On Sun, Jun 09, 2013 at 03:42:24PM +0200, Arnd Bergmann wrote:
> > On Saturday 08 June 2013 15:38:52 Ezequiel Garcia wrote:
> > > On Fri, Jun 07, 2013 at 02:00:54PM -0600, Jason Gunthorpe wrote:
> >
> > > R
On Sunday 09 June 2013, Linus Walleij wrote:
> + /*
> +* IP AMBA bus clocks, driving the bus side of the
> +* peripheral clocking, clock gates.
> +*/
> +
> + hclkdma0: hclkdma0@48M {
> + #clock-cells =
1 - 100 of 945 matches
Mail list logo
