* 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
* Boot freezes at memset_io in early_init
From: Ricardo Ayres Severo @ 2008-02-15 18:40 UTC (permalink / raw)
To: linuxppc-embedded
Hi all,
When booting the kernel, it freezes at this line in arch/ppc/setup.c:early_init
317 memset_io(PTRRELOC(&__bss-start), 0, _end - __bss_start);
I searched the list's archive and found this post [1] which has a
similar problem than I, but there isn't any solution posted.
What could be causing this?
I'm using the PPC405 in a Xilinux XUPV2P board with a Virtex II FPGA.
Thanks,
[1] http://ozlabs.org/pipermail/linuxppc-embedded/2004-August/015380.html
--
Ricardo Ayres Severo <severo.ricardo@gmail.com>
^ permalink raw reply
* Re: XUP Virtex II p with Linux 2.4 - Question
From: Grant Likely @ 2008-02-15 18:44 UTC (permalink / raw)
To: rodolfo; +Cc: rodolfogalvao87, linuxppc-embedded
In-Reply-To: <1575591b2b88bb7caca70587ec899dea@lesc.ufc.br>
On Fri, Feb 15, 2008 at 8:51 AM, rodolfo <rodolfo@lesc.ufc.br> wrote:
> 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:
>
<snip>
>
> Anybody can help me? i'm new in this world (fpga - linux)!
You should switch to using a 2.6 kernel. The 2.4 stuff is difficult to support.
See my notes here:
http://wiki.secretlab.ca/index.php/Linux_on_Xilinx_Virtex
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH] booting-without-of: add Xilinx uart 16550.
From: Sergei Shtylyov @ 2008-02-15 18:56 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev, Pavel Kiryukhin
In-Reply-To: <fa686aa40802151038l7488293clb0c47da5b1b1e4fc@mail.gmail.com>
Grant Likely 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".
How much incompatible it is with 16550? Does that only extend to register
stride of 4 instead of 1 -- if so, it should be considered compatible since
the same chip can be into address space mapped with stride of 1, 2, or 4, or
whatever power of 2. If it has some actual register difference, like e. g.
DLAB not existing and the divisor latch mapped to a separate register rather
than 0..1, then indeed, new compatible property must be defined.
> We need a new compatible property for 16550 like devices with a reg shift and
> offset.
No, we don't strictly need it if all incompatibilty is constrained to how
the same 16550 registers mapped to address space which is a function of the
address decoder, not the chip itself. Well, that's of course based in 8250.c's
ability to handle different strides -- an imaginary driver could only handle
1:1 chip mapping.
> 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";
Well, that means that we'll need a to add a code which "glues" the chip to
8250.c driver... well, of_serial.c could be that glue layer if we add to it
the ability to recognize Xilinx UART... well, legacy_serial.c could be taught
that trick too...
Well, we could also add the new compatible, but still claim "ns16550"
compatibility...
> Cheers,
> g.
WBR, Sergei
^ permalink raw reply
* Re: [PATCH] booting-without-of: add Xilinx uart 16550.
From: Grant Likely @ 2008-02-15 19:02 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: linuxppc-dev, Pavel Kiryukhin
In-Reply-To: <47B5E042.9050805@ru.mvista.com>
On Fri, Feb 15, 2008 at 11:56 AM, Sergei Shtylyov
<sshtylyov@ru.mvista.com> wrote:
> Grant Likely wrote:
>
> >> + 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".
>
> How much incompatible it is with 16550? Does that only extend to register
> stride of 4 instead of 1 -- if so, it should be considered compatible since
> the same chip can be into address space mapped with stride of 1, 2, or 4, or
> whatever power of 2. If it has some actual register difference, like e. g.
> DLAB not existing and the divisor latch mapped to a separate register rather
> than 0..1, then indeed, new compatible property must be defined.
The definition of compatible (from the OpenFirmware) docs is that the
*device* is register level compatible. That includes register
locations and offsets. The registers are not at the same location,
therefore it is not compatible.
However, the *driver* can be easily made compatible with the devices.
We just teach the driver to bind against both "ns16550" and whatever
value is chosen for these reg-shifted devices. Not a big deal.
> > We need a new compatible property for 16550 like devices with a reg shift and
> > offset.
>
> No, we don't strictly need it if all incompatibilty is constrained to how
> the same 16550 registers mapped to address space which is a function of the
> address decoder, not the chip itself. Well, that's of course based in 8250.c's
> ability to handle different strides -- an imaginary driver could only handle
> 1:1 chip mapping.
compatible also covers bus binding when it is a memory mapped device.
Otherwise you need another node between the bus and the ns16550 type
device that does translation from the wide stride (regshift=2) to the
ns16550 register definitions (regshift=0).
>
>
> > 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";
>
> Well, that means that we'll need a to add a code which "glues" the chip to
> 8250.c driver... well, of_serial.c could be that glue layer if we add to it
> the ability to recognize Xilinx UART... well, legacy_serial.c could be taught
> that trick too...
> Well, we could also add the new compatible, but still claim "ns16550"
> compatibility...
No, we cannot because it is not register level compatible (and once
again, that definition includes the stride between registers)
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ 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