* Re: [PATCH 6/9] fs_enet: Be an of_platform device when CONFIG_PPC_CPM_NEW_BINDING is set.
From: Laurent Pinchart @ 2008-02-15 12:50 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Scott Wood, netdev, jgarzik
In-Reply-To: <20070920220121.GF28784@loki.buserror.net>
[-- Attachment #1: Type: text/plain, Size: 1979 bytes --]
Hi Scott,
I apologize for bringing this after so much time. Hope the "better late than
never" motto applies.
On Friday 21 September 2007 00:01, Scott Wood wrote:
> The existing OF glue code was crufty and broken. Rather than fix it, it
> will be removed, and the ethernet driver now talks to the device tree
> directly.
>
> The old, non-CONFIG_PPC_CPM_NEW_BINDING code can go away once CPM
> platforms are dropped from arch/ppc (which will hopefully be soon), and
> existing arch/powerpc boards that I wasn't able to test on for this
> patchset get converted (which should be even sooner).
>
> Signed-off-by: Scott Wood <scottwood@freescale.com>
[snip]
> diff --git a/drivers/net/fs_enet/fs_enet.h b/drivers/net/fs_enet/fs_enet.h
> index f8c7ee8..14ebba8 100644
> --- a/drivers/net/fs_enet/fs_enet.h
> +++ b/drivers/net/fs_enet/fs_enet.h
> @@ -24,19 +24,6 @@ struct fec_info {
> #include <asm/cpm2.h>
> #endif
>
> -/* This is used to operate with pins.
> - Note that the actual port size may
> - be different; cpm(s) handle it OK */
> -struct bb_info {
> - u8 mdio_dat_msk;
> - u8 mdio_dir_msk;
> - u8 *mdio_dir;
> - u8 *mdio_dat;
> - u8 mdc_msk;
> - u8 *mdc_dat;
> - int delay;
> -};
> -
[snip]
> diff --git a/drivers/net/fs_enet/mii-bitbang.c
> b/drivers/net/fs_enet/mii-bitbang.c index 8f766a5..2b9c44c 100644
> --- a/drivers/net/fs_enet/mii-bitbang.c
> +++ b/drivers/net/fs_enet/mii-bitbang.c
[snip]
> +struct bb_info {
> + __be32 __iomem *dir;
> + __be32 __iomem *dat;
> + u32 mdio_msk;
> + u32 mdc_msk;
> + int delay;
> +};
We're loosing the possibility of having MDC and MDIO on different ports. This
is quite easy to fix for the non-CONFIG_PPC_CPM_NEW_BINDING case but I'm not
familiar with OF bindings (yet) to fix the CONFIG_PPC_CPM_NEW_BINDING case.
--
Laurent Pinchart
CSE Semaphore Belgium
Chaussée de Bruxelles, 732A
B-1410 Waterloo
Belgium
T +32 (2) 387 42 59
F +32 (2) 387 42 75
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* [PATCH] fs_enet: Remove unused fields in the fs_mii_bb_platform_info structure.
From: Laurent Pinchart @ 2008-02-15 13:27 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 1606 bytes --]
The mdio_port, mdio_bit, mdc_port and mdc_bit fields in the
fs_mii_bb_platform_info structure are left-overs from the move to the Phy
Abstraction Layer subsystem. They can be safely removed.
Signed-off-by: Laurent Pinchart <laurentp@cse-semaphore.com>
---
arch/powerpc/sysdev/fsl_soc.c | 4 ----
include/linux/fs_enet_pd.h | 4 ----
2 files changed, 0 insertions(+), 8 deletions(-)
diff --git a/arch/powerpc/sysdev/fsl_soc.c b/arch/powerpc/sysdev/fsl_soc.c
index 3ace747..cefc8b4 100644
--- a/arch/powerpc/sysdev/fsl_soc.c
+++ b/arch/powerpc/sysdev/fsl_soc.c
@@ -804,10 +804,6 @@ static int __init fs_enet_of_init(void)
mdio_bb_prop[1];
fs_enet_mdio_bb_data.mdc_dat.bit =
mdio_bb_prop[2];
- fs_enet_mdio_bb_data.mdio_port =
- mdio_bb_prop[3];
- fs_enet_mdio_bb_data.mdc_port =
- mdio_bb_prop[4];
fs_enet_mdio_bb_data.delay =
mdio_bb_prop[5];
diff --git a/include/linux/fs_enet_pd.h b/include/linux/fs_enet_pd.h
index 9bc045b..decc4b5 100644
--- a/include/linux/fs_enet_pd.h
+++ b/include/linux/fs_enet_pd.h
@@ -103,10 +103,6 @@ struct fs_mii_bb_platform_info {
struct fs_mii_bit mdio_dir;
struct fs_mii_bit mdio_dat;
struct fs_mii_bit mdc_dat;
- int mdio_port; /* port & bit for MDIO */
- int mdio_bit;
- int mdc_port; /* port & bit for MDC */
- int mdc_bit;
int delay; /* delay in us */
int irq[32]; /* irqs per phy's */
};
--
1.5.0
--
Laurent Pinchart
CSE Semaphore Belgium
Chaussée de Bruxelles, 732A
B-1410 Waterloo
Belgium
T +32 (2) 387 42 59
F +32 (2) 387 42 75
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply related
* [PATCH v2] [POWERPC] Enable correct operation of serial ports with nonzero regshift.
From: Pavel Kiryukhin @ 2008-02-15 13:30 UTC (permalink / raw)
To: linuxppc-dev
Add regshift reading to serial drivers.
This enables correct operation of serial ports with
nonzero regshift such as Xilinx opb 16550 uart.
Signed-off-by: Pavel Kiryukhin <pkiryukhin@ru.mvista.com>
arch/powerpc/kernel/legacy_serial.c | 6 +++++-
drivers/serial/of_serial.c | 6 ++++--
2 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/kernel/legacy_serial.c b/arch/powerpc/kernel/legacy_serial.c
index 61dd174..949e41c 100644
--- a/arch/powerpc/kernel/legacy_serial.c
+++ b/arch/powerpc/kernel/legacy_serial.c
@@ -50,7 +50,7 @@ static int __init add_legacy_port(struct device_node *np, int want_index,
phys_addr_t taddr, unsigned long irq,
upf_t flags, int irq_check_parent)
{
- const u32 *clk, *spd;
+ const u32 *clk, *spd, *regshift;
u32 clock = BASE_BAUD * 16;
int index;
@@ -62,6 +62,9 @@ static int __init add_legacy_port(struct device_node *np, int want_index,
/* get default speed if present */
spd = of_get_property(np, "current-speed", NULL);
+ /* get regshift if present*/
+ regshift = of_get_property(np, "reg-shift", NULL);
+
/* If we have a location index, then try to use it */
if (want_index >= 0 && want_index < MAX_LEGACY_SERIAL_PORTS)
index = want_index;
@@ -104,6 +107,7 @@ static int __init add_legacy_port(struct device_node *np, int want_index,
legacy_serial_ports[index].uartclk = clock;
legacy_serial_ports[index].irq = irq;
legacy_serial_ports[index].flags = flags;
+ legacy_serial_ports[index].regshift = regshift ? (u8)*regshift : 0;
legacy_serial_infos[index].taddr = taddr;
legacy_serial_infos[index].np = of_node_get(np);
legacy_serial_infos[index].clock = clock;
diff --git a/drivers/serial/of_serial.c b/drivers/serial/of_serial.c
index a64d858..3f09c5a 100644
--- a/drivers/serial/of_serial.c
+++ b/drivers/serial/of_serial.c
@@ -30,7 +30,7 @@ static int __devinit of_platform_serial_setup(struct of_device *ofdev,
{
struct resource resource;
struct device_node *np = ofdev->node;
- const unsigned int *clk, *spd;
+ const unsigned int *clk, *spd, *regshift;
int ret;
memset(port, 0, sizeof *port);
@@ -40,7 +40,7 @@ static int __devinit of_platform_serial_setup(struct of_device *ofdev,
dev_warn(&ofdev->dev, "no clock-frequency property set\n");
return -ENODEV;
}
-
+ regshift = of_get_property(np, "reg-shift", NULL);
ret = of_address_to_resource(np, 0, &resource);
if (ret) {
dev_warn(&ofdev->dev, "invalid address\n");
@@ -57,6 +57,8 @@ static int __devinit of_platform_serial_setup(struct of_device *ofdev,
| UPF_FIXED_PORT;
port->dev = &ofdev->dev;
port->custom_divisor = *clk / (16 * (*spd));
+ if (regshift)
+ port->regshift = *regshift;
return 0;
}
^ permalink raw reply related
* [PATCH] booting-without-of: add Xilinx uart 16550.
From: Pavel Kiryukhin @ 2008-02-15 13:40 UTC (permalink / raw)
To: linuxppc-dev
Add uart 16550 properties description to Xilinx portion of booting-without-of.txt
Signed-off-by: Pavel Kiryukhin <pkiryukhin@ru.mvista.com>
---
Documentation/powerpc/booting-without-of.txt | 16 ++++++++++++++--
1 files changed, 14 insertions(+), 2 deletions(-)
diff --git a/Documentation/powerpc/booting-without-of.txt b/Documentation/powerpc/booting-without-of.txt
index 7b4e8a7..dd77bbc 100644
--- a/Documentation/powerpc/booting-without-of.txt
+++ b/Documentation/powerpc/booting-without-of.txt
@@ -2575,10 +2575,22 @@ platforms are moved over to use the flattened-device-tree model.
Xilinx uartlite devices are simple fixed speed serial ports.
- Requred properties:
+ Required properties:
- current-speed : Baud rate of uartlite
- v) Xilinx hwicap
+ v) Xilinx Uart 16550
+
+ Xilinx uart 16550 device registers are compatible with all standard 16540
+ and 16550 UARTs.
+
+ Required properties:
+ - current-speed : Baud rate of uart.
+ - clock-frequency : Baud rate generator reference clock. May be driven
+ by OPB_Clk (100 MHz).
+ - reg-shift : registers offset shift (standard uart_port field).
+ Property is optional if regshift is zero.
+
+ vi) Xilinx hwicap
Xilinx hwicap devices provide access to the configuration logic
of the FPGA through the Internal Configuration Access Port
--
1.5.4.1
^ permalink raw reply related
* Re: dtc: Fold comment handling test into testsuite
From: Jon Loeliger @ 2008-02-15 14:12 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev
In-Reply-To: <20080215041416.GA6221@localhost.localdomain>
So, like, the other day David Gibson mumbled:
> For ages dtc has included a sample dts, comment-test.dts, for checking
> various lexical corner cases in comment processing. In fact, it
> predates the automated testsuite, and has never been integrated into
> it. This patch addresses this oversight, folding the comment handling
> test in with the rest of the testsuite.
>
> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Applied.
Thanks,
jdl
^ permalink raw reply
* Re: [PATCH] PPC440EP Interrupt Triggering and Level Settings
From: Josh Boyer @ 2008-02-15 15:12 UTC (permalink / raw)
To: Wolfgang Ocker; +Cc: linuxppc-dev
In-Reply-To: <1202671442.3384.15.camel@galileo.recco.de>
On Sun, 10 Feb 2008 20:24:02 +0100
Wolfgang Ocker <weo@reccoware.de> wrote:
> From: Wolfgang Ocker <weo@reccoware.de>
>
> Corrected IRQ triggering and level settings according to latest revision
> of the 440EP User Manual (rev 1.24 nov 16, 2007).
>
> The incorrect settings might cause a failure of the network if both
> onchip ethernet ports are under heavy load.
>
> Signed-off-by: Wolfgang Ocker <weo@reccoware.de>
Your patch is word-wrapped. I've gone ahead and fixed that up, but you
might want to figure that out for future patches.
josh
^ permalink raw reply
* Re: [PATCH] drivers/base: export gpl (un)register_memory_notifier
From: Christoph Raisch @ 2008-02-15 13:22 UTC (permalink / raw)
To: Dave Hansen
Cc: Thomas Q Klein, ossthema, Jan-Bernd Themann, Greg KH, apw,
linux-kernel, linuxppc-dev, Badari Pulavarty, netdev, tklein
In-Reply-To: <1203009163.19205.42.camel@nimitz.home.sr71.net>
Dave Hansen <haveblue@us.ibm.com> wrote on 14.02.2008 18:12:43:
> On Thu, 2008-02-14 at 09:46 +0100, Christoph Raisch wrote:
> > Dave Hansen <haveblue@us.ibm.com> wrote on 13.02.2008 18:05:00:
> > > On Wed, 2008-02-13 at 16:17 +0100, Jan-Bernd Themann wrote:
> > > > Constraints imposed by HW / FW:
> > > > - eHEA has own MMU
> > > > - eHEA Memory Regions (MRs) are used by the eHEA MMU to translate
> > virtual
> > > > addresses to absolute addresses (like DMA mapped memory on a PCI
bus)
> > > > - The number of MRs is limited (not enough to have one MR per
packet)
> > >
> > > Are there enough to have one per 16MB section?
> >
> > Unfortunately this won't work. This was one of our first ideas we
tossed
> > out,
> > but the number of MRs will not be sufficient.
>
> Can you give a ballpark of how many there are to work with? 10? 100?
> 1000?
>
It depends on HMC configuration, but in worst case the upper limit is in
the 2 digits range.
> > > But, I'm really not convinced that you can actually keep this map
> > > yourselves. It's not as simple as you think. What happens if you
get
> > > on an LPAR with two sections, one 256MB@0x0 and another
> > > 16MB@0x1000000000000000. That's quite possible. I think your
vmalloc'd
> > > array will eat all of memory.
> > I'm glad you mention this part. There are many algorithms out there to
> > handle this problem,
> > hashes/trees/... all of these trade speed for smaller memory footprint.
> > We based the table decission on the existing implementations of the
> > architecture.
> > Do you see such a case coming along for the next generation POWER
systems?
>
> Dude. It exists *TODAY*. Go take a machine, add tens of gigabytes of
> memory to it. Then, remove all of the sections of memory in the middle.
> You'll be left with a very sparse memory configuration that we *DO*
> handle today in the core VM. We handle it quite well, actually.
>
> The hypervisor does not shrink memory from the top down. It pulls
> things out of the middle and shuffles things around. In fact, a NUMA
> node's memory isn't even contiguous.
>
> Your code will OOM the machine in this case. I consider the ehea driver
> buggy in this regard.
Your comment indicates that the upper limit for memory to be set on HMC
does not influence
the upper limit of the partition physical address space.
So our base assumption we discussed internally is wrong here.
(conclusion see below)
>
> > I would guess these drastic changes would also require changes in base
> > kernel.
>
> No, we actually solved those a couple years ago.
>
> > Will you provide a generic mapping system with a contiguous virtual
address
> > space
> > like the ehea_bmap we can query? This would need to be a "stable" part
of
> > the implementation,
> > including translation functions from kernel to
nextgen_ehea_generic_bmap
> > like virt_to_abs.
>
> Yes, that's a real possibility, especially if some other users for it
> come forward. We could definitely add something like that to the
> generic code. But, you'll have to be convincing that what we have now
> is insufficient.
>
> Does this requirement:
> "- MRs cover a contiguous virtual memory block (no holes)"
> come from the hardware?
>
yes
> Is that *EACH* MR? OR all MRs?
>
each
> Where does EHEA_BUSMAP_START come from? Is that defined in the
> hardware? Have you checked to ensure that no other users might want a
> chunk of memory in that area?
>
EHEA_BUSMAP_START is a value which has to match between the wqe
virtual addresses and the MR used in them.
Fortunately there's a simple answer on that one. Each MR has a own address
space,
so there's no need to check.
A HEA MR actually has exactly the same attributes as a Infiniband MR with
this hardware.
send/receive processing is pretty much comparable to a Infiniband UD queue.
> Can you query the existing MRs?
no
> Not change them in place, but can you
> query their contents?
no
>
> > > That's why we have SPARSEMEM_EXTREME and SPARSEMEM_VMEMMAP
implemented
> > > in the core, so that we can deal with these kinds of problems, once
and
> > > *NOT* in every single little driver out there.
> > >
> > > > Functions to use while building ehea_bmap + MRs:
> > > > - Use either the functions that are used by the memory hotplug
system
> > as
> > > > well, that means using the section defines + functions
> > (section_nr_to_pfn,
> > > > pfn_valid)
> > >
> > > Basically, you can't use anything related to sections outside of the
> > > core code. You can use things like pfn_valid(), or you can create
new
> > > interfaces that are properly abstracted.
> >
> > We picked sections instead of PFNs because this keeps the ehea_bmap in
a
> > reasonable range
> > on the existing systems.
> > But if you provide a abstract method handling exactly the problem we
> > mention
> > we'll be happy to use that and dump our private implementation.
>
> One thing you can guarantee today is that things are contiguous up to
> MAX_ORDER_NR_PAGES. That's a symbol that is unlikely to change and is
> much more appropriate than using sparsemem. We could also give you a
> nice new #define like MINIMUM_CONTIGUOUS_PAGES or something. I think
> that's what you really want.
That's definitely the right direction.
>From this mail thread I would conclude....
memory space can have holes, and drivers shouldn't make any assumption when
where and how.
A translation from kernel to ehea_bmap space should be fast and predictable
(ruling out hashes).
If a driver doesn't know anything else about the mapping structure,
the normal solution in kernel for this type of problem is a multi level
look up table
like pgd->pud->pmd->pte
This doesn't sound right to be implemented in a device driver.
We didn't see from the existing code that such a mapping to a contiguous
space already exists.
Maybe we've missed it.
If the mapping is less random, the translation gets much simpler.
MAX_ORDER_NR_PAGES helps here, is there more like that?
Gruss / Regards
Christoph Raisch + Jan-Bernd Themann
^ permalink raw reply
* Re: [PATCH 6/9] fs_enet: Be an of_platform device when CONFIG_PPC_CPM_NEW_BINDING is set.
From: Sergej Stepanov @ 2008-02-15 15:38 UTC (permalink / raw)
To: Laurent Pinchart; +Cc: linuxppc-dev, jgarzik, netdev
In-Reply-To: <200802151350.20627.laurentp@cse-semaphore.com>
Am Freitag, den 15.02.2008, 13:50 +0100 schrieb Laurent Pinchart:
> We're loosing the possibility of having MDC and MDIO on different ports. This
> is quite easy to fix for the non-CONFIG_PPC_CPM_NEW_BINDING case but I'm not
> familiar with OF bindings (yet) to fix the CONFIG_PPC_CPM_NEW_BINDING case.
>
for OF issue i had this for a paar month:
http://www.spinics.net/lists/netdev/msg45778.html
http://www.spinics.net/lists/netdev/msg47159.html
i'll be glad if it helps...
Regards
Sergej.
^ permalink raw reply
* XUP Virtex II p with Linux 2.4 - Question
From: rodolfo @ 2008-02-15 15:51 UTC (permalink / raw)
To: linuxppc-embedded, rodolfogalvao87
Hi everybody!
I subscribe on this list today because i have some problems with linux
kernel 2.4 compilation. I'm using EDK/ISE 9.1i, crosstool-0.38 . I follow
this sites:
- http://www.cs.washington.edu/research/lis/empart/xup_ppc_linux.shtml
- http://splish.ee.byu.edu/projects/LinuxFPGA/
- http://www.crhc.uiuc.edu/IMPACT/gsrc/hardwarelab/docs/kernel-HOWTO.html
I have a lot of error like this: "can not found ...", "undeclared first in
this function...". But i could solve them! Now the problem is:
../common/ns16550.c: In function `serial_init':
../common/ns16550.c:63: error: `XPAR_UARTNS550_0_CLOCK_FREQ_HZ' undeclared
(first use in this function)
../common/ns16550.c:63: error: (Each undeclared identifier is reported only
once
../common/ns16550.c:63: error: for each function it appears in.)
make[2]: ** [../common/ns16550.o] Erro 1
make[2]: Saindo do diretório
`/home/rodolfo/Desktop/Projeto_Linux_Embedded/bk-client2.0/linux/arch/ppc/boot/simple'
make[1]: ** [zImage.initrd] Erro 2
make[1]: Saindo do diretório
`/home/rodolfo/Desktop/Projeto_Linux_Embedded/bk-client2.0/linux/arch/ppc/boot'
make: ** [zImage.initrd] Erro 2
Anybody can help me? i'm new in this world (fpga - linux)!
Thanks
Rodolfo Galvao
Fortaleza/CE - BRASIL
^ permalink raw reply
* Re: HDLC driver - dev_free_skb_irq causes Segfault
From: Jochen Friedrich @ 2008-02-15 16:21 UTC (permalink / raw)
To: rmcguire; +Cc: linuxppc-embedded
In-Reply-To: <00be01c86b8d$27c2fcb0$6405a8c0@absolut>
Hi Russell,
> ‘Unable to Handle Kernel Paging Request for data at address 0x00000000’
You need to check where the crash happens and what data is 0.
> Anyone have any ideas?
Is the source of this driver available somewhere?
Thanks,
Jochen
^ permalink raw reply
* Re: [PATCH 1/2] fb: add support for foreign endianness
From: Anton Vorontsov @ 2008-02-15 16:45 UTC (permalink / raw)
To: Andrew Morton; +Cc: linuxppc-dev, linux-fbdev-devel, linux-kernel, adaplas
In-Reply-To: <20080214224942.a0cb6218.akpm@linux-foundation.org>
On Thu, Feb 14, 2008 at 10:49:42PM -0800, Andrew Morton wrote:
> On Tue, 5 Feb 2008 18:44:32 +0300 Anton Vorontsov <avorontsov@ru.mvista.com> wrote:
>
> > This patch adds support for the framebuffers with non-native
> > endianness. This is done via FBINFO_FOREIGN_ENDIAN flag that will
> > be used by the drivers. Depending on the host endianness this flag
> > will be overwritten by FBINFO_BE_MATH internal flag, or cleared.
> >
> > Tested to work on MPC8360E-RDK (BE) + Fujitsu MINT framebuffer (LE).
>
> That's a pretty large patch to fbdev core,
Yes, but changes are mostly trivial. No insurance of typos and thinkos
though. OTOH, it survived my tests.
> and Tony appears to have gone
> offline again and you didn't cc the fbdev mailing list.
FRAMEBUFFER LAYER
P: Antonino Daplas
M: adaplas@gmail.com
L: linux-fbdev-devel@lists.sourceforge.net (subscribers-only)
I'm lazy to subscribe on occasional patches. Yup, this is hardly
an excuse...
> I fixed the third problem. Could the other fbdev developers please review
> and comment on this?
>
> Thanks.
>
>
>
> Actually... should CONFIG_FB_FOREIGN_ENDIAN exist, or should this feature
> be permanently enabled?
It should not. Because with CONFIG_FB_FOREIGN_ENDIAN enabled, drawing
might be a little bit slower, because of external checks for endianness
(I didn't noticed any slowdown, but I guess it's still measurable if we
find some fb benchmark).
Thinking about it a little bit more, I believe we want to add a choice,
which exactly foreign endianness we want to compile-in. Then, if we're
pretty confident that particular BE machine uses only LE framebuffer,
gcc can optimize away endianness checks.
Patch on top of previous inlined here. With that patch, slowdown is
possible with CONFIG_FB_BOTH_ENDIAN option only, which is still
default if FOREIGN_ENDIAN is selected.
> I'd like to at least queue a patch in -mm so that CONFIG_FB_FOREIGN_ENDIAN
> is forced-on, so the code gets some runtime testing. Will that break
> anything?
Nope, it should not break anything, just possible fbconsole/tux drawing
slowdown.
Thanks,
- - - -
From: Anton Vorontsov <avorontsov@ru.mvista.com>
Subject: fb: add support for choice foreign endianness
With this patch FB_FOREIGN_ENDIAN converted to menuconfig with the
choice inside: which type of foreign endianness we want to compile-in.
As a bonus, now fb subsystem will refuse to register framebuffer with
unsupported endianness, and will suggest a way to solve the problem.
[ on top of fb-add-support-for-foreign-endianness.patch ]
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
drivers/video/Kconfig | 27 +++++++++++++++++++++------
drivers/video/fbmem.c | 38 ++++++++++++++++++++++++++++++--------
include/linux/fb.h | 14 +++++++++++---
3 files changed, 62 insertions(+), 17 deletions(-)
diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index 6b3940d..9e0b6ea 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -139,14 +139,29 @@ config FB_SYS_IMAGEBLIT
blitting. This is used by drivers that don't provide their own
(accelerated) version and the framebuffer is in system RAM.
-config FB_FOREIGN_ENDIAN
- bool "Enable support for foreign endianness"
+menuconfig FB_FOREIGN_ENDIAN
+ bool "Framebuffer foreign endianness support"
depends on FB
---help---
- This option enables support for the framebuffers with non-native
- endianness (e.g. Little-Endian framebuffer on a Big-Endian machine).
- You probably don't have such hardware, so in most cases it's safe to
- say "n" here.
+ This menu will let you enable support for the framebuffers with
+ non-native endianness (e.g. Little-Endian framebuffer on a
+ Big-Endian machine). Most probably you don't have such hardware,
+ so it's safe to say "n" here.
+
+choice
+ prompt "Choice endianness support"
+ depends on FB_FOREIGN_ENDIAN
+
+config FB_BOTH_ENDIAN
+ bool "Support for Big- and Little-Endian framebuffers"
+
+config FB_BIG_ENDIAN
+ bool "Support for Big-Endian framebuffers only"
+
+config FB_LITTLE_ENDIAN
+ bool "Support for Little-Endian framebuffers only"
+
+endchoice
config FB_SYS_FOPS
tristate
diff --git a/drivers/video/fbmem.c b/drivers/video/fbmem.c
index c086004..11d92fd 100644
--- a/drivers/video/fbmem.c
+++ b/drivers/video/fbmem.c
@@ -1352,6 +1352,32 @@ static const struct file_operations fb_fops = {
struct class *fb_class;
EXPORT_SYMBOL(fb_class);
+
+static int fb_check_foreignness(struct fb_info *fi)
+{
+ const bool foreign_endian = fi->flags & FBINFO_FOREIGN_ENDIAN;
+
+ fi->flags &= ~FBINFO_FOREIGN_ENDIAN;
+
+#ifdef __BIG_ENDIAN
+ fi->flags |= foreign_endian ? 0 : FBINFO_BE_MATH;
+#else
+ fi->flags |= foreign_endian ? FBINFO_BE_MATH : 0;
+#endif /* __BIG_ENDIAN */
+
+ if (fi->flags & FBINFO_BE_MATH && !fb_be_math(fi)) {
+ pr_err("%s: enable CONFIG_FB_BIG_ENDIAN to "
+ "support this framebuffer\n", fi->fix.id);
+ return -ENOSYS;
+ } else if (!(fi->flags & FBINFO_BE_MATH) && fb_be_math(fi)) {
+ pr_err("%s: enable CONFIG_FB_LITTLE_ENDIAN to "
+ "support this framebuffer\n", fi->fix.id);
+ return -ENOSYS;
+ }
+
+ return 0;
+}
+
/**
* register_framebuffer - registers a frame buffer device
* @fb_info: frame buffer info structure
@@ -1368,10 +1394,13 @@ register_framebuffer(struct fb_info *fb_info)
int i;
struct fb_event event;
struct fb_videomode mode;
- const bool foreign_endian = fb_info->flags & FBINFO_FOREIGN_ENDIAN;
if (num_registered_fb == FB_MAX)
return -ENXIO;
+
+ if (fb_check_foreignness(fb_info))
+ return -ENOSYS;
+
num_registered_fb++;
for (i = 0 ; i < FB_MAX; i++)
if (!registered_fb[i])
@@ -1405,13 +1434,6 @@ register_framebuffer(struct fb_info *fb_info)
if (!fb_info->pixmap.blit_y)
fb_info->pixmap.blit_y = ~(u32)0;
- fb_info->flags &= ~FBINFO_FOREIGN_ENDIAN;
-#ifdef __BIG_ENDIAN
- fb_info->flags |= foreign_endian ? 0 : FBINFO_BE_MATH;
-#else
- fb_info->flags |= foreign_endian ? FBINFO_BE_MATH : 0;
-#endif
-
if (!fb_info->modelist.prev || !fb_info->modelist.next)
INIT_LIST_HEAD(&fb_info->modelist);
diff --git a/include/linux/fb.h b/include/linux/fb.h
index a067ed3..72295b0 100644
--- a/include/linux/fb.h
+++ b/include/linux/fb.h
@@ -979,13 +979,21 @@ extern int fb_deferred_io_fsync(struct file *file, struct dentry *dentry,
static inline bool fb_be_math(struct fb_info *info)
{
-#if defined(CONFIG_FB_FOREIGN_ENDIAN)
+#ifdef CONFIG_FB_FOREIGN_ENDIAN
+#if defined(CONFIG_FB_BOTH_ENDIAN)
return info->flags & FBINFO_BE_MATH;
-#elif defined(__BIG_ENDIAN)
+#elif defined(CONFIG_FB_BIG_ENDIAN)
+ return true;
+#elif defined(CONFIG_FB_LITTLE_ENDIAN)
+ return false;
+#endif /* CONFIG_FB_BOTH_ENDIAN */
+#else
+#ifdef __BIG_ENDIAN
return true;
#else
return false;
-#endif
+#endif /* __BIG_ENDIAN */
+#endif /* CONFIG_FB_FOREIGN_ENDIAN */
}
/* drivers/video/fbsysfs.c */
--
1.5.2.2
^ permalink raw reply related
* Re: [PATCH] drivers/base: export gpl (un)register_memory_notifier
From: Dave Hansen @ 2008-02-15 16:55 UTC (permalink / raw)
To: Christoph Raisch
Cc: Thomas Q Klein, ossthema, Jan-Bernd Themann, Greg KH, apw,
linux-kernel, linuxppc-dev, Badari Pulavarty, netdev, tklein
In-Reply-To: <OF58A8E0B3.B5CC265E-ONC12573F0.00496E2B-C12573F0.0049850F@de.ibm.com>
On Fri, 2008-02-15 at 14:22 +0100, Christoph Raisch wrote:
> A translation from kernel to ehea_bmap space should be fast and
> predictable
> (ruling out hashes).
> If a driver doesn't know anything else about the mapping structure,
> the normal solution in kernel for this type of problem is a multi
> level
> look up table
> like pgd->pud->pmd->pte
> This doesn't sound right to be implemented in a device driver.
>
> We didn't see from the existing code that such a mapping to a
> contiguous
> space already exists.
> Maybe we've missed it.
I've been thinking about that, and I don't think you really *need* to
keep a comprehensive map like that.
When the memory is in a particular configuration (range of memory
present along with unique set of holes) you get a unique ehea_bmap
configuration. That layout is completely predictable.
So, if at any time you want to figure out what the ehea_bmap address for
a particular *Linux* virtual address is, you just need to pretend that
you're creating the entire ehea_bmap, use the same algorithm and figure
out host you would have placed things, and use that result.
Now, that's going to be a slow, crappy linear search (but maybe not as
slow as recreating the silly thing). So, you might eventually run into
some scalability problems with a lot of packets going around. But, I'd
be curious if you do in practice.
The other idea is that you create a mapping that is precisely 1:1 with
kernel memory. Let's say you have two sections present, 0 and 100. You
have a high_section_index of 100, and you vmalloc() a 100 entry array.
You need to create a *CONTIGUOUS* ehea map? Create one like this:
EHEA_VADDR->Linux Section
0->0
1->0
2->0
3->0
...
100->100
It's contiguous. Each area points to a valid Linux memory address.
It's also discernable in O(1) to what EHEA address a given Linux address
is mapped. You just have a couple of duplicate entries.
-- Dave
^ permalink raw reply
* RE: [PATCH] booting-without-of: add Xilinx uart 16550.
From: Stephen Neuendorffer @ 2008-02-15 17:08 UTC (permalink / raw)
To: Pavel Kiryukhin, linuxppc-dev
In-Reply-To: <47B59631.10908@ru.mvista.com>
> + - reg-shift : registers offset shift (standard uart_port
field).
> + Property is optional if regshift is zero.
I was hoping to get an idea of what is required here, or when I might
use it?
It looks like the ARCH=3Dppc code instantiates this with a reg-shift of
2... Is this the expected value? When would it be not zero? or not
two?
Steve
^ permalink raw reply
* Re: [PATCH 3/8] pseries: phyp dump: use sysfs to release reserved mem
From: Linas Vepstas @ 2008-02-15 17:30 UTC (permalink / raw)
To: Tony Breeds; +Cc: mahuja, linuxppc-dev, paulus
In-Reply-To: <20080215010528.GI6887@bakeyournoodle.com>
On 14/02/2008, Tony Breeds <tony@bakeyournoodle.com> wrote:
> On Tue, Feb 12, 2008 at 01:11:58AM -0600, Manish Ahuja wrote:
> > +static ssize_t
> > +show_release_region(struct kset * kset, char *buf)
> > +{
> > + return sprintf(buf, "ola\n");
> > +}
> > +
> > +static struct subsys_attribute rr = __ATTR(release_region, 0600,
> > + show_release_region,
> > + store_release_region);
>
>
> Any reason this sysfs attribute can't be write only? The show method
> doesn't seem needed.
This was supposed to be a place-holder; a later patch would add detailed
info. The goal was to have user-land tools that would operate these files
to progressively dump and release memory regions; however, until these
userland tools get written, the proper interface remains murky (e.g.
real addresses? virtual addresses? just delta's or a whole memory map?
some sort of numa flags or whatever?)
--linas
^ permalink raw reply
* Re: [PATCH] booting-without-of: add Xilinx uart 16550.
From: Pavel Kiryukhin @ 2008-02-15 17:41 UTC (permalink / raw)
To: Stephen Neuendorffer; +Cc: linuxppc-dev
In-Reply-To: <20080215170844.9D21610081@mail40-dub.bigfish.com>
Stephen Neuendorffer wrote:
>> + - reg-shift : registers offset shift (standard uart_port
> field).
>> + Property is optional if regshift is zero.
>
> I was hoping to get an idea of what is required here, or when I might
> use it?
>
> It looks like the ARCH=ppc code instantiates this with a reg-shift of
> 2... Is this the expected value?
Yes, reg-shift = 2 should be set for Xilinx 16550 uart.
Should I add this to patch?
BTW regshift=2 is hardcoded for uartlite.
> When would it be not zero? or not
> two?
Sorry, it seems I don't follow here.
--
Regards,
Pavel
^ permalink raw reply
* RE: [PATCH] booting-without-of: add Xilinx uart 16550.
From: Stephen Neuendorffer @ 2008-02-15 17:46 UTC (permalink / raw)
To: Pavel Kiryukhin; +Cc: linuxppc-dev
In-Reply-To: <47B5CEAF.8030705@ru.mvista.com>
> -----Original Message-----
> From: Pavel Kiryukhin [mailto:pkiryukhin@ru.mvista.com]
> Sent: Friday, February 15, 2008 9:41 AM
> To: Stephen Neuendorffer
> Cc: linuxppc-dev@ozlabs.org
> Subject: Re: [PATCH] booting-without-of: add Xilinx uart 16550.
>=20
> Stephen Neuendorffer wrote:
> >> + - reg-shift : registers offset shift (standard uart_port
> > field).
> >> + Property is optional if regshift is zero.
> >
> > I was hoping to get an idea of what is required here, or when I
might
> > use it?
> >
> > It looks like the ARCH=3Dppc code instantiates this with a reg-shift
of
> > 2... Is this the expected value?
>=20
> Yes, reg-shift =3D 2 should be set for Xilinx 16550 uart.
> Should I add this to patch?
Yes, please!
=20
> BTW regshift=3D2 is hardcoded for uartlite.
>=20
> > When would it be not zero? or not
> > two?
> Sorry, it seems I don't follow here.
I think all that needs to get added is 'For the Xilinx uart 16550 cores,
reg-shift must be set to 2'
Steve
^ permalink raw reply
* [BUID_FAILURE] next-20080215 Build failure caused by ide: rework PowerMac media-bay support
From: Kamalesh Babulal @ 2008-02-15 17:54 UTC (permalink / raw)
To: bzolnier; +Cc: linux-ide, linux-kernel, linuxppc-dev
The linux-next-20080215 kernel build fails on the powerpc with
following error
CC arch/powerpc/platforms/powermac/setup.o
In file included from arch/powerpc/platforms/powermac/setup.c:66:
include/asm/mediabay.h:29: error: syntax error before 'ide_hwif_t'
include/asm/mediabay.h:29: warning: function declaration isn't a prototype
make[2]: *** [arch/powerpc/platforms/powermac/setup.o] Error 1
make[1]: *** [arch/powerpc/platforms/powermac] Error 2
make: *** [arch/powerpc/platforms] Error 2
This build failure is caused by the ide: rework PowerMac media-bay support
patch.This problem was reported and solution suggested according to
http://lkml.org/lkml/2008/2/13/195 including the
#include <linux/ide.h> after
#ifdef CONFIG_BLK_DEV_IDE_PMAC
helps in fixing the build failure.
--
Thanks & Regards,
Kamalesh Babulal,
Linux Technology Center,
IBM, ISTL.
^ permalink raw reply
* NOR flash partitions gone
From: Sean MacLennan @ 2008-02-15 19:11 UTC (permalink / raw)
To: 'linuxppc-dev'
I did a git pull of Josh's for-2.6.25 tree. Now the NOR partitions are
no longer setup.
nor_flash@0,0 {
compatible = "amd,s29gl032a", "cfi-flash";
bank-width = <2>;
reg = <0 0 400000>;
#address-cells = <1>;
#size-cells = <1>;
partition@300000 {
label = "fpga";
reg = <300000 40000>;
};
partition@340000 {
label = "env";
reg = <340000 40000>;
};
partition@380000 {
label = "u-boot";
reg = <380000 80000>;
};
};
It still detects the chip, it just doesn't configure the partitions. Any
ideas?
Cheers,
Sean
^ permalink raw reply
* Re: NOR flash partitions gone
From: Scott Wood @ 2008-02-15 18:14 UTC (permalink / raw)
To: Sean MacLennan; +Cc: 'linuxppc-dev'
In-Reply-To: <47B5E3CA.5050208@pikatech.com>
Sean MacLennan wrote:
> I did a git pull of Josh's for-2.6.25 tree. Now the NOR partitions are
> no longer setup.
>
> nor_flash@0,0 {
> compatible = "amd,s29gl032a", "cfi-flash";
> bank-width = <2>;
> reg = <0 0 400000>;
> #address-cells = <1>;
> #size-cells = <1>;
> partition@300000 {
> label = "fpga";
> reg = <300000 40000>;
> };
> partition@340000 {
> label = "env";
> reg = <340000 40000>;
> };
> partition@380000 {
> label = "u-boot";
> reg = <380000 80000>;
> };
> };
>
>
>
> It still detects the chip, it just doesn't configure the partitions. Any
> ideas?
Try turning off command line partition support -- there's a bug in it
that was exposed by changes to the OF physmap code (in particular, it
returns -EINVAL rather than zero when no command line partitions are
present).
-Scott
^ permalink raw reply
* Re: NOR flash partitions gone
From: Anton Vorontsov @ 2008-02-15 18:17 UTC (permalink / raw)
To: Sean MacLennan; +Cc: 'linuxppc-dev'
In-Reply-To: <47B5E3CA.5050208@pikatech.com>
On Fri, Feb 15, 2008 at 02:11:06PM -0500, Sean MacLennan wrote:
> I did a git pull of Josh's for-2.6.25 tree. Now the NOR partitions are
> no longer setup.
>
> nor_flash@0,0 {
> compatible = "amd,s29gl032a", "cfi-flash";
> bank-width = <2>;
> reg = <0 0 400000>;
> #address-cells = <1>;
> #size-cells = <1>;
> partition@300000 {
> label = "fpga";
> reg = <300000 40000>;
> };
> partition@340000 {
> label = "env";
> reg = <340000 40000>;
> };
> partition@380000 {
> label = "u-boot";
> reg = <380000 80000>;
> };
> };
>
>
>
> It still detects the chip, it just doesn't configure the partitions. Any
> ideas?
Probably CONFIG_MTD_OF_PARTS is not set?
Good luck,
--
Anton Vorontsov
email: cbou@mail.ru
backup email: ya-cbou@yandex.ru
irc://irc.freenode.net/bd2
^ permalink raw reply
* [PATCH] prom.c: Fix dt_mem_next_cell() to read the full mem cells
From: Becky Bruce @ 2008-02-15 18:17 UTC (permalink / raw)
To: linuxppc-dev
dt_mem_next_cell() currently does of_read_ulong(). This does
not allow for the case where #size-cells and/or #address-cells = 2 on
a 32-bit system, as it will end up reading 32 bits instead of the
expected 64. Change it to use of_read_number instead and always return
a u64.
Signed-off-by: Becky Bruce <becky.bruce at freescale.com>
---
arch/powerpc/kernel/prom.c | 13 +++++++------
1 files changed, 7 insertions(+), 6 deletions(-)
diff --git a/arch/powerpc/kernel/prom.c b/arch/powerpc/kernel/prom.c
index c17a585..ff600ef 100644
--- a/arch/powerpc/kernel/prom.c
+++ b/arch/powerpc/kernel/prom.c
@@ -865,12 +865,12 @@ static int __init early_init_dt_scan_root(unsigned long node,
return 1;
}
-static unsigned long __init dt_mem_next_cell(int s, cell_t **cellp)
+static u64 __init dt_mem_next_cell(int s, cell_t **cellp)
{
cell_t *p = *cellp;
*cellp = p + s;
- return of_read_ulong(p, s);
+ return of_read_number(p, s);
}
#ifdef CONFIG_PPC_PSERIES
@@ -883,8 +883,8 @@ static unsigned long __init dt_mem_next_cell(int s, cell_t **cellp)
static int __init early_init_dt_scan_drconf_memory(unsigned long node)
{
cell_t *dm, *ls;
- unsigned long l, n;
- unsigned long base, size, lmb_size, flags;
+ unsigned long l, n, flags;
+ u64 base, size, lmb_size;
ls = (cell_t *)of_get_flat_dt_prop(node, "ibm,lmb-size", &l);
if (ls == NULL || l < dt_root_size_cells * sizeof(cell_t))
@@ -959,14 +959,15 @@ static int __init early_init_dt_scan_memory(unsigned long node,
uname, l, reg[0], reg[1], reg[2], reg[3]);
while ((endp - reg) >= (dt_root_addr_cells + dt_root_size_cells)) {
- unsigned long base, size;
+ u64 base, size;
base = dt_mem_next_cell(dt_root_addr_cells, ®);
size = dt_mem_next_cell(dt_root_size_cells, ®);
if (size == 0)
continue;
- DBG(" - %lx , %lx\n", base, size);
+ DBG(" - %llx , %llx\n", (unsigned long long)base,
+ (unsigned long long)size);
#ifdef CONFIG_PPC64
if (iommu_is_off) {
if (base >= 0x80000000ul)
--
1.5.3.8
^ permalink raw reply related
* Re: [PATCH] booting-without-of: add Xilinx uart 16550.
From: Milton Miller @ 2008-02-15 18:34 UTC (permalink / raw)
To: Pavel Kiryukhin; +Cc: ppcdev
In-Reply-To: <47B59631.10908@ru.mvista.com>
On Sat Feb 16 00:40:01 EST 2008, Pavel Kiryukhin pkiryukhin wrote:
> Add uart 16550 properties description to Xilinx portion of
> booting-without-of.txt
This patch description is a bit weak. How about adding what properties
are being added. Also, as described below, it's going to become more
than just adding a property.
> Signed-off-by: Pavel Kiryukhin <pkiryukhin at ru.mvista.com>
> ---
> Documentation/powerpc/booting-without-of.txt | 16 ++++++++++++++--
> 1 files changed, 14 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/powerpc/booting-without-of.txt
> b/Documentation/powerpc/booting-without-of.txt
> index 7b4e8a7..dd77bbc 100644
> --- a/Documentation/powerpc/booting-without-of.txt
> +++ b/Documentation/powerpc/booting-without-of.txt
> @@ -2575,10 +2575,22 @@ platforms are moved over to use the
> flattened-device-tree model.
>
> Xilinx uartlite devices are simple fixed speed serial ports.
>
> - Requred properties:
> + Required properties:
> - current-speed : Baud rate of uartlite
>
> - v) Xilinx hwicap
> + v) Xilinx Uart 16550
> +
> + Xilinx uart 16550 device registers are compatible with all
> standard 16540
> + and 16550 UARTs.
> +
> + Required properties:
> + - current-speed : Baud rate of uart.
> + - clock-frequency : Baud rate generator reference clock. May
> be driven
> + by OPB_Clk (100 MHz).
Freqency of the reference clock generating the baud rate. (Sometimes
this is connected to the OBP_Clk which is usually 100MHz). This is
not the documentation for the macro, its the documentation for the
device tree.
> + - reg-shift : registers offset shift (standard uart_port
> field).
> + Property is optional if regshift is zero.
As Steven said, you must define what the property means (don't say that
the value should be 2 on chip x, describe how to determine the correct
value and how to use it). "When this property is present, the address
bits selecting the different 16550 registers are shifted left this many
bits."
Also, since this is not register compatible with previous the previous
ns16550 binding, we need to use a new compatible string.
ns16550-shifted or ns16550-offset would be ok with me. When we define
this node, refer to 16550, and state that we expect nodes that have a
zero shfit should include the ns16550 string.
Looking in the bigger context, this binding is not Xilinx specific; but
I don't see an obviousy better place and am not going to do more than
mention that issue.
milton
^ permalink raw reply
* Re: [PATCH v2] [POWERPC] Enable correct operation of serial ports with
From: Milton Miller @ 2008-02-15 18:34 UTC (permalink / raw)
To: Pavel Kiryukhin; +Cc: ppcdev
In-Reply-To: <47B593E1.2060905@ru.mvista.com>
On Sat Feb 16 00:30:09 EST 2008, Pavel Kiryukhin wrote:
> Add regshift reading to serial drivers.
> This enables correct operation of serial ports with
> nonzero regshift such as Xilinx opb 16550 uart.
>
> Signed-off-by: Pavel Kiryukhin <pkiryukhin at ru.mvista.com>
This patch is incomplete in that it does not add support to recognize
any such nodes.
As discussed in the previous submissions, serial ports that attach the
registers with offsets must get a new compatible name, as the binding
for ns16550 does not include this reg--shift property. It would
therefore be wrong to claim compatibility with it, as older consumers
of the device tree would bind to this node without the support. (Its
ok to check for this port always, but we should only expect it on the
new compatible type).
We need to define this new type, add it to the doc, and add code to
find such ports (presently we only search for ns16550 and device_type
serial on isa bus).
> @@ -40,7 +40,7 @@ static int __devinit of_platform_serial_setup(struct
> of_device *ofdev,
> dev_warn(&ofdev->dev, "no clock-frequency property
> set\n");
> return -ENODEV;
> }
> -
> + regshift = of_get_property(np, "reg-shift", NULL);
> ret = of_address_to_resource(np, 0, &resource);
> if (ret) {
> dev_warn(&ofdev->dev, "invalid address\n");
Looking at the code I was going to say "lets put this optional property
with the other one (spd) that doesn't have the if next to it."
However, I now see that the existence of spd (current-speed) is simply
never checked, and if its missing this code will oops with a NULL
pointer. Could you prepare a patch to fix that? I'm not sure if we
need to fail if its not present, or we can just skip setting
port->custom_divisor. You will need to look at the driver to see what
it requires.
And I think that fetching this property should be moved to the end
instead of being mixed with the properties we require, but that is just
my preference.
> @@ -57,6 +57,8 @@ static int __devinit of_platform_serial_setup(struct
> of_device *ofdev,
> | UPF_FIXED_PORT;
> port->dev = &ofdev->dev;
> port->custom_divisor = *clk / (16 * (*spd));
> + if (regshift)
> + port->regshift = *regshift;
>
> return 0;
> }
milton
^ permalink raw reply
* Re: [PATCH] booting-without-of: add Xilinx uart 16550.
From: Grant Likely @ 2008-02-15 18:38 UTC (permalink / raw)
To: Pavel Kiryukhin; +Cc: linuxppc-dev
In-Reply-To: <47B59631.10908@ru.mvista.com>
On Fri, Feb 15, 2008 at 6:40 AM, Pavel Kiryukhin
<pkiryukhin@ru.mvista.com> wrote:
> Add uart 16550 properties description to Xilinx portion of booting-without-of.txt
>
> Signed-off-by: Pavel Kiryukhin <pkiryukhin@ru.mvista.com>
> ---
> Documentation/powerpc/booting-without-of.txt | 16 ++++++++++++++--
> 1 files changed, 14 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/powerpc/booting-without-of.txt b/Documentation/powerpc/booting-without-of.txt
> index 7b4e8a7..dd77bbc 100644
> --- a/Documentation/powerpc/booting-without-of.txt
> +++ b/Documentation/powerpc/booting-without-of.txt
> @@ -2575,10 +2575,22 @@ platforms are moved over to use the flattened-device-tree model.
>
> Xilinx uartlite devices are simple fixed speed serial ports.
>
> - Requred properties:
> + Required properties:
> - current-speed : Baud rate of uartlite
>
> - v) Xilinx hwicap
> + v) Xilinx Uart 16550
> +
> + Xilinx uart 16550 device registers are compatible with all standard 16540
> + and 16550 UARTs.
Not strictly true; the xilinx uart is *almost* compatible with the
ns16550. The same driver can be made to work, but it is not register
level compatible so we cannot claim compatible="ns16550". We need a
new compatible property for 16550 like devices with a reg shift and
offset. Instead of attempting to come up with a generic description
of this, I recommend just naming it after the actual device instance;
something like compatible="xlnx,opb-uart16550";
Cheers,
g.
^ permalink raw reply
* Re: NOR flash partitions gone
From: Sean MacLennan @ 2008-02-15 19:39 UTC (permalink / raw)
To: avorontsov; +Cc: 'linuxppc-dev'
In-Reply-To: <20080215181743.GA30029@localhost.localdomain>
Anton Vorontsov wrote:
> Probably CONFIG_MTD_OF_PARTS is not set?
>
> Good luck,
>
That was it! Thanks!
Cheers,
Sean
^ 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