Alexander Popov wrote:
+struct mpc512x_lpbfifo_request {
+ phys_addr_t bus_phys; /* physical address of some device on LPB */
Is this a phys_addr_t or a dma_addr_t? It can't be both a physical
address and a bus address.
+ void *ram_virt; /* virtual address of some reg
Alexander Popov wrote:
The only question I have: why calling dma_unmap_single() from within
a spinlock is a bad practice?
I don't know, but usually functions that allocate or free memory cannot
be called from within a spinlock. You need to check that. Since the
MPC5121 is a single-core CPU,
Alexander Popov wrote:
I've just followed devicetree/bindings/dma/dma.txt...
This "rx-tx" doesn't mean much but it could show that LocalPlus Bus FIFO
uses a single DMA read-write channel. Should I really drop it?
Hmmm, I'm not sure. Is there anything else (besides your driver) that
parses thi
On 09/30/2015 04:24 PM, Alexander Popov wrote:
Can you test for "!cs" here instead?
+e = -EFAULT;
+goto err_param;
+}
Unfortunately no: 0 is a valid value for Chip Select.
Is it OK to leave it like that?
Yes.
+lpbfifo.ram_bus_addr = sg_dma_address(&sg); /* For fre
Gerlando Falauto wrote:
Change-Id: If1e7d8931f440ea9259726c36d3df797dda016fb
You need to remove these from patches that are emailed, and fix the
pointer type comparison.
Otherwise,
Acked-by: Timur Tabi
___
Linuxppc-dev mailing list
Linuxppc-dev
On Thu, Dec 3, 2015 at 6:08 AM, <> wrote:
> From: Madalin Bucur
>
> This patch series adds the Ethernet driver for the Freescale
> QorIQ Data Path Acceleration Architecture (DPAA).
Please fix your git-send-email configuration, so that your emails are
formatted properly. This is the From: header
On Sun, Dec 20, 2015 at 2:30 PM, Maciej S. Szmigiero
wrote:
> SACNT register should be marked volatile since
> its WR and RD bits are cleared by SSI after
> completing the relevant operation.
> This unbreaks AC'97 register access.
>
> Fixes: 05cf237972fe ("ASoC: fsl_ssi: Add driver suspend and res
Maciej S. Szmigiero wrote:
+ regmap_write(regs, CCSR_SSI_SACNT,
+ ssi_private->regcache_sacnt);
So I'm not familiar with all of the regcache features, but I understand
this patch. I was wondering if it makes sense to write the same exact
value that was read previo
Maciej S. Szmigiero wrote:
Mark some registers precious since their
reads have side effects (like clearing flags).
Signed-off-by: Maciej S. Szmigiero
Acked-by: Timur Tabi
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https
in AC'97 mode.
Fixes: 05cf237972fe ("ASoC: fsl_ssi: Add driver suspend and resume to support MEGA
Fast")
Signed-off-by: Maciej S. Szmigiero
Acked-by: Timur Tabi
I'm surprised that we're actually encouraging drivers to contain
h
Mark Brown wrote:
That's possibly problematic because the flat cache will of necessity end
up with defaults (of 0 from the kzalloc()) for all the registers.
You'll still have default values in the cache, though some of the
behaviour around optimising syncs does change without them explicitly
give
Mark Brown wrote:
regcache handles this fine, it's perfectly happy to just go and allocate
the cache as registers get used (this is why the code that's doing the
allocation exists...). What is causing problems here is that the first
access to the register is happening in interrupt context so we
Mark Brown wrote:
Quite possibly (it'll be more efficient and it's intended for such use
cases) but as I said in my other reply that then has the issue that it
implicitly gives default values to all the registers so I'd expect we
still need to handle the cache initialisation explicitly (or
altern
Lothar Waßmann wrote:
- select SND_SOC_FSL_SSI
+ select SND_SOC_FSL_SAI if SOC_IMX6UL
+ select SND_SOC_FSL_SSI if SOC_IMX6Q || SOC_IMX6SL || SOC_IMX6SX
I don't think this is compatible with a multiarch kernel.
___
Linuxppc-dev mailin
Lothar Waßmann wrote:
Why? If more than one of the IMX6 SoCs are selected, both interfaces
may be selected at the same time without any harm.
Oh, ok. I thought the point behind the patch was that you *souldn't*
enable the the SSI driver on an i.MX6UL.
Maciej S. Szmigiero wrote:
+static const struct regmap_config fsl_ssi_regconfig_imx21 = {
+ .max_register = CCSR_SSI_SRMSK,
+ .reg_bits = 32,
+ .val_bits = 32,
+ .reg_stride = 4,
+ .val_format_endian = REGMAP_ENDIAN_NATIVE,
+ .num_reg_defaults_raw = CCSR_SSI_SR
Maciej S. Szmigiero wrote:
This is because (at least according to the datasheet) imx21-class SSI
registers end at CCSR_SSI_SRMSK (no SACC{ST,EN,DIS} regs), so
reading them for cache initialization may not be safe.
Also, a "MXC 91221 only" comment before these regs in FSL tree
(drivers/mxc/ssi/re
Maciej S. Szmigiero wrote:
On 17.01.2016 15:16, Maciej S. Szmigiero wrote:
On 17.01.2016 06:16, Timur Tabi wrote:
Maciej S. Szmigiero wrote:
This is because (at least according to the datasheet) imx21-class SSI
registers end at CCSR_SSI_SRMSK (no SACC{ST,EN,DIS} regs), so
reading them for
On 2/27/19 11:56 PM, S.j. Wang wrote:
cs42xx8 is a 24-bit A/D and 24-bit D/A device, so the S32_LE
should not be in the supported format list.
Signed-off-by: Shengjiu Wang
Is the device capable of accepting 32-bit samples, even if it downgrades
it to 24-bit internally? If so, then maybe SNDR
On 3/1/19 12:32 AM, S.j. Wang wrote:
This case is covered by S24_LE I think. The S32_LE means the data is 32bit and
slot width
Is 32bit, this is not in data sheet.
The problem is that if you have 32-bit samples in your audio file, and
you want to play them, then software (e.g. alsalib) will
On Fri, Nov 8, 2019 at 7:03 AM Rasmus Villemoes
wrote:
>
> The QUICC engine drivers use the powerpc-specific out_be32() etc. In
> order to allow those drivers to build for other architectures, those
> must be replaced by iowrite32be(). However, on powerpc, out_be32() is
> a simple inline function
On 11/12/19 1:14 AM, Rasmus Villemoes wrote:
but that's because readl and writel by definition work on little-endian
registers. I.e., on a BE platform, the readl and writel implementation
must themselves contain a swab, so the above would end up doing two
swabs on a BE platform.
Do you know whe
On Fri, Nov 8, 2019 at 7:03 AM Rasmus Villemoes
wrote:
>
> - /*
> -* Determine if we need Soft-UART mode
> -*/
> if (of_find_property(np, "soft-uart", NULL)) {
> dev_dbg(&ofdev->dev, "using Soft-UART mode\n");
> soft_uart = 1;
> +
On Fri, Nov 8, 2019 at 7:03 AM Rasmus Villemoes
wrote:
>
> - if (*iprop)
> - qe_port->port.uartclk = *iprop;
> + if (val)
> + qe_port->port.uartclk = val;
> else {
> /*
> * Older versions of U-Boot do not initialize t
On Fri, Nov 8, 2019 at 7:03 AM Rasmus Villemoes
wrote:
>
> + if (of_property_read_u32(np, "cell-index", &val) &&
> + of_property_read_u32(np, "device-id", &val)) {
I know that this is technically correct, but it's obfuscated IMHO.
'val' is set correctly only when of_property_read_
On Fri, Nov 8, 2019 at 7:04 AM Rasmus Villemoes
wrote:
>
> Currently, QUICC_ENGINE depends on PPC32, so this in itself does not
> change anything. In order to allow removing the PPC32 dependency from
> QUICC_ENGINE and avoid allmodconfig build failures, add this explicit
> dependency.
Can you add
On Fri, Nov 8, 2019 at 7:04 AM Rasmus Villemoes
wrote:
> diff --git a/drivers/net/wan/fsl_ucc_hdlc.c b/drivers/net/wan/fsl_ucc_hdlc.c
> index 8d13586bb774..f029eaa7cfc0 100644
> --- a/drivers/net/wan/fsl_ucc_hdlc.c
> +++ b/drivers/net/wan/fsl_ucc_hdlc.c
> @@ -245,6 +245,11 @@ static int uhdlc_ini
On Fri, Nov 8, 2019 at 7:04 AM Rasmus Villemoes
wrote:
>
> +static bool qe_general4_errata(void)
> +{
> +#ifdef CONFIG_PPC32
> + return pvr_version_is(PVR_VER_836x) || pvr_version_is(PVR_VER_832x);
> +#endif
> + return false;
> +}
> +
> /* Program the BRG to the given sampling rate an
On 11/14/19 11:44 PM, Li Yang wrote:
Can you add an explanation why we don't want ucc_geth on non-PowerPC platforms?
I think it is because the QE Ethernet was never integrated in any
non-PowerPC SoC and most likely will not be in the future. We
probably can make it compile for other architectur
On 11/15/19 1:54 AM, Rasmus Villemoes wrote:
"Also, the QE Ethernet has never been integrated on any non-PowerPC SoC
and most likely will not be in the future."
That works for me, thanks.
On 11/15/19 1:44 AM, Rasmus Villemoes wrote:
I can change it, sure, but it's a matter of taste. To me the above asks
"does the value change when it is truncated to a u16" which makes
perfect sense when the value is next used with iowrite16be(). Using a
comparison to U16_MAX takes more brain cycle
On 11/15/19 2:01 AM, Rasmus Villemoes wrote:
That would be a separate patch, this patch is only concerned with
eliminating the implicit assumption of the host being big-endian. And
there's already been some pushback to adding arch-specific ifdefs (which
I agree with, but as I responded there see
...@rasmusvillemoes.dk/
This is excellent work, thank you.
All patches:
Reviewed-by: Timur Tabi
Serial patches:
Acked-by: Timur Tabi
...@rasmusvillemoes.dk/
If it helps:
Entire series:
Acked-by: Timur Tabi
I've worked on all code covered by this patchset except for the hdlc
driver. I don't know if my ACKs are acceptable to everyone, but you
have them regardless.
Colin Ian King
Acked-by: Timur Tabi
Looks like this bug has been there since day 1.
On 1/13/20 6:26 AM, Michael Ellerman wrote:
I've never heard of it, and I have no idea how to test it.
It's not used by qemu, I guess there is/was a Freescale hypervisor that
used it.
Yes, there is/was a Freescale hypervisor that I and a few others worked
on. I've added a couple people on CC
On 1/13/20 8:34 AM, Laurentiu Tudor wrote:
There are a few users that I know of, but I can't tell if that's enough
to justify keeping the driver.
[1]https://source.codeaurora.org/external/qoriq/qoriq-yocto-sdk/hypervisor/
IIRC, the driver is the only reasonable way to get a serial console from
On Thu, Jan 9, 2020 at 1:41 AM Stephen Rothwell wrote:
>
> ev_byte_channel_send() assumes that its third argument is a 16 byte array.
> Some places where it is called it may not be (or we can't easily tell
> if it is). Newer compilers have started producing warnings about this,
> so make sure we
On 1/13/20 2:25 PM, Stephen Rothwell wrote:
The problem is not really the declaration, the problem is that
ev_byte_channel_send always accesses 16 bytes from the buffer and it is
not always passed a buffer that long (in one case it is passed a
pointer to a single byte). So the alternative to the
On 1/13/20 7:10 PM, Timur Tabi wrote:
I would prefer that ev_byte_channel_send() is updated to access only
'count' bytes. If that means adding a memcpy to the
ev_byte_channel_send() itself, then so be it. Trying to figure out how
to stuff n bytes into 4 32-bit registers is pr
On 1/14/20 5:00 AM, Laurentiu Tudor wrote:
Michael Ellerman made a call for volunteers from NXP to maintain
this driver and I offered myself.
Signed-off-by: Laurentiu Tudor
Acked-by: Timur Tabi
On 1/14/20 3:18 AM, Laurentiu Tudor wrote:
I can offer myself. I'll send a MAINTAINERS patch if nobody is against it.
Yes, please do. I'm always available if you have any questions on the code.
On 1/14/20 2:29 AM, Segher Boessenkool wrote:
You have no working lswx I suppose?:-)
I don't know if the P4080 supports lswx, but it does, than that would be
an elegant way to fix this bug.
On 1/14/20 12:31 AM, Stephen Rothwell wrote:
+/**
+ * ev_byte_channel_send - send characters to a byte stream
+ * @handle: byte stream handle
+ * @count: (input) num of chars to send, (output) num chars sent
+ * @bp: pointer to chars to send
+ *
+ * Returns 0 for success, or an error code.
+ */
+
On 1/15/20 2:01 PM, Scott Wood wrote:
FWIW I'd rather see the original patch,
that keeps the raw asm hcall stuff as simple wrappers in one place.
I can live with that.
On 1/21/20 3:09 PM, Heiner Kallweit wrote:
drivers/net/ethernet/qualcomm/emac/emac.c | 14 +-
Acked-by: Timur Tabi
s zero anyway.
2) Rename msi_addr_lo to ccsr_msiir_offset, to indicate that it's an offset
relative to the beginning of CCSR.
3) Calculate 64-bit addresses using actual 64-bit math.
4) Document some of the code and assumptions we make.
Signed-off-by: Timur Tabi
---
arch/powerpc/sysdev/fsl_m
to create common compatibility strings.
Signed-off-by: Timur Tabi
---
Changes for other Freescale boards will be made in future patches.
.../devicetree/bindings/powerpc/fsl/board.txt | 30
arch/powerpc/boot/dts/p1010rdb.dts | 10 ++
arch/powerpc
Audio support for the MPC5200 exists, so enable it by default.
Signed-off-by: Timur Tabi
---
There was a bug in the audio drivers related to the of_platform
changes that was never discovered because these drivers were
never compiled by default. This patch should make sure that
never happens
Commit 6820fead ("powerpc/fsl_msi: Handle msi-available-ranges better") added
support for multiple ranges in the msi-available-ranges property, but it
miscalculated the MSIR index when multiple ranges are used.
Signed-off-by: Timur Tabi
---
arch/powerpc/sysdev/fsl_msi.c |8 +--
of FPGA, most of the
functionality is the same, so it makes sense to create common compatibility
strings.
Signed-off-by: Timur Tabi
---
v2: removed references to the CPLD
This patch applies on top of "[PATCH 3/4] powerpc/p3060qds: Add support for
P3060QDS board", but it also assumes that
Kumar Gala wrote:
> What happened to looking at pixis vs ngpixis ?
Doh, I knew I was forgetting something.
--
Timur Tabi
Linux kernel developer at Freescale
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listi
Gala Kumar-B11780 wrote:
> I pulling the p3060qds bit out so drop that change from next patch.
>
Ok, I'm thinking it should look like this:
compatible = "fsl,p3060qds-fpga", "fsl,fpga-qixis";
--
Timur Tabi
Linu
,p3060qds-qixis", "fsl,fpga-qixis";
looks kinda dumb.
--
Timur Tabi
Linux kernel developer at Freescale
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
ice trees. This is not a real problem, however,
since that particular function doesn't work anyway. When the DIU is active,
the PIXIS is in "indirect mode", and so cannot be accessed as a memory-mapped
device.
Signed-off-by: Timur Tabi
---
v3: added "ngpixis" to list
v
ware support registered
If I disable performance counter support, it just stops at the "Mount-cache hash
table entries: 256" line.
--
Timur Tabi
Linux kernel developer at Freescale
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
ather than fix
the warning, we just eliminate the code altogether.
Signed-off-by: Timur Tabi
---
drivers/tty/ehv_bytechan.c |7 ++-
1 files changed, 2 insertions(+), 5 deletions(-)
diff --git a/drivers/tty/ehv_bytechan.c b/drivers/tty/ehv_bytechan.c
index e67f70b..b24e6f7 100644
--- a/drive
Greg KH wrote:
> This patch doesn't apply at all to my tty tree, what was it made
> against?
An internal repository that supposed to be in-sync with the latest and greatest.
What's the URL for your tty-next repo?
--
Timur Tabi
Linux kernel develo
lobal variable.
Signed-off-by: Timur Tabi
---
drivers/tty/ehv_bytechan.c |7 ++-
1 files changed, 2 insertions(+), 5 deletions(-)
diff --git a/drivers/tty/ehv_bytechan.c b/drivers/tty/ehv_bytechan.c
index f733718..1595dba 100644
--- a/drivers/tty/ehv_bytechan.c
+++ b/drivers/tty/ehv_bytec
ct fsl_msi were redefined
from an actual address to just an offset, but the fields were not renamed
accordingly. These fields are replace with a single field, msiir_offset,
to reflect the new meaning.
Signed-off-by: Timur Tabi
---
This patch is necessary, but not sufficient, for MSI support
That's why they
like to keep 32-bit and 36-bit environments for both, and why they default to
32-bit.
--
Timur Tabi
Linux kernel developer at Freescale
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Geert Uytterhoeven wrote:
> You deleted this part:
>
> config PHYS_ADDR_T_64BIT
>def_bool 64BIT || ARCH_PHYS_ADDR_T_64BIT
>
> which enforces that PHYS_ADDR_T_64BIT is enabled if 64BIT is set.
Ok, I didn't catch that before, but it makes sense now. Thanks.
--
orry, but I have to strongly disagree here. It is *NOT* clear that a
variable of type 'phys_addr_t' can hold something that is not a physical
address.
--
Timur Tabi
Linux kernel developer at Freescale
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
op performance by up to 25% in some situations? We talked about that on
an internal mailing list several months ago.
--
Timur Tabi
Linux kernel developer at Freescale
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
mment added to the structure definition. I
don't think that's asking a lot.
--
Timur Tabi
Linux kernel developer at Freescale
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
ion, but I don't understand why
you couldn't do that when you applied the patch.
--
Timur Tabi
Linux kernel developer at Freescale
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
om creating a 32-bit kernel.
This is my problem with the patch.
--
Timur Tabi
Linux kernel developer at Freescale
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
c.dtsi
or si.dtsi file can re-enable them?
--
Timur Tabi
Linux kernel developer at Freescale
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Kumar Gala wrote:
> I would have hoped the bindings had made it clear already what was board info
> vs what was SoC.
When it comes to device trees, I never assume anything is "clear".
> If not, they should be clarify that in the binding specs.
I'm okay with that.
--
of the PCI bus for that device. If it exists, then as we are looping over
all MSI devices, we skip the ones that don't have a matching phandle.
Signed-off-by: Timur Tabi
---
arch/powerpc/sysdev/fsl_msi.c | 33 +
1 files changed, 33 insertions(+), 0 deleti
of the PCI bus for that device. If it exists, then as we are looping over
all MSI devices, we skip the ones that don't have a matching phandle.
Signed-off-by: Timur Tabi
---
arch/powerpc/sysdev/fsl_msi.c | 33 +
arch/powerpc/sysdev/fsl_msi.h |3 +++
of the PCI bus for that device. If it exists, then as we are looping over
all MSI devices, we skip the ones that don't have a matching phandle.
Signed-off-by: Timur Tabi
---
v3: added check for invalid fsl,msi phandles
arch/powerpc/sysdev/fsl_msi.c | 39 +
On Nov 3, 2011, at 7:16 AM, David Laight wrote:
> Arithmetic on 'void *' should not be done. I know some versions of
> gcc allow it (provided some warning level/option is enabled) but
> that doesn't mean it is valid.
> My suspicions are that is was allowed due to the way 'void *'
> was originally
ned-off-by: Timur Tabi
---
arch/powerpc/configs/corenet32_smp_defconfig |1 +
arch/powerpc/platforms/85xx/Kconfig |5 -
2 files changed, 1 insertions(+), 5 deletions(-)
diff --git a/arch/powerpc/configs/corenet32_smp_defconfig
b/arch/powerpc/configs/corenet32_smp_defco
o the Kconfig of each board doesn't sound like
the best way to enforce this.
--
Timur Tabi
Linux kernel developer at Freescale
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
ned-off-by: Timur Tabi
---
arch/powerpc/platforms/85xx/Kconfig |1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/platforms/85xx/Kconfig
b/arch/powerpc/platforms/85xx/Kconfig
index 12f5932..dddada4 100644
--- a/arch/powerpc/platforms/85xx/Kconfig
+++ b/ar
emory above 4GB.
Item #2 is not something that we really worry about. It's only a real problem
on true 64-bit kernels, and in those cases, we cannot build a kernel with
32-bit phys support, so the driver needs to handle it internally.
--
Timur Tabi
Linux kernel developer at Freescale
_
bit kernels on our high-end parts. Like
I said, I'm not a fan of that decision.
> I don't know about the other platforms well
> enough to tell what would break by enabling PHYS_64BIT, but I assume
> that something in the past caused that dependency list.
It's just
property:
ranges = <0x0 0x0 0xf 0xe800 0x0800
0x1 0x0 0xf 0xe000 0x0800
0x2 0x0 0x0 0xffa0 0x0004
^^^
0x3 0x0 0xf 0xffdf 0x8000>;
--
Kumar Gala wrote:
>> > Acked-by: Timur Tabi
> How about a Tested-by:
I did test it.
Tested-by: Timur Tabi
--
Timur Tabi
Linux kernel developer at Freescale
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://list
e introduce another board-control child node of the
localbus node that contains a 'reg' property for CS0 and CS1. This will
produce the correct physical addresses for CS0 and CS1.
Signed-off-by: Timur Tabi
---
arch/powerpc/boot/dts/p1022ds.dts | 14 ++
1 files changed, 14
side-effect of no longer requiring U-Boot to enable the DIU.
Now Linux can enable the DIU all by itself.
Signed-off-by: Timur Tabi
---
arch/powerpc/platforms/85xx/p1022_ds.c | 132 ++-
1 files changed, 110 insertions(+), 22 deletions(-)
diff --git a/arch/powerpc
you had multiple error path labels, you could avoid these others
> as well (and the NULL checks on the error path).
But I don't want multiple error path labels. The error path could only happen
if someone passed in a broken device tree (i.e. pretty much never), so I'm not
keen on
DIU are incompatible, and yet that's exactly what we ship on the P1022DS
board. We could just remove the NOR flash node from the DTS.
--
Timur Tabi
Linux kernel developer at Freescale
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
; Or, have U-boot set up the desired mode before entering the kernel, and
> provide an appropriate device tree.
I can both of these features, but not in this patch.
--
Timur Tabi
Linux kernel developer at Freescale
___
Linuxppc-dev maili
ned? I'd like to fixup the tree in an early_param()
function.
--
Timur Tabi
Linux kernel developer at Freescale
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
e introduce another board-control child node of the
localbus node that contains a 'reg' property for CS0 and CS1. This will
produce the correct physical addresses for CS0 and CS1.
Signed-off-by: Timur Tabi
---
arch/powerpc/boot/dts/p1022ds.dts | 14 ++
1 files changed, 14
the pixis FPGA.
Therefore, if the DIU is going to be enabled, then memory-mapped devices on
the localbus, like NOR flash, need to be disabled.
Signed-off-by: Timur Tabi
---
arch/powerpc/platforms/85xx/p1022_ds.c | 70
1 files changed, 70 insertions(+), 0 deletions
side-effect of no longer requiring U-Boot to enable the DIU.
Now Linux can enable the DIU all by itself.
Signed-off-by: Timur Tabi
---
arch/powerpc/platforms/85xx/p1022_ds.c | 132 ++-
1 files changed, 110 insertions(+), 22 deletions(-)
diff --git a/arch/powerpc
Scott Wood wrote:
> What's wrong with doing it in setup_arch()?
Well, I was hoping to encapsulate everything into one function -- the
early_param() callback function. But I guess that's not going to work.
--
Timur Tabi
Linux kernel developer
stions.
However, considering that I'm modifying my own code, I would hope that you can
appreciate my personal coding style preference. And my style is to reduce the
number of labels, even if it means superfluous checks in the exit code.
So Kumar, if there are no further objections, please apply th
roblem with the other two PCI busses. It looks like the
physical address is correct, but the BUS address is wrong (it's using the
32-bit bus address instead of the 36-bit bus address).
--
Timur Tabi
Linux kernel developer at Freescale
_
it's scanned everything else first.
I'm trying to debug it now.
--
Timur Tabi
Linux kernel developer at Freescale
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Timur Tabi wrote:
> If I move the "fsl,eloplus-dma" into mpc85xx_common_ids[], then everything
> works.
>
> I suspect there's some kind of state machine in of_platform_bus_probe() that
> allows it to find the DMA channel nodes if it's scanned everything els
latform_bus_create() is part of
the problem.
The only fix I can think of is to move "fsl,eloplus-dma" into
mpc85xx_common_ids[]. I'll post a patch that does that, and we can discuss it.
--
Timur Tabi
Linux kernel developer at Freescale
___
uplicate filename '/devices/e0005000.localbus'
because we end up duplicating probes.
--
Timur Tabi
Linux kernel developer at Freescale
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
ecific)
call to of_platform_bus_probe() never finds any of the busses it's asked
to find.
To remedy this, the platform-specific of_device_id tables are eliminated,
and their entries are merged into mpc85xx_common_ids[], so that all busses
are probed at once.
Signed-off-by: Timur Tabi
---
arch/powerpc/pla
ice tree"), the I2C nodes are
unintentionally reversed in the device tree, and so the machine driver
guesses the wrong I2C adapter number.
Signed-off-by: Timur Tabi
---
drivers/i2c/busses/i2c-mpc.c | 14 +-
1 files changed, 13 insertions(+), 1 deletions(-)
diff --git a/drivers/
Scott Wood wrote:
> On 12/01/2011 11:33 AM, Timur Tabi wrote:
>> An I2C device tree node can contain a 'cell-index' property that can be
>> used to enumerate the I2C devices. If such a property exists, use it
>> to specify the I2C adapter number.
>
> Didn&
a way to get a "struct device" from "struct device_node",
> we should add it.
How do I do that? Scan all the struct devices until I find one where
dev->of_node == np? That seems really inefficient.
--
Timur Tabi
Linux kernel developer at Freescale
_
101 - 200 of 1189 matches
Mail list logo
