* Re: [RFC] uartlite driver MicroBlaze compatability
From: Peter Korsgaard @ 2007-05-02 13:45 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <4636C836.4050502@itee.uq.edu.au>
>>>>> "JW" == John Williams <jwilliams@itee.uq.edu.au> writes:
Hi,
JW> The attached patch gets your uartlite driver going on MicroBlaze.
Nice!
JW> All readb/writeb ops are converted to ioread32/iowrite32.
JW> On MicroBlaze readb/writeb are picking up the MSB, instead of LSB,
JW> and thus reading all zeros instead of the 8-bit
JW> control/status/FIFO registers that you intended.
I take it that the microblaze is big endian? Then you just need to add
3 to the base address and everything should work without your patch.
JW> Can you please confirm if this works on PPC?
It won't as ioread/write does big/little endian byte swapping. Isn't
that done on microblaze?
--
Bye, Peter Korsgaard
^ permalink raw reply
* Re: [PATCH] powerpc: fix spurious vectors on weird MPIC
From: Josh Boyer @ 2007-05-02 13:45 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev
In-Reply-To: <1177965491.3026.47.camel@zod.rchland.ibm.com>
On Mon, 2007-04-30 at 15:38 -0500, Josh Boyer wrote:
> The weird TSI 10x MPIC needs an EOI after getting a spurious vector. This
> patch uses the existing MPIC_SPV_EOI flag to fix this issue.
Paul, I'd like to get this into 2.6.22 if possible. It's needed for a
round of patches I'll be sending out soon.
thx,
josh
^ permalink raw reply
* Re: [RFC] uartlite driver MicroBlaze compatability
From: Peter Korsgaard @ 2007-05-02 13:59 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <528646bc0704302255j3a825f10vbffd4bac961b28d7@mail.gmail.com>
>>>>> "GL" == Grant Likely <grant.likely@secretlab.ca> writes:
Hi,
>> Can you please confirm if this works on PPC?
GL> Yes, I've confirmed this does work on PPC; but I don't think it's
GL> quite the correct fix.
GL> ioread/write32 is mapped to in/out_le32, yet the bootloader driver
GL> must use in/out_be32. This is because the uartlite driver follows
GL> the lead of 8250 and requires an offset of 3 from the base address
GL> in order to find the relevant byte wise address. In fact, I
GL> believe the driver should work as-is on microblaze if the
GL> offset-by-3 is not used when registering it to the platform bus.
Not used? Isn't the microblaze big endian as well?
GL> However, the uartlite is *not* an 8250. The 8250 turns up all
GL> over the place and it's registers are defined as 8 bit wide. The
GL> offset-by-3 stuff is part of the plat_serial8250_port structure
GL> which is also used to specify .regshift (increment between
GL> registers). Whereas the UARTLITE is defined as a 32 bit device
GL> and it doesn't show up in anywhere near as many designs.
GL> Registers are always 4 bytes wide and are always located at
GL> multiples of 4 bytes off the base address.
Well, yes and no - The registers physically contains 8 bit of
information, but are commonly located on the 32bit opb bus.
GL> The biggest problem with keeping the 3 byte offset and using
GL> ioread/write32 on it makes every register access straddle a 32-bit
GL> boundary. This means 2 bus transactions for every register
GL> access. Absolutely not what we want.
Exactly.
GL> The problem with keeping the byte-wise access as it is now is that
GL> it means the platform bus binding needs to explicitly know what
GL> the host access width is and add the 3 byte offset accordingly
GL> (rather than using the base address as specified in xparameters
GL> unmodified and using the in/out_be32 macro take care of reading it
GL> correctly & efficiently).
I don't think that's a big problem. Other reasons for using 8bit I/O
are:
- No endianness problems (besides setting the proper base
address). "There's no read/write register in native endianness"
interface in the kernel. readl is always little endian, and _be32
would be wrong/not available on all archs. The uartlite interface is
nice and simple - Who knows if someone would add a FPGA with a bunch
of uartlite's to an ARM/MIPS/whatever design?
- No bus width problems. We have designs which needed extra uarts late
in the design, and have implemented uartlite compatible firmware in
a SP3e FPGA connected over a 16bit bus (EMC). The uartlite driver
works nicely with that as it is. With 32bit access you would double
the bus transactions.
- It matches 8250.c
GL> (There are also annoyances that will come up when we move to
GL> arch/powerpc and hook it up to the of_platform_bus)
Ohh, like what?
>> I note that Grant's recent bootloader driver uses in_be32/out_be32
>> - would you prefer that instead of ioread32/iowrite32?
GL> I certainly think so. The device is documented as using 32 bit BE
GL> registers; so the driver should access them as 32bit BE registers
GL> IMHO. Or at least, if there is a good reason to continue the
GL> bytewise access, then the driver should contain the smarts to
GL> translate from documented base address to the appropriate offset.
How should it be able to do that? Using some magic #ifdef to know if
it's compiled for a big endian arch and do a +3? That seems ugly to
me.
In other words - I disagree.
--
Bye, Peter Korsgaard
^ permalink raw reply
* Re: [PATCH 1/5] powerpc: generic time suspend/resume code
From: Johannes Berg @ 2007-05-02 14:04 UTC (permalink / raw)
To: michael; +Cc: linuxppc-dev
In-Reply-To: <1178103995.14649.3.camel@concordia.ozlabs.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 690 bytes --]
On Wed, 2007-05-02 at 21:06 +1000, Michael Ellerman wrote:
> Ah sorry, I didn't mention prep_defconfig is arch/__ppc__.
Ahh, ok.
> See arch/ppc/Makefile:
>
> core-y += arch/ppc/kernel/ arch/powerpc/kernel/ \
> arch/ppc/platforms/ \
> arch/ppc/mm/ arch/ppc/lib/ \
> arch/ppc/syslib/ arch/powerpc/sysdev/ \
> arch/powerpc/lib/
>
>
> So I guess we need to add the Kconfig fragment on arch/ppc also?
Yeah, but let me first see later today if I can go without rtc lib as
Paul has suggested.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 190 bytes --]
^ permalink raw reply
* What defines a cpu table platform? (was Re: Change 440GP platform to ppc440)
From: Kumar Gala @ 2007-05-02 14:06 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev list
In-Reply-To: <E98E4E57-2322-412F-A58E-A0CCC39DDCE3@kernel.crashing.org>
On May 1, 2007, at 10:38 PM, Kumar Gala wrote:
>
> On Apr 24, 2007, at 12:46 AM, Stefan Roese wrote:
>
>> On Tuesday 24 April 2007 02:12, Roland Dreier wrote:
>>>>> I recall dimly that there was some user-visible difference
>>>>> between the
>>>>> 440GP and the other 440 processors, and that's why we made the
>>>>> platform string different. I don't recall what the difference
>>>>> was.
>>>
>>> FWIW, I've run the same userspace (binaries) on 405GPr, 440GP and
>>> 440SPe without any problems. Not that I'm a 4xx expert by any
>>> stretch, but I don't know of anything special about the 440GP.
>>
>> I don't know of any differences either. So I'm voting to change the
>> platform
>> to ppc440 too.
>
> After some discussion with Paul we think we figured out why 440GP was
> marked differently. I doesn't implement 'isel', and all other
> 440's do.
This whole discussion makes me wondering what defines a new cpu table
platform? I know one application of this value is for being able to
pick "platform" specific/tuned libraries. Are there other uses?
If its just for libraries wouldn't the existence of FPUs and SPE/
Altivec warrant different platform types?
- k
^ permalink raw reply
* [PATCH] ehea: Fix skb header access
From: Thomas Klein @ 2007-05-02 14:07 UTC (permalink / raw)
To: Jeff Garzik
Cc: Thomas Klein, Jan-Bernd Themann, netdev, linux-kernel,
Christoph Raisch, Stefan Roscher, linux-ppc, Marcus Eder
Adapt to new skb header access functions.
Signed-off-by: Thomas Klein <tklein@de.ibm.com>
---
diff --git a/drivers/net/ehea/ehea_main.c b/drivers/net/ehea/ehea_main.c
index c7a5614..7211648 100644
--- a/drivers/net/ehea/ehea_main.c
+++ b/drivers/net/ehea/ehea_main.c
@@ -1803,10 +1803,10 @@ static inline int ehea_hash_skb(struct s
u32 tmp;
if ((skb->protocol == htons(ETH_P_IP)) &&
- (skb->nh.iph->protocol == IPPROTO_TCP)) {
- tcp = (struct tcphdr*)(skb->nh.raw + (skb->nh.iph->ihl * 4));
+ (ip_hdr(skb)->protocol == IPPROTO_TCP)) {
+ tcp = (struct tcphdr*)(skb_network_header(skb) + (ip_hdr(skb)->ihl * 4));
tmp = (tcp->source + (tcp->dest << 16)) % 31;
- tmp += skb->nh.iph->daddr % 31;
+ tmp += ip_hdr(skb)->daddr % 31;
return tmp % num_qps;
}
else
^ permalink raw reply related
* Re: [RFC] uartlite driver MicroBlaze compatability
From: Peter Korsgaard @ 2007-05-02 14:09 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <528646bc0705012247p4a0fff63oa8d98364d5f639b0@mail.gmail.com>
>>>>> "GL" == Grant Likely <grant.likely@secretlab.ca> writes:
Hi,
GL> Hmm, I think I was smoking something last night.
;)
GL> Address used for 8 bit access should not be affected by CPU
GL> endianess. After David's comments, I reread the uartlite
GL> documentation. The current design is definately for 32bit OPB bus
GL> connections, but it looks like there is a posibility for xilinx to
GL> add a 16 or 8 bit attachment. Since the uartlite design
GL> explicitly supports 8, 16 and 32 bit access, sticking with 8 bit
GL> io may be the safest. However, I still think the application of
GL> the 3 byte offset should be done in the driver, and not in the
GL> platform bus registration.
That would effectively make the driver big endian only. What if Xilinx
would come out with a FPGA with a ARM core in it?
GL> I've reworked the patch with the following changes - remove 3 byte
GL> offset from platform bus registration. - added ulite_in/ulite_out
GL> macros to make changing bus attachment details simpler if xilinx
GL> changes the uartlite design. - stick with 8 bit IO.
Russell didn't like those accessor macros back when it was submitted
last year:
http://thread.gmane.org/gmane.linux.serial/1237/focus=1251
--
Bye, Peter Korsgaard
^ permalink raw reply
* Re: patches for 2.6.22
From: Kumar Gala @ 2007-05-02 14:12 UTC (permalink / raw)
To: Kim Phillips; +Cc: linuxppc-dev list, Paul Mackerras, jeff Garzik, netdev
In-Reply-To: <20070430145119.6713490e.kim.phillips@freescale.com>
On Apr 30, 2007, at 2:51 PM, Kim Phillips wrote:
> On Fri, 27 Apr 2007 21:25:19 +1000
> Paul Mackerras <paulus@samba.org> wrote:
>
>> If anyone has patches that I haven't picked up yet which they think
>> should go into 2.6.22, please send me either a pointer to the
>
> these were missed:
>
> [PATCH 1/4 v5] powerpc: document phy-connection-type property
> Tue Apr 24 07:26:10 EST 2007
> http://ozlabs.org/pipermail/linuxppc-dev/2007-April/034669.html
ok.
> [PATCH 2/4 v4] powerpc: replace undocumented interface properties
> in dts files
> Tue Apr 24 07:26:14 EST 2007
> http://ozlabs.org/pipermail/linuxppc-dev/2007-April/034670.html
I have issues with this since it looks like the current ucc driver in
linus's tree is using a previous rev of your patch and thus using
interface-type and max-speed still.
> [PATCH 3/4] powerpc: Add 'mdio' to bus scan id list for platforms
> with QE UEC
> Wed Apr 11 07:56:49 EST 2007
> http://ozlabs.org/pipermail/linuxppc-dev/2007-April/034163.html
ok
>
> [PATCH 4/4] powerpc: turn on corresponding PHY drivers in QE UEC
> platforms defconfigs
> Wed Apr 11 07:56:53 EST 2007
> http://ozlabs.org/pipermail/linuxppc-dev/2007-April/034164.html
ok
I'll pull patches 1, 3, 4 and wait on the dts changes until you sort
of the ucc driver issues with Jeff.
- k
^ permalink raw reply
* Re: [PATCH 2/2] Rename get_property to of_get_property: drivers/net
From: Kumar Gala @ 2007-05-02 14:15 UTC (permalink / raw)
To: David Miller; +Cc: sfr, jeff, netdev, linuxppc-dev, paulus, akpm
In-Reply-To: <20070428.204754.62343452.davem@davemloft.net>
On Apr 28, 2007, at 10:47 PM, David Miller wrote:
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Sun, 29 Apr 2007 11:44:46 +1000
>
>> So can I take this as a future OK for architecture specific network
>> drivers changes to go through the architecture trees (cc'd to you)?
>
> It's been my experience that if I'm just working through some
> platform or bus specific API changes, people like Jeff tend to
> not mind if it goes via ARCH trees and the like.
Is this acceptable? Just want to make sure before I ask Paul to
pull some changes that touches the following drivers:
drivers/net/fs_enet/mac-scc.c | 2 +-
drivers/net/ucc_geth.c | 30 ++++----
drivers/serial/cpm_uart/cpm_uart_cpm1.c | 4 +-
drivers/serial/cpm_uart/cpm_uart_cpm2.c | 4 +-
But is related to an arch API cleanup.
- k
^ permalink raw reply
* Re: [PATCH 2/2] Rename get_property to of_get_property: drivers/net
From: Jeff Garzik @ 2007-05-02 14:17 UTC (permalink / raw)
To: Kumar Gala; +Cc: sfr, netdev, linuxppc-dev, paulus, akpm, David Miller
In-Reply-To: <3802D7AD-67EC-4FA2-B361-A388AFCB0B94@kernel.crashing.org>
Kumar Gala wrote:
>
> On Apr 28, 2007, at 10:47 PM, David Miller wrote:
>
>> From: Stephen Rothwell <sfr@canb.auug.org.au>
>> Date: Sun, 29 Apr 2007 11:44:46 +1000
>>
>>> So can I take this as a future OK for architecture specific network
>>> drivers changes to go through the architecture trees (cc'd to you)?
>>
>> It's been my experience that if I'm just working through some
>> platform or bus specific API changes, people like Jeff tend to
>> not mind if it goes via ARCH trees and the like.
>
> Is this acceptable? Just want to make sure before I ask Paul to pull
> some changes that touches the following drivers:
>
> drivers/net/fs_enet/mac-scc.c | 2 +-
> drivers/net/ucc_geth.c | 30 ++++----
> drivers/serial/cpm_uart/cpm_uart_cpm1.c | 4 +-
> drivers/serial/cpm_uart/cpm_uart_cpm2.c | 4 +-
I don't see a patch, just a diffstat.
Jeff
^ permalink raw reply
* [PATCH v4] powerpc: 64K page support for kexec
From: Luke Browning @ 2007-05-02 14:19 UTC (permalink / raw)
To: Olof Johansson
Cc: Arnd Bergmann, miltonm, linuxppc-dev, Paul Mackerras, cbe-oss-dev
In-Reply-To: <20070426223228.GA30000@lixom.net>
This patch fixes a couple of kexec problems related to 64K page
support in the kernel. kexec issues a tlbie for each pte. The
parameters for the tlbie are the page size and the virtual address.
Support was missing for the computation of these two parameters
for 64K pages. This patch adds that support.
Same as previous versions without BUG_ON()s.
Signed-off-by: Luke Browning <lukebrowning@us.ibm.com>
Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Acked-by: Olof Johansson <olof@lixom.net>
Index: linux-2.6.21-rc4/arch/powerpc/mm/hash_native_64.c
===================================================================
--- linux-2.6.21-rc4.orig/arch/powerpc/mm/hash_native_64.c
+++ linux-2.6.21-rc4/arch/powerpc/mm/hash_native_64.c
@@ -26,6 +26,7 @@
#include <asm/tlb.h>
#include <asm/cputable.h>
#include <asm/udbg.h>
+#include <asm/kexec.h>
#ifdef DEBUG_LOW
#define DBG_LOW(fmt...) udbg_printf(fmt)
@@ -340,31 +341,70 @@ static void native_hpte_invalidate(unsig
local_irq_restore(flags);
}
-/*
- * XXX This need fixing based on page size. It's only used by
- * native_hpte_clear() for now which needs fixing too so they
- * make a good pair...
- */
-static unsigned long slot2va(unsigned long hpte_v, unsigned long slot)
-{
- unsigned long avpn = HPTE_V_AVPN_VAL(hpte_v);
- unsigned long va;
-
- va = avpn << 23;
-
- if (! (hpte_v & HPTE_V_LARGE)) {
- unsigned long vpi, pteg;
+#define LP_SHIFT 12
+#define LP_BITS 8
+#define LP_MASK(i) ((0xFF >> (i)) << LP_SHIFT)
+
+static void hpte_decode(hpte_t *hpte, unsigned long slot,
+ int *psize, unsigned long *va)
+{
+ unsigned long hpte_r = hpte->r;
+ unsigned long hpte_v = hpte->v;
+ unsigned long avpn;
+ int i, size, shift, penc, avpnm_bits;
+
+ if (!(hpte_v & HPTE_V_LARGE))
+ size = MMU_PAGE_4K;
+ else {
+ for (i = 0; i < LP_BITS; i++) {
+ if ((hpte_r & LP_MASK(i+1)) == LP_MASK(i+1))
+ break;
+ }
+ penc = LP_MASK(i+1) >> LP_SHIFT;
+ for (size = 0; size < MMU_PAGE_COUNT; size++) {
- pteg = slot / HPTES_PER_GROUP;
- if (hpte_v & HPTE_V_SECONDARY)
- pteg = ~pteg;
+ /* 4K pages are not represented by LP */
+ if (size == MMU_PAGE_4K)
+ continue;
+
+ /* valid entries have a shift value */
+ if (!mmu_psize_defs[size].shift)
+ continue;
- vpi = ((va >> 28) ^ pteg) & htab_hash_mask;
+ if (penc == mmu_psize_defs[size].penc)
+ break;
+ }
+ }
- va |= vpi << PAGE_SHIFT;
+ /*
+ * FIXME, the code below works for 16M, 64K, and 4K pages as these
+ * fall under the p<=23 rules for calculating the virtual address.
+ * In the case of 16M pages, an extra bit is stolen from the AVPN
+ * field to achieve the requisite 24 bits.
+ *
+ * Does not work for 16G pages or 1 TB segments.
+ */
+ shift = mmu_psize_defs[size].shift;
+ if (mmu_psize_defs[size].avpnm)
+ avpnm_bits = __ilog2_u64(mmu_psize_defs[size].avpnm) + 1;
+ else
+ avpnm_bits = 0;
+ if (shift - avpnm_bits <= 23) {
+ avpn = HPTE_V_AVPN_VAL(hpte_v) << 23;
+
+ if (shift < 23) {
+ unsigned long vpi, pteg;
+
+ pteg = slot / HPTES_PER_GROUP;
+ if (hpte_v & HPTE_V_SECONDARY)
+ pteg = ~pteg;
+ vpi = ((avpn >> 28) ^ pteg) & htab_hash_mask;
+ avpn |= (vpi << mmu_psize_defs[size].shift);
+ }
}
- return va;
+ *va = avpn;
+ *psize = size;
}
/*
@@ -374,15 +414,14 @@ static unsigned long slot2va(unsigned lo
*
* TODO: add batching support when enabled. remember, no dynamic memory here,
* athough there is the control page available...
- *
- * XXX FIXME: 4k only for now !
*/
static void native_hpte_clear(void)
{
unsigned long slot, slots, flags;
hpte_t *hptep = htab_address;
- unsigned long hpte_v;
+ unsigned long hpte_v, va;
unsigned long pteg_count;
+ int psize;
pteg_count = htab_hash_mask + 1;
@@ -408,8 +447,9 @@ static void native_hpte_clear(void)
* already hold the native_tlbie_lock.
*/
if (hpte_v & HPTE_V_VALID) {
+ hpte_decode(hptep, slot, &psize, &va);
hptep->v = 0;
- __tlbie(slot2va(hpte_v, slot), MMU_PAGE_4K);
+ __tlbie(va, psize);
}
}
^ permalink raw reply
* Re: patches for 2.6.22
From: Kim Phillips @ 2007-05-02 14:19 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, paulus, jeff, netdev
In-Reply-To: <42664CF1-75AF-4343-BC50-870D3614C683@kernel.crashing.org>
On Wed, 2 May 2007 09:12:36 -0500
Kumar Gala <galak@kernel.crashing.org> wrote:
>
> I'll pull patches 1, 3, 4 and wait on the dts changes until you sort
> of the ucc driver issues with Jeff.
sounds good. I was waiting for the get_property -> of_get_propery
patches for ucc_geth before I submitted the follow-on patch to change
interface-type and remove max-speed. It's out now, so I can proceed.
Kim
^ permalink raw reply
* Re: [PATCH] Remove duplicate export of __div64_32.
From: Kumar Gala @ 2007-05-02 14:20 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, paulus
In-Reply-To: <20070501160538.GA24292@ld0162-tx32.am.freescale.net>
On May 1, 2007, at 11:05 AM, Scott Wood wrote:
> Change 3927f2e8f9afa3424bb51ca81f7abac01ffd0005 moved lib/lib64.c from
> lib-y to obj-y, preventing the export in ppc_ksyms.c from overriding
> the one in lib, and thus causing a duplicate-export warning.
I assume you mean lib/div64.c?
- k
^ permalink raw reply
* [PATCH] powerpc timer sysdev: use mktime
From: Johannes Berg @ 2007-05-02 14:25 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <17976.5964.593278.752595@cargo.ozlabs.ibm.com>
This patch makes the timer sysdev use mktime instead of rtc_tm_to_time
by simply copying the function to avoid using rtc-lib.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
--- wireless-dev.orig/arch/powerpc/sysdev/timer.c 2007-05-02 16:16:52.639177080 +0200
+++ wireless-dev/arch/powerpc/sysdev/timer.c 2007-05-02 16:21:56.429177080 +0200
@@ -24,7 +24,12 @@ static int timer_resume(struct sys_devic
/* get current RTC time and convert to seconds */
get_rtc_time(&cur_rtc_tm);
- rtc_tm_to_time(&cur_rtc_tm, &cur_rtc_time);
+ cur_rtc_time = mktime(cur_rtc_tm.tm_year + 1900,
+ cur_rtc_tm.tm_mon + 1,
+ cur_rtc_tm.tm_mday,
+ cur_rtc_tm.tm_hour,
+ cur_rtc_tm.tm_min,
+ cur_rtc_tm.tm_sec);
diff = cur_rtc_time - suspend_rtc_time;
@@ -44,7 +49,12 @@ static int timer_suspend(struct sys_devi
WARN_ON(!ppc_md.get_rtc_time);
get_rtc_time(&suspend_rtc_tm);
- rtc_tm_to_time(&suspend_rtc_tm, &suspend_rtc_time);
+ suspend_rtc_time = mktime(suspend_rtc_tm.tm_year + 1900,
+ suspend_rtc_tm.tm_mon + 1,
+ suspend_rtc_tm.tm_mday,
+ suspend_rtc_tm.tm_hour,
+ suspend_rtc_tm.tm_min,
+ suspend_rtc_tm.tm_sec);
return 0;
}
--- wireless-dev.orig/arch/powerpc/Kconfig 2007-05-02 16:22:07.619177080 +0200
+++ wireless-dev/arch/powerpc/Kconfig 2007-05-02 16:22:12.759177080 +0200
@@ -11,11 +11,6 @@ config PPC64
This option selects whether a 32-bit or a 64-bit kernel
will be built.
-config PPC_PM_NEEDS_RTC_LIB
- bool
- select RTC_LIB
- default y if PM
-
config PPC32
bool
default y if !PPC64
^ permalink raw reply
* Re: [patch 0/8] PS3 AV/FB patches
From: René Rebe @ 2007-05-02 14:03 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Geert Uytterhoeven
In-Reply-To: <20070502124830.911142000@pademelon.sonytel.be>
Hi Geert,
On Wednesday 02 May 2007 14:48:30 Geert Uytterhoeven wrote:
> Hi Linus, Andrew,
>=20
> Here are our patches for the PS3 Audio Video Settings and Virtual Frame
> Buffer
> drivers for 2.6.22:
>=20
> [1/8] ps3fb: thread updates
> [2/8] ps3fb: atomic fixes
> [3/8] ps3av: thread updates
> [4/8] ps3fb: kill superfluous zero initializations
> [5/8] ps3av: misc updates
> [6/8] [PATCH] ps3: Make `ps3videomode -v 0' (auto mode) work again
> [7/8] ps3fb: Use __func__ instead of __FUNCTION__
> [8/8] ps3av: Use __func__ instead of __FUNCTION__
>=20
> The last 3 are new, but they are quite simple/trivial.
while at the ps3fb code I wonder if the initiator of the RSX petition ever =
spoke
with some Sony related kernel hackers regarding allowing any kind of
acceleration:
http://www.petitiononline.com/RSX/petition.html
While 3d acceleration is not that important for me on the PS3, just specifi=
ng
a exact resolution, to e.g. drive non-TV display, does also not appear to be
possible with the current ps3fb code and the hypervisor, only TV resolutions
are support, right?
Is there any chance we can get at least modesetting and basic 2D accelerati=
on
(best some alpha-bitblt & colorspace conversion + scaling)?
Yours,
=2D-=20
Ren=E9 Rebe - ExactCODE GmbH - Europe, Germany, Berlin
http://exactcode.de | http://t2-project.org | http://rene.rebe.name
^ permalink raw reply
* [PATCH v2] via-pmu: remove LED sleep notifier
From: Johannes Berg @ 2007-05-02 14:32 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <20070502205741.72dc191b.sfr@canb.auug.org.au>
The generic LED code now makes sure that suspended devices don't blink,
so we no longer need to do it ourselves. For the suspend to disk case,
however, we need to make sure that we don't blink if the PMU sysdev
was suspended before the LED device.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
drivers/macintosh/via-pmu-led.c | 35 +++--------------------------------
drivers/macintosh/via-pmu.c | 2 +-
include/linux/pmu.h | 3 +++
3 files changed, 7 insertions(+), 33 deletions(-)
--- wireless-dev.orig/drivers/macintosh/via-pmu-led.c 2007-05-02 10:46:52.289190072 +0200
+++ wireless-dev/drivers/macintosh/via-pmu-led.c 2007-05-02 16:31:37.019177080 +0200
@@ -31,7 +31,6 @@ static spinlock_t pmu_blink_lock;
static struct adb_request pmu_blink_req;
/* -1: no change, 0: request off, 1: request on */
static int requested_change;
-static int sleeping;
static void pmu_req_done(struct adb_request * req)
{
@@ -41,7 +40,7 @@ static void pmu_req_done(struct adb_requ
/* if someone requested a change in the meantime
* (we only see the last one which is fine)
* then apply it now */
- if (requested_change != -1 && !sleeping)
+ if (requested_change != -1 && !pmu_sys_suspended)
pmu_request(&pmu_blink_req, NULL, 4, 0xee, 4, 0, requested_change);
/* reset requested change */
requested_change = -1;
@@ -66,7 +65,7 @@ static void pmu_led_set(struct led_class
break;
}
/* if request isn't done, then don't do anything */
- if (pmu_blink_req.complete && !sleeping)
+ if (pmu_blink_req.complete && !pmu_sys_suspended)
pmu_request(&pmu_blink_req, NULL, 4, 0xee, 4, 0, requested_change);
out:
spin_unlock_irqrestore(&pmu_blink_lock, flags);
@@ -80,32 +79,6 @@ static struct led_classdev pmu_led = {
.brightness_set = pmu_led_set,
};
-#ifdef CONFIG_PM
-static void pmu_led_sleep_call(struct pmu_sleep_notifier *self, int when)
-{
- unsigned long flags;
-
- spin_lock_irqsave(&pmu_blink_lock, flags);
-
- switch (when) {
- case PBOOK_SLEEP_REQUEST:
- sleeping = 1;
- break;
- case PBOOK_WAKE:
- sleeping = 0;
- break;
- default:
- /* do nothing */
- break;
- }
- spin_unlock_irqrestore(&pmu_blink_lock, flags);
-}
-
-static struct pmu_sleep_notifier via_pmu_led_sleep_notif = {
- .notifier_call = pmu_led_sleep_call,
-};
-#endif
-
static int __init via_pmu_led_init(void)
{
struct device_node *dt;
@@ -135,9 +108,7 @@ static int __init via_pmu_led_init(void)
/* no outstanding req */
pmu_blink_req.complete = 1;
pmu_blink_req.done = pmu_req_done;
-#ifdef CONFIG_PM
- pmu_register_sleep_notifier(&via_pmu_led_sleep_notif);
-#endif
+
return led_classdev_register(NULL, &pmu_led);
}
--- wireless-dev.orig/drivers/macintosh/via-pmu.c 2007-05-02 10:46:52.319190072 +0200
+++ wireless-dev/drivers/macintosh/via-pmu.c 2007-05-02 16:30:42.849177080 +0200
@@ -2759,7 +2759,7 @@ pmu_polled_request(struct adb_request *r
#if defined(CONFIG_PM) && defined(CONFIG_PPC32)
-static int pmu_sys_suspended;
+int pmu_sys_suspended;
static int pmu_sys_suspend(struct sys_device *sysdev, pm_message_t state)
{
--- wireless-dev.orig/include/linux/pmu.h 2007-05-02 16:30:48.519177080 +0200
+++ wireless-dev/include/linux/pmu.h 2007-05-02 16:31:29.619177080 +0200
@@ -225,4 +225,7 @@ extern unsigned int pmu_power_flags;
/* Backlight */
extern void pmu_backlight_init(void);
+/* some code needs to know if the PMU was suspended for hibernation */
+extern int pmu_sys_suspended;
+
#endif /* __KERNEL__ */
^ permalink raw reply
* Re: [PATCH] powermac: support G5 CPU hotplug
From: Johannes Berg @ 2007-05-02 14:33 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <17976.28170.695715.416339@cargo.ozlabs.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 288 bytes --]
On Wed, 2007-05-02 at 20:55 +1000, Paul Mackerras wrote:
> Ultimately we want to put the disabled cpus in sleep mode, but that
> will require a suitable cache flush routine.
I don't have any docs for the particular processors the G5s have, do
they have a sleep mode?
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 190 bytes --]
^ permalink raw reply
* Re: [patch 0/8] PS3 AV/FB patches
From: Geert Uytterhoeven @ 2007-05-02 14:53 UTC (permalink / raw)
To: René Rebe; +Cc: linuxppc-dev
In-Reply-To: <200705021603.34637.rene@exactcode.de>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: TEXT/PLAIN; charset=UTF-8, Size: 931 bytes --]
Hi René,
On Wed, 2 May 2007, [iso-8859-1] René Rebe wrote:
> While 3d acceleration is not that important for me on the PS3, just specifing
> a exact resolution, to e.g. drive non-TV display, does also not appear to be
> possible with the current ps3fb code and the hypervisor, only TV resolutions
> are support, right?
In addition to the TV resolutions 480i/480p/720p/1080i/1080p in 50/60 Hz,
ps3fb supports 1280x768 (WXGA), 1280x1024 (SXGA), and 1920x1200 (WUXGA).
> Is there any chance we can get at least modesetting and basic 2D acceleration
> (best some alpha-bitblt & colorspace conversion + scaling)?
These requests are definitely considered.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- Sony Network and Software Technology Center Europe (NSCE)
Geert.Uytterhoeven@sonycom.com ------- The Corporate Village, Da Vincilaan 7-D1
Voice +32-2-7008453 Fax +32-2-7008622 ---------------- B-1935 Zaventem, Belgium
^ permalink raw reply
* Re: [patch 0/8] PS3 AV/FB patches
From: René Rebe @ 2007-05-02 15:05 UTC (permalink / raw)
To: Geert Uytterhoeven; +Cc: linuxppc-dev
In-Reply-To: <Pine.LNX.4.62.0705021650290.3706@pademelon.sonytel.be>
Hi again,
On Wednesday 02 May 2007 16:53:49 Geert Uytterhoeven wrote:
> Hi Ren=E9,
>=20
> On Wed, 2 May 2007, [iso-8859-1] Ren=E9 Rebe wrote:
> > While 3d acceleration is not that important for me on the PS3, just spe=
cifing
> > a exact resolution, to e.g. drive non-TV display, does also not appear =
to be
> > possible with the current ps3fb code and the hypervisor, only TV resolu=
tions
> > are support, right?
>=20
> In addition to the TV resolutions 480i/480p/720p/1080i/1080p in 50/60 Hz,
> ps3fb supports 1280x768 (WXGA), 1280x1024 (SXGA), and 1920x1200 (WUXGA).
Ok fair enough I forgot to mention the {W,S}XGA ones - actually after the s=
tatic list
of the user-land helper I read the kernel side code already to see if there=
is something
else that can be passed to the hypervisor.
I mean more the currently also common modes such as: 1680x1050 and co.
> > Is there any chance we can get at least modesetting and basic 2D accele=
ration
> > (best some alpha-bitblt & colorspace conversion + scaling)?
>=20
> These requests are definitely considered.
Nice to hear. I keep pressing my thumbs.
Yours,
=2D-=20
Ren=C3=A9 Rebe - ExactCODE GmbH - Europe, Germany, Berlin
http://exactcode.de | http://t2-project.org | http://rene.rebe.name
^ permalink raw reply
* Re: [PATCH 1/6] powerpc: split out CPU specific options into a new Kconfig file
From: Timur Tabi @ 2007-05-02 15:54 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linuxppc-dev, paulus
In-Reply-To: <20070502115644.638734471@arndb.de>
Arnd Bergmann wrote:
> +config CLASSIC32
> + bool "52xx/6xx/7xx/74xx"
> + select PPC_FPU
> + select 6xx
> + help
> + There are four families of PowerPC chips supported. The more common
> + types (601, 603, 604, 740, 750, 7400), the Motorola embedded
> + versions (821, 823, 850, 855, 860, 52xx, 82xx, 83xx), the AMCC
> + embedded versions (403 and 405) and the high end 64 bit Power
> + processors (POWER 3, POWER4, and IBM PPC970 also known as G5).
Is this help text still accurate? The bool line says "52xx/6xx/7xx/74xx", but you talk
about many more processors in the help text. You mention the 83xx, but not the 85xx or
86xx, nor do you mention Freescale. Not only that, but the help text implies that 8xx,
52xx, 82xx, and 83xx are part of the same family, but the bool text implies that 52xx is
part of a different family.
> + This option is the catch-all for 6xx types, including some of the
> + embedded versions. Unless there is see an option for the specific
> + chip family you are using, you want this option.
So CLASSIC32 is only for 6xx families, not any of the others? Then what's the "select
6xx" for? Isn't that redundant?
> + You do not want this if you are building a kernel for a 64 bit
> + IBM RS/6000 or an Apple G5, choose 6xx.
This needs to be reworded, as the English doesn't make sense.
--
Timur Tabi
Linux Kernel Developer @ Freescale
^ permalink raw reply
* Re: [PATCH 2/2] Rename get_property to of_get_property: drivers/net
From: Kumar Gala @ 2007-05-02 15:53 UTC (permalink / raw)
To: Jeff Garzik; +Cc: sfr, netdev, linuxppc-dev, paulus, akpm, David Miller
In-Reply-To: <46389D85.7000301@garzik.org>
On May 2, 2007, at 9:17 AM, Jeff Garzik wrote:
> Kumar Gala wrote:
>> On Apr 28, 2007, at 10:47 PM, David Miller wrote:
>>> From: Stephen Rothwell <sfr@canb.auug.org.au>
>>> Date: Sun, 29 Apr 2007 11:44:46 +1000
>>>
>>>> So can I take this as a future OK for architecture specific network
>>>> drivers changes to go through the architecture trees (cc'd to you)?
>>>
>>> It's been my experience that if I'm just working through some
>>> platform or bus specific API changes, people like Jeff tend to
>>> not mind if it goes via ARCH trees and the like.
>> Is this acceptable? Just want to make sure before I ask Paul to
>> pull some changes that touches the following drivers:
>> drivers/net/fs_enet/mac-scc.c | 2 +-
>> drivers/net/ucc_geth.c | 30 ++++----
>> drivers/serial/cpm_uart/cpm_uart_cpm1.c | 4 +-
>> drivers/serial/cpm_uart/cpm_uart_cpm2.c | 4 +-
>
> I don't see a patch, just a diffstat.
I haven't sent a patch, just asking the question if I need to break
it up or not.
- k
^ permalink raw reply
* better compression: 1.0MB for defconfig-minimal kernel
From: John Reiser @ 2007-05-02 15:49 UTC (permalink / raw)
To: linuxppc-embedded
upx --lzma compresses much tighter than gzip.
A user-mode test jig succesfully handles the 2.6.21.1 kernel
configured with defconfig-minimal in 1,018,237 bytes total,
in contrast to the 1,390,765 bytes of vmlinux.bin.gz (and the .gz
does not include 34,795 bytes for compiled arch/powerpc/boot/*.c.)
However, I cannot figure out how to get a real bootable kernel
that uses compression. I'd like to test it on an Apple PowerMac G4
that now runs Fedora Core 6. The FC6 kernel calls itself "vmlinuz"
but does _not_ use any compression; I double-checked by rebuilding
from the .src.rpm.
A plain "make" in a kernel.org-2.6.21.1 tree gives a vmlinux that is
not compressed. A "make zImage" produces arch/powerpc/boot/uImage
[with no thanks to the *undocumented* mkimage] that uses gzip,
but does not use any code from arch/powerpc/boot/*.c; so where is
the decompression code?
linux/Documentation/powerpc/*.txt does not shed light on these issues.
Please point me at a description of the flow of control for
building and booting a compressed Linux kernel for powerpc. Thank you.
--
^ permalink raw reply
* Re: [RFC] uartlite driver MicroBlaze compatability
From: Grant Likely @ 2007-05-02 15:59 UTC (permalink / raw)
To: Peter Korsgaard; +Cc: linuxppc-embedded
In-Reply-To: <87wszr48sc.fsf@sleipner.barco.com>
On 5/2/07, Peter Korsgaard <peter.korsgaard@barco.com> wrote:
> >>>>> "GL" == Grant Likely <grant.likely@secretlab.ca> writes:
>
> Hi,
>
> GL> Hmm, I think I was smoking something last night.
>
> ;)
>
> GL> Address used for 8 bit access should not be affected by CPU
> GL> endianess. After David's comments, I reread the uartlite
> GL> documentation. The current design is definately for 32bit OPB bus
> GL> connections, but it looks like there is a posibility for xilinx to
> GL> add a 16 or 8 bit attachment. Since the uartlite design
> GL> explicitly supports 8, 16 and 32 bit access, sticking with 8 bit
> GL> io may be the safest. However, I still think the application of
> GL> the 3 byte offset should be done in the driver, and not in the
> GL> platform bus registration.
>
> That would effectively make the driver big endian only. What if Xilinx
> would come out with a FPGA with a ARM core in it?
It shouldn't. When doing byte-wise access, byte 3 is *always* byte 3;
regardless of the endianess of the processor. It's the endianess of
the device that determines where the individual bytes show up. The
opb_uartlite documentation defines the registers as big endian,
therefore if you do a bytewise access to address 0x3, you'll always
get the least significant byte of the first register.
Since the 3 byte offset does not change between little endian and big
endian processors then I think the knowledge of the offset should be
kept in the driver, not the device registration.
>
> GL> I've reworked the patch with the following changes - remove 3 byte
> GL> offset from platform bus registration. - added ulite_in/ulite_out
> GL> macros to make changing bus attachment details simpler if xilinx
> GL> changes the uartlite design. - stick with 8 bit IO.
>
> Russell didn't like those accessor macros back when it was submitted
> last year:
>> +static inline void serial_out(struct uart_port *port, int offset, int
Russell> Since there's no additional complication here, do you need separate
Russell> serial_in/serial_out inline functions?
As I think the driver should know about the 3 byte offset; the
accessor macro makes sense again. Plus if Xilinx ever adds a uartlite
varient w/ bytewise or halfword wise registers it becomes much easier
to taylor in the future.
Cheers,
g.
--
Grant Likely, B.Sc. P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: [PATCH 2/2] Rename get_property to of_get_property: drivers/net
From: Jeff Garzik @ 2007-05-02 16:00 UTC (permalink / raw)
To: Kumar Gala; +Cc: sfr, netdev, linuxppc-dev, paulus, akpm, David Miller
In-Reply-To: <9B877BC8-C064-4CD1-9325-5C3EA925346E@kernel.crashing.org>
Kumar Gala wrote:
>
> On May 2, 2007, at 9:17 AM, Jeff Garzik wrote:
>
>> Kumar Gala wrote:
>>> On Apr 28, 2007, at 10:47 PM, David Miller wrote:
>>>> From: Stephen Rothwell <sfr@canb.auug.org.au>
>>>> Date: Sun, 29 Apr 2007 11:44:46 +1000
>>>>
>>>>> So can I take this as a future OK for architecture specific network
>>>>> drivers changes to go through the architecture trees (cc'd to you)?
>>>>
>>>> It's been my experience that if I'm just working through some
>>>> platform or bus specific API changes, people like Jeff tend to
>>>> not mind if it goes via ARCH trees and the like.
>>> Is this acceptable? Just want to make sure before I ask Paul to
>>> pull some changes that touches the following drivers:
>>> drivers/net/fs_enet/mac-scc.c | 2 +-
>>> drivers/net/ucc_geth.c | 30 ++++----
>>> drivers/serial/cpm_uart/cpm_uart_cpm1.c | 4 +-
>>> drivers/serial/cpm_uart/cpm_uart_cpm2.c | 4 +-
>>
>> I don't see a patch, just a diffstat.
>
> I haven't sent a patch, just asking the question if I need to break it
> up or not.
Without seeing the patch, I have no idea...
Jeff
^ permalink raw reply
* Re: [PATCH] gianfar: Add I/O barriers when touching buffer descriptor ownership.
From: Scott Wood @ 2007-05-02 16:04 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: netdev, jgarzik, linuxppc-dev
In-Reply-To: <65f0b79871a670eb595cca7d78e2f4e9@kernel.crashing.org>
Segher Boessenkool wrote:
>> The hardware must not see that is given ownership of a buffer until it is
>> completely written, and when the driver receives ownership of a buffer,
>> it must ensure that any other reads to the buffer reflect its final
>> state. Thus, I/O barriers are added where required.
>>
>> Without this patch, I have observed GCC reordering the setting of
>> bdp->length and bdp->status in gfar_new_skb.
>
>
> The :::"memory" in the barriers you used prevent GCC
> from reordering accesses around the barriers.
Sure... it was just an example to point out that it's actually
happening, rather than a theoretical concern.
> AFAICS you need stronger barriers though; {w,r,}mb(),
> to prevent _any_ reordering of those memory accesses,
> not just the compiler-generated ones.
My impression was that the eieio used by iobarrier would be sufficient
for that, as we're not trying to synchronize between accesses to
different types of memory. Is sync really required here?
-Scott
^ 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