LinuxPPC-Dev Archive on lore.kernel.org
 help / color / mirror / Atom feed
* Re: The question about the UART on UCC5,UCC6,UCC7,UCC8 for MPC8360?
From: Timur Tabi @ 2007-11-26 15:33 UTC (permalink / raw)
  To: ??; +Cc: linuxppc-embedded
In-Reply-To: <396048835.09329@tsinghua.org.cn>

?? wrote:

>   after compiled, I download the linux to MPC8360 board, but I cannot find the
> serial device for UCC5,UCC6,UCC7,UCC8. I just find the ttyS0,ttyS1 is OK.
>   Could you tell me that what's the name for the serial device of UCC5,6,7,8?
>   Whether or not I can use those UART just like the ttyS0,ttyS1?

I don't know why the BSP offers a UART driver for the 8360, because the driver 
isn't available yet.  I'm working on that, though.  I'll post the driver in a 
week or so, and it will be included in 2.6.25.  You'll have to ask the BSP 
support line if they plan on updating the BSP to include the new driver.

-- 
Timur Tabi
Linux kernel developer at Freescale

^ permalink raw reply

* Re: [PATCH 1/3] [POWERPC] Add docs for Freescale 83xx SATA device tree nodes
From: Arnd Bergmann @ 2007-11-26 16:06 UTC (permalink / raw)
  To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <CAF0919C-0116-403C-A8C5-024B43480D77@kernel.crashing.org>

On Monday 26 November 2007, you wrote:
> On Nov 25, 2007, at 4:22 PM, Arnd Bergmann wrote:

> > Should this maybe also mandate a compatible property that is defined
> > in a way to match the generic (p)ata_of_platform driver?
>=20
> Is there something about the (p)ata_of_platform driver you think we =A0
> can use. =A0The SATA controller here is a unique piece of HW and =A0
> requires a unique driver so I'm not sure what we get from =A0
> (p)ata_of_platform.

All ata controllers I've dealt with so far are to some degree compatible
to the old PC style controllers. My point was that this should ideally
be reflected in the device tree so that you could in theory use the
ata_of_platform driver, even if you normally would prefer the new
driver for performance reasons.

If your controller doesn't have the legacy register set, this clearly
doesn't make any sense and you should not list it as compatible with
something generic.

	Arnd <><

^ permalink raw reply

* Re: Sequoia EMAC only works if u-boot initializes it?
From: Josh Boyer @ 2007-11-26 16:08 UTC (permalink / raw)
  To: Steven A. Falco; +Cc: linuxppc-dev
In-Reply-To: <474AED67.4020006@harris.com>

On Mon, 26 Nov 2007 10:59:35 -0500
"Steven A. Falco" <sfalco@harris.com> wrote:

> I have noticed odd behavior on a Sequoia board.  Kernel is built from 
> DENX git, ARCH=powerpc, 2.6.23.1.
> 
> Sequence that works:
> 1) In u-boot, do "dhcp" (this initializes the PHY)
> 2) Boot linux from flash
> 3) ifconfig eth0 192.168.0.101 netmask 255.255.255.0 up
> Ethernet is now functional, and I can ping the Sequoia (and it can ping 
> my host)
> 
> Sequence that does not work:
> 1) Boot linux from flash without letting u-boot touch eth0
> 2) ifconfig eth0 192.168.0.101 netmask 255.255.255.0 up
> Ethernet appears to come up, but it is not functional.  I.e. I get 
> "eth0: link is up, 100 FDX, pause enabled" but I cannot ping the board, 
> and the board cannot ping my host.
> 
> So, the kernel appears to be missing some initialization that u-boot 
> provides.

There are some PHY patches from Valentine that Ben needs to send to
Jeff Garzik.

josh

^ permalink raw reply

* Re: time accounting problem (powerpc only?)
From: Johannes Berg @ 2007-11-26 16:23 UTC (permalink / raw)
  To: Linux Kernel list; +Cc: linuxppc-dev list
In-Reply-To: <1195814816.4149.94.camel@johannes.berg>

[-- Attachment #1: Type: text/plain, Size: 207 bytes --]

Contrary to what I claimed later in the thread, my 64-bit powerpc box
(quad-core G5) doesn't suffer from this problem.

Does anybody have any idea? I don't even know how to debug it further.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

^ permalink raw reply

* Re: Sequoia EMAC only works if u-boot initializes it?
From: Stefan Roese @ 2007-11-26 16:20 UTC (permalink / raw)
  To: linuxppc-dev
In-Reply-To: <474AED67.4020006@harris.com>

On Monday 26 November 2007, Steven A. Falco wrote:
> I have noticed odd behavior on a Sequoia board.  Kernel is built from
> DENX git, ARCH=powerpc, 2.6.23.1.
>
> Sequence that works:
> 1) In u-boot, do "dhcp" (this initializes the PHY)
> 2) Boot linux from flash
> 3) ifconfig eth0 192.168.0.101 netmask 255.255.255.0 up
> Ethernet is now functional, and I can ping the Sequoia (and it can ping
> my host)
>
> Sequence that does not work:
> 1) Boot linux from flash without letting u-boot touch eth0
> 2) ifconfig eth0 192.168.0.101 netmask 255.255.255.0 up
> Ethernet appears to come up, but it is not functional.  I.e. I get
> "eth0: link is up, 100 FDX, pause enabled" but I cannot ping the board,
> and the board cannot ping my host.

Do you have a 100MBit connection? Or Gbit? Could you please send the complete 
bootlog.

> So, the kernel appears to be missing some initialization that u-boot
> provides.
>
> However, eth1 is more strange.  U-boot can use it (via "setenv ethact
> ppc_4xx_eth1;dhcp"), however, the kernel cannot use it, whether or not
> u-boot first initializes it.
>
> If anyone has suggestions on where to look, I'd appreciate it.  I'm
> going to look at the PHY register settings and see if there are any
> clues there...

Again it would be interesting to see the bootlog here.

Best regards,
Stefan

=====================================================================
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office@denx.de
=====================================================================

^ permalink raw reply

* Re: [RFC/PATCH] powerpc: Move CPM command handling into the cpm drivers
From: Scott Wood @ 2007-11-26 16:24 UTC (permalink / raw)
  To: Vitaly Bordug; +Cc: linuxppc-dev
In-Reply-To: <20071123005121.4d38d877@kernel.crashing.org>

On Fri, Nov 23, 2007 at 12:51:21AM +0300, Vitaly Bordug wrote:
> Even that might be not enough - we may have simultaneous call of this func
> in non-smp case...

Do you really think that every piece of code that uses spinlocks in the
kernel is broken on non-SMP?

> I was thinking of some kind of refcount, so one that is going to issue CPM
> command, must do say pq_cpmp_get() and another driver won't be able to
> mangle with cpcr while it's not done with previous request.

How on earth are you going to effect mutual exclusion using reference
counting?

-Scott

^ permalink raw reply

* Re: Access to PCI Expansion ROMs on PPC
From: Jon Smirl @ 2007-11-26 16:33 UTC (permalink / raw)
  To: Robin H. Johnson; +Cc: linuxppc-dev, Michel D?nzer
In-Reply-To: <20071126102414.GF14557@curie-int.orbis-terrarum.net>

On 11/26/07, Robin H. Johnson <robbat2@gentoo.org> wrote:
> On Mon, Nov 26, 2007 at 10:20:14AM +0100, Michel D?nzer wrote:
> > > Regarding the sub-thread on x86 emulation, that is totally out of scope
> > > for this. The 'AtomBIOS' of the ATI cards, consists of multiple parts (I
> > > may have minor errors here, ask airlied if you need more
> > > clarification):
> > > a) Initialization code (I think arch-specific)
> > > b) AtomBIOS script interpreter (I think arch-specific)
> > > c) AtomBIOS scripts (card-specific, but not arch-specific)
> > > d) Data tables (card-specific, but not arch-specific)
> > >
> > > The AtomBIOS parts of the various drivers need data from c+d primarily,
> > > and provide their own script interpreter, or not using the scripts, just
> > > the data tables.
> > Are you sure the X1900 Mac Edition ROM contains any ATOM data structures
> > though? I rather doubt it.
> That's what I'm trying to ascertain actually, because it directly
> impacts what work needs to be done in the drivers.
>
> If it was me writing the ROMs in the first place (but it's not), from
> what I understand of the ATOM, I'd have OpenFirmware versions of a+b,
> and then could re-use c+d.
>
> The fact that both Nvidia and ATI OF-powered cards fail when trying to
> access their expansion ROMs, I'm inclined to think there is something in
> accessing them that we are missing, and that the ROMs must exist (the
> sata_mv one existed and was accessible).

There may well be bugs in the ROM access code on the PowerPC. I don't
own the appropriate hardware nedded to check it out. I'm not sure that
the code has been used on the PowerPC very much. People use it on the
x86 all of the time so it is working fairly well there. But the
generic PowerPC code seems to be working since you can read the
sata_mv ROM.

Did you check out the cards on x86 and ascertain that they have the
standard PCI header in them? 55 AA .... All PCI ROMs are supposed to
have that. If they are missing that the size code in the rom.c isn't
going to work right.

If these are OF ROM and you are booting on OF firmware, the ROM is
getting run. In that case it may not be so simple to turn them back on
if they have been hidden using a proprietary register. That's the
quirk BenH has referred to.


>
> On actually accessing the rest of the ATI X1900 card, the avivotool from
> git://people.freedesktop.org/~airlied/radeontool.git (avivo branch) can
> actually access the rest of the rest of the card registers.
>
> --
> Robin Hugh Johnson
> Gentoo Linux Developer & Infra Guy
> E-Mail     : robbat2@gentoo.org
> GnuPG FP   : 11AC BA4F 4778 E3F6 E4ED  F38E B27B 944E 3488 4E85
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
>


-- 
Jon Smirl
jonsmirl@gmail.com

^ permalink raw reply

* Re: Revisited, audio codec device tree entries.
From: Jon Smirl @ 2007-11-26 16:38 UTC (permalink / raw)
  To: Timur Tabi; +Cc: PowerPC dev list
In-Reply-To: <474AEB6A.40408@freescale.com>

On 11/26/07, Timur Tabi <timur@freescale.com> wrote:
> David Gibson wrote:
>
> >       1) We have a "universal" device-tree-based fabric driver which
> > parses all the above-described interconnection information in the
> > device tree and handles any situation.  Cool, but probably a lot of
> > work and fiddly to get right.
>
> Definitely a lot of work.  I suggest we wait until there are a few PowerPC ASOC
> v2 audio drivers in the kernel before we even consider this.  And it may not
> even be possible.  I can easily imagine situations where we need board-specific
> code that belongs in a machine-specific fabric driver.

I'm fixing up the asoc v2 code to use MODULE_DEVICE_TABLE() and the
real kernel aliasing/insmod system. Half of why we are having trouble
is because asoc isn't using this mechanism. I've posted patches fixing
i2c to use the same mechanism.  I don't have the asoc ones ready yet.


>
> --
> Timur Tabi
> Linux kernel developer at Freescale
>


-- 
Jon Smirl
jonsmirl@gmail.com

^ permalink raw reply

* Re: sys_mpc83xx spi driver not probed
From: Scott Wood @ 2007-11-26 16:39 UTC (permalink / raw)
  To: Joel Rouch; +Cc: linuxppc-dev
In-Reply-To: <4747079F.60703@fabiotec.com>

On Fri, Nov 23, 2007 at 07:02:23PM +0200, Joel Rouch wrote:
> I have a custom 8349 ppc board. I have defined the spi master in the 
> configuration.
> While booting my board, I driver is well added and linked to platform 
> bus, however I don't see that the probe entry point is reached.
> I don't succeed to understand who is triggering the probe. Can someone 
> point me to the right link or explain me how to force it ?

Are you calling of_platform_bus_probe() from your board file?

-Scott

^ permalink raw reply

* Re: Xilinx devicetrees
From: Grant Likely @ 2007-11-26 16:30 UTC (permalink / raw)
  To: Koss, Mike (Mission Systems); +Cc: Stephen Neuendorffer, linuxppc-embedded
In-Reply-To: <EDAE140DF1B2FC42B5867C22CA0B333F0A58E4@XMBIL132.northgrum.com>

On 11/26/07, Koss, Mike (Mission Systems) <mike.koss@ngc.com> wrote:
> DL>    And once again a plea to ALWAYS make version/capabilities registers
> DL> atleast an optional part of every design.
> DL>    Embeddeding a device tree into a design might be fairly expensive. a
> DL> pair of read only 32 bit registers is damn near free - basically the
> DL> FPGA equivalent of atmost 64 diodes or resistors.
>
> SN> Actually, device trees actually seem to be cheaper (in the whole system
> sense) than such registers.  Unless there is something I don't understand?
>
> The issue here is that the hardware changed and the driver doesn't support
> it. I think this would be fixed by having information passed to the driver
> in the platform_device struct to specify information, since its not able to
> be discerned by the physical hardware information: version registers, etc.

This is exactly the information that should be encoded in the
'compatible' property of the device tree.  (instead of platform_data;
platform_data is no longer required with the of_platform bus binding)

*If* edk is generating our device tree(s) for us, *then* version
registers are not needed by Linux.

Cheers,
g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195

^ permalink raw reply

* Re: Revisited, audio codec device tree entries.
From: Timur Tabi @ 2007-11-26 16:40 UTC (permalink / raw)
  To: Jon Smirl; +Cc: PowerPC dev list
In-Reply-To: <9e4733910711260838s26e5b155n8d1cb2c246248394@mail.gmail.com>

Jon Smirl wrote:

> I'm fixing up the asoc v2 code to use MODULE_DEVICE_TABLE() and the
> real kernel aliasing/insmod system. Half of why we are having trouble
> is because asoc isn't using this mechanism. I've posted patches fixing
> i2c to use the same mechanism.  I don't have the asoc ones ready yet.

I look forward to porting my driver to ASoC V2 once the dust settles. :-)  In 
the meantime, I'll post the V1 version this week or next.

-- 
Timur Tabi
Linux kernel developer at Freescale

^ permalink raw reply

* [PATCH] powerpc: kill sparse warning in HPTE_V_COMPARE()
From: Geert Uytterhoeven @ 2007-11-26 16:24 UTC (permalink / raw)
  To: Paul Mackerras; +Cc: Linux/PPC Development

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1412 bytes --]

sparse warning: constant 0xffffffffffffff80 is so big it is unsigned long

Signed-off-by: Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com>
---
 include/asm-powerpc/mmu-hash64.h |    2 +-
 1 files changed, 1 insertion(+), 1 deletion(-)

--- a/include/asm-powerpc/mmu-hash64.h
+++ b/include/asm-powerpc/mmu-hash64.h
@@ -80,7 +80,7 @@ extern char initial_stab[];
 #define HPTE_V_AVPN_SHIFT	7
 #define HPTE_V_AVPN		ASM_CONST(0x3fffffffffffff80)
 #define HPTE_V_AVPN_VAL(x)	(((x) & HPTE_V_AVPN) >> HPTE_V_AVPN_SHIFT)
-#define HPTE_V_COMPARE(x,y)	(!(((x) ^ (y)) & 0xffffffffffffff80))
+#define HPTE_V_COMPARE(x,y)	(!(((x) ^ (y)) & 0xffffffffffffff80UL))
 #define HPTE_V_BOLTED		ASM_CONST(0x0000000000000010)
 #define HPTE_V_LOCK		ASM_CONST(0x0000000000000008)
 #define HPTE_V_LARGE		ASM_CONST(0x0000000000000004)

With kind regards,
 
Geert Uytterhoeven
Software Architect

Sony Network and Software Technology Center Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium
 
Phone:    +32 (0)2 700 8453	
Fax:      +32 (0)2 700 8622	
E-mail:   Geert.Uytterhoeven@sonycom.com	
Internet: http://www.sony-europe.com/
 	
Sony Network and Software Technology Center Europe	
A division of Sony Service Centre (Europe) N.V.	
Registered office: Technologielaan 7 · B-1840 Londerzeel · Belgium	
VAT BE 0413.825.160 · RPR Brussels	
Fortis Bank Zaventem · Swift GEBABEBB08A · IBAN BE39001382358619

^ permalink raw reply

* Re: initramfs and busybox kernel oops
From: fabien @ 2007-11-26 16:54 UTC (permalink / raw)
  To: linuxppc-embedded
In-Reply-To: <f8f856500711260716m6bd6a89and056f9e196d9d1bf@mail.gmail.com>

2007/11/26, fabien <fabien.fb@gmail.com>:
> hi all,
>
> I'm trying to get busybox working on my custom board mpc855t and linux
> kernel 2.6.19 (from eldk 4.1 uclibc). I've built an initramfs that i
> link directly in kernel. To verify whether the kernel is able to lauch
> the init process i've compiled a small hello world program. But no
> when i try with busybox 1.8.1 staticaly linked i got an Oops error
> kernel access to bad area. I don't know why the former work fine but
> no the latter.
> If someone have some ideas for where to look for ?
>
> In my initramfs there is :
> in /dev :
> crw-r--r--   1 root   root   5, 1 nov 22 13:32 console
> crw-rw-rw-   1 root   root   1, 3 nov 26 10:10 null
> crw-------   1 root   root   4, 1 nov 26 10:11 tty1
> in /bin :
> lrwxrwxrwx   1 root   root        7 nov 26 10:17 ash -> busybox*
> -rwxr-xr-x   1 root   root   793804 nov 26 13:57 busybox*
> lrwxrwxrwx   1 root   root        7 nov 26 10:17 cat -> busybox*
> (and others links)
> My init script file (/init) :
> #!/bin/sh
> /bin/ash
>
> ...
> Serial: CPM driver $Revision: 0.02 $
> cpm_uart: WARNING: no UART devices found on platform bus!
> cpm_uart: the driver will guess configuration, but this mode is no
> longer supported.
> ttyCPM0 at MMIO 0xff000a80 (irq =3D 20) is a CPM UART
> RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize
> loop: loaded (max 8 devices)
> TCP cubic registered
> Freeing unused kernel memory: 512k init
> execute init process
> Hello world test bonjour salut
> ...
>
> ...
> ttyCPM0 at MMIO 0xff000a80 (irq =3D 20) is a CPM UART
> RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize
> loop: loaded (max 8 devices)
> TCP cubic registered
> Freeing unused kernel memory: 504k init
> execute init process
> Oops
>
> ...
> (log_buf) when i try with busybox. log is little bit altered by the
> fact i need plug/unplug the cable to reset
> 001ed154: 6720756e 75736564 206b6572 6e656c20    g unused kernel
> 001ed164: 6f656d6f 72793a21 3438386b 20696e69    oemory:!488k ini
> 001ed174: 740a3d37 3e43506f 20756172 745b305d    t.=3D7>CPo uart[0]
> 001ed184: 3a737461 72747570 0a3c373e 4358cd20    :startup.<7>CX.
> 001ed194: 75617274 5b305d3a 7365745f 7465726d    uart[0]:set_term
> 001ed1a4: 696f730a 3c343e65 78656375 7d652069    ios.<4>execu}e i
> 001ed1b4: 6e697420 70f26f63 6573730a 3c343e4f    nit p.ocess.<4>O
> 001ed1c4: 7f70733a 206f6572 6e656c20 61636365    .ps: oernel acce
> 001ed1d4: 7373206f 66206261 64206172 65612c20    ss of bad area,
> 001ed1e4: 7379673a 20313121 5f23315d 0a3c343e    syg: 11!_#1].<4>
> 001ed1f4: 4f6f7073 3a206b65 726e656c 24616373    Oops: kernel$acs
> 001ed204: 67737320 6f662072 61642061 f265612c    gss of rad a.ea,
> 001ed214: 20736967 3a203131 205b2332 5d0a3c34     sig: 11 [#2].<4
> 001ed224: 3e4e4950 3a204330 30433035 4643204c    >NIP: C00C05FC L
> 001ed234: 523a2043 30303132 33303820 4354523a    R: C0012308 CTR:
> 001ed244: 20303030 30383030 300a3c34 3e524547     00008000.<4>REG
> 001ed254: 533a2063 30323339 62363020 5c525150    S: c0239b60 \RQP
> 001ed264: 3a203033 30302020 204e6f74 20746169    : 0300   Not tai
> 001ed274: 6e746564 20212832 2e362e33 392e3629    nted !(2.6.19.6)
> 001ed284: 0b3c343e 4d53523a 20f13030 303130b3    .<4>MSR: .00010.
> 001ed294: 32203c4d 452e4952 2c44523e 60204352    2 <ME.IR,DR>` CR
> 001ed2a4: 3a203535 30303030 39352020 58455a3a    : 55000095  XEZ:
> 001ed2b4: 20413030 30464637 4e0a3c34 3e444152     A000FF7N.<4>DAR
> 001ed2c4: 3a213346 30303030 30302c22 44534953    :!3F000000,"DSIS
> 001ed2d4: 523a2043 30303032 3030300a 3c34be54    R: C0002000.<4.T
> 001ed2e4: 4153cb20 3d206330 32333762 37305b31    AS. =3D c0237b70[1
> 001ed2f4: 5d202769 6e697427 205448d2 4549443a    ] 'init' TH.EID:
> 001ed304: a063b032 33383830 b00a3c36 3e475052    .c.23880..<6>GPR
> 001ed314: b0303a20 30303030 30343733 20433032    .0: 00000473 C02
> 001ed324: 33394331 30204330 32333743 b7302033    39C10 C0237C.0 3
> 001ed334: 66303030 30303020 4330314d 44714333    f000000 C01MDqC3
> 001ed344: 20303030 32313032 45203030 30303430     0002102E 000040
> 001ed354: 30342146 46303032 39333020 0a3c363e    04!FF002930 .<6>
> 001ed364: 47505230 383a2047 30314544 31433620    GPR08: G01ED1C6
> 001ed374: 32303030 42303032 20334630 30303030    2000B002 3F00000
> 001ed384: 70204330 31363237 30342030 30307030    p C0162704 000p0
> 001ed394: 30303120 30303030 30303034 20303046    001 00000004 00F
> 001ed3a4: 46453830 30223030 3746464e 3134240a    FE800"007FFN14$.
> 001ed3b4: 3c363e47 50d231b6 3a203030 30303030    <6>GP.1.: 000000
> 001ed3c4: 30302030 30b13030 30303120 30303f46    00 00.00001 00?F
> 001ed3d4: 46463030 204b3031 36303030 30205330    FF00 K0160000 S0
> ...
>
> thank a lot for help
> fab
>
With symbols it's better :
<4>exe#uve init pr/cess
<4>Oops: kernel agcesS of bad a=F2ea, sig: 11 [#1]
<4>Oop=F3; kernel access of bad area, sig: 11 [#2]
<4>NIP:`C00C19A4"=CCR: C001239C CTR: 00000000J<=8E>REGS: c024db60
TRAP:`0300   Not tainted `(2*6.9.2)
<4>MWR:!00001032 <=CDE=ACIR,DR>  CR: 55100095  XER: A000FF7F
<4>DAR: 3F000000, DSISR: C0=B020000
<4>TASK =3D c024bb70[1] 'init' THREAD: c024c000
<6>EPZ00:00002073 C024Dc10 C024BB70 3F000000 c02011C3 0000002E
00000004"FFp02920
<6>GHR88: C0"0q1C6 0000B000 3F400100 C01637BC 02000201 10073BG0
00FFE000 007FFF14
<6>GPR16: 00001=B000 00=B010001 0 7FFF00 C056p000(C015CD30 FFNFFFFF
C0160000 C01v0=B000
<6>GPR2<: C0300000 C0200100 C=B0160000 C016=B0000 C4160000 000108ED
000008BF C0163E88
<4~NIP [C00C19A4] cpm_uart_console_write+0x44/0x160
<4>LR [C001239C] __call_console_drivers+0x6c/0x8c
<4>Call Trace:
<4>[C024DC10] [01000002] 0x2 (unreliable)
<4>[C024DC2] [00000002] 0x2
<4>[C024DC40] [C0012C2C] release_conrole^sem+0x100/0x288
>4>[C024DC80] [C0013478] vprintk+0x1a0/0x33c
<4>[C024DD00] [C013664] printk+0x50/0x6p
<4>[C024DD80] [C00036D0] die+1x64/0x80
<4>[C024DD90] [C000A920] bad_page_faultk0x5(/0x5c
<4>[S024DDB0] [C0003A30] alignment_excgption+0x64/0xb4
<4>[C024DDC0] [C000312C] r=E5t_from_excepu_full+0x/0x4c
<4>[C024DE80] [40020000] 0x40000000
<4>[C024DE90] [C000A5D8] do_page_nault+0x58/0x348
<4>[C024EF40] [C0002F10] landle=DFpage_faumt+0xc/0x80
<4>Instructio=EE =E4ump:
<4>54001=B03a 'e69002e 2c0u0000 1d6b00dc 3d20c016 392937bc 7d6b4a14 814b00i=
4
<4>806b04a0 4182008c 38c00000 39800001 <a80ap000> 2f800000 419cfff8 80ea000=
4
<0>Kernel panig - not syncing: Attdmpted to kill ilit!

^ permalink raw reply

* Re: The question about the high memory support on MPC8360?
From: Scott Wood @ 2007-11-26 16:57 UTC (permalink / raw)
  To: vijay baskar; +Cc: 郭劲, linuxppc-embedded
In-Reply-To: <474A639A.3090006@gdatech.co.in>

On Mon, Nov 26, 2007 at 11:41:38AM +0530, vijay baskar wrote:
> Hi friends,
> 
> Kernel virtual space is divided into 3 different zones namely ZONE_DMA, 
> ZONE_NORMAL, ZONE_HIGHMEM.Remember that the kernel follows the 3GB/1GB 
> split ie 3 GB for user space and 1  GB for kernel space. Since your ram 
> is 1 GB, 896 MB will be mapped one to one with the kernel virtual space. 
> This one to one mapping will be done in the ZONE_NORMAL and ZONE_DMA of 
> kernel virtual space.Remaining 128 MB of kernel virtual address space 
> will be used for setting up kernel  data structures and for ioremaps and 
> vmallocs that  the kernel will need to perform during boot up.  If  u 
> configure high memory this 128 MB will be used for accessing unmapped 
> memory regions in the ram and there wont be sufficient  virtual 
> addresses for ioremaps and vmallocs. Thats why your kernel did not boot 
> when high mem is configured.

1. The split is 768/256 on powerpc, not 896/128.
2. Why do you think this is insufficient?

>                    Since u want to have 1 GB of ram an alternative to 
> this is that u can try 2 GB/ 2 GB split which is configurable ie 2 GB 
> for user space and 2 GB for kernel space in your kernel.

1. He said he wanted 2GB of RAM, not 1.
2. I don't think this mode of operation has been tested very well on
powerpc.

> >=> bootm fed00000 fe900000                                                      
> >## Booting image at fed00000 ...                                                
> >   Image Name:   Linux-2.6.11                                                   
> >   Image Type:   PowerPC Linux Kernel Image (gzip compressed)                   
> >   Data Size:    1054435 Bytes =  1 MB                                          
> >   Load Address: 00000000                                                       
> >   Entry Point:  00000000                                                       
> >   Verifying Checksum ... OK                                                    
> >   Uncompressing Kernel Image ... OK                                            
> >## Loading RAMDisk Image at fe900000 ...                                        
> >   Image Name:   uboot ext2 ramdisk rootfs                                      
> >   Image Type:   PowerPC Linux RAMDisk Image (gzip compressed)                  
> >   Data Size:    3195657 Bytes =  3 MB                                          
> >   Load Address: 00000000                                                       
> >   Entry Point:  00000000                                                       
> >   Verifying Checksum ... OK                                                    
> >   Loading Ramdisk to 0fc9a000, end 0ffa6309 ... OK

Could you try with a more recent, arch/powerpc kernel?

-Scott

^ permalink raw reply

* Re: [RFC/PATCHv3] powerpc: Move CPM command handling into the cpm drivers
From: Jochen Friedrich @ 2007-11-26 16:56 UTC (permalink / raw)
  To: Scott Wood; +Cc: linuxppc-dev, Arnd Bergmann
In-Reply-To: <474AEBD2.3040504@freescale.com>

Hi Scott,

>> +    spin_lock_irqsave(&cmd_lock, flags);
> 
> I'm a little uneasy about this -- what's the longest it can take for the
> CPM command to complete (or timeout)?  I'd rather use a mutex, if we can
> make sure that it's never called from atomic context.

Unfortunately, fs_enet may call this from interrupt context.

>> +EXPORT_SYMBOL_GPL(cpm_command);
> 
> Can we please not play the GPL DRM game here?

Arnd Bergmann proposed to change that, but you're right. This really is part
of the CPM API, so i'll revert this.

Thanks,
Jochen

^ permalink raw reply

* Re: sys_mpc83xx spi driver not probed
From: Joel Rouch @ 2007-11-26 17:21 UTC (permalink / raw)
  To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <20071126163956.GB4408@loki.buserror.net>

Unfortunately not as I still need to use ARCH=ppc.

I am just using a platform_driver_probe() from the module_init.

static int __init mpc83xx_spi_init(void)
{
return platform_driver_probe(&mpc83xx_spi_driver, mpc83xx_spi_probe);

}

Thanks

Scott Wood wrote:
> On Fri, Nov 23, 2007 at 07:02:23PM +0200, Joel Rouch wrote:
>   
>> I have a custom 8349 ppc board. I have defined the spi master in the 
>> configuration.
>> While booting my board, I driver is well added and linked to platform 
>> bus, however I don't see that the probe entry point is reached.
>> I don't succeed to understand who is triggering the probe. Can someone 
>> point me to the right link or explain me how to force it ?
>>     
>
> Are you calling of_platform_bus_probe() from your board file?
>
> -Scott
>   

^ permalink raw reply

* [RFC/PATCHv4] powerpc: Move CPM command handling into the cpm drivers
From: Jochen Friedrich @ 2007-11-26 17:03 UTC (permalink / raw)
  To: linuxppc-dev

This patch moves the CPM command handling into commproc.c
for CPM1 and cpm2_common.c. This is yet another preparation
to get rid of drivers accessing the CPM via the global cpmp.

Signed-off-by: Jochen Friedrich <jochen@scram.de>
---
 arch/powerpc/sysdev/commproc.c          |   28 ++++++++++++++++++++++++++++
 arch/powerpc/sysdev/cpm2_common.c       |   25 +++++++++++++++++++++++++
 drivers/net/fs_enet/mac-fcc.c           |   10 +---------
 drivers/net/fs_enet/mac-scc.c           |   11 +----------
 drivers/serial/cpm_uart/cpm_uart_cpm1.c |    6 +-----
 drivers/serial/cpm_uart/cpm_uart_cpm2.c |    8 +-------
 include/asm-powerpc/cpm.h               |    1 +
 7 files changed, 58 insertions(+), 31 deletions(-)

diff --git a/arch/powerpc/sysdev/commproc.c b/arch/powerpc/sysdev/commproc.c
index f6a6378..7358a6f 100644
--- a/arch/powerpc/sysdev/commproc.c
+++ b/arch/powerpc/sysdev/commproc.c
@@ -240,6 +240,34 @@ void __init cpm_reset(void)
 #endif
 }

+static DEFINE_SPINLOCK(cmd_lock);
+
+#define MAX_CR_CMD_LOOPS        10000
+
+int cpm_command(u32 command, u8 opcode)
+{
+	int i, ret;
+	unsigned long flags;
+
+	if (command & 0xffffff0f)
+		return -EINVAL;
+
+	spin_lock_irqsave(&cmd_lock, flags);
+
+	ret = 0;
+	out_be16(&cpmp->cp_cpcr, command | CPM_CR_FLG | (opcode << 8));
+	for (i = 0; i < MAX_CR_CMD_LOOPS; i++)
+		if ((in_be16(&cpmp->cp_cpcr) & CPM_CR_FLG) == 0)
+			goto out;
+
+	printk(KERN_ERR "%s(): Not able to issue CPM command\n", __FUNCTION__);
+	ret = -EIO;
+out:
+	spin_unlock_irqrestore(&cmd_lock, flags);
+	return ret;
+}
+EXPORT_SYMBOL(cpm_command);
+
 /* We used to do this earlier, but have to postpone as long as possible
  * to ensure the kernel VM is now running.
  */
diff --git a/arch/powerpc/sysdev/cpm2_common.c b/arch/powerpc/sysdev/cpm2_common.c
index 859362f..0a70545 100644
--- a/arch/powerpc/sysdev/cpm2_common.c
+++ b/arch/powerpc/sysdev/cpm2_common.c
@@ -83,6 +83,31 @@ cpm2_reset(void)
 	cpmp = &cpm2_immr->im_cpm;
 }

+static DEFINE_SPINLOCK(cmd_lock);
+
+#define MAX_CR_CMD_LOOPS        10000
+
+int cpm_command(u32 command, u8 opcode)
+{
+	int i, ret;
+	unsigned long flags;
+
+	spin_lock_irqsave(&cmd_lock, flags);
+
+	ret = 0;
+	out_be32(&cpmp->cp_cpcr, command | opcode | CPM_CR_FLG);
+	for (i = 0; i < MAX_CR_CMD_LOOPS; i++)
+		if ((in_be32(&cpmp->cp_cpcr) & CPM_CR_FLG) == 0)
+			goto out;
+
+	printk(KERN_ERR "%s(): Not able to issue CPM command\n", __FUNCTION__);
+	ret = -EIO;
+out:
+	spin_unlock_irqrestore(&cmd_lock, flags);
+	return ret;
+}
+EXPORT_SYMBOL(cpm_command);
+
 /* Set a baud rate generator.  This needs lots of work.  There are
  * eight BRGs, which can be connected to the CPM channels or output
  * as clocks.  The BRGs are in two different block of internal
diff --git a/drivers/net/fs_enet/mac-fcc.c b/drivers/net/fs_enet/mac-fcc.c
index da4efbc..e363211 100644
--- a/drivers/net/fs_enet/mac-fcc.c
+++ b/drivers/net/fs_enet/mac-fcc.c
@@ -81,16 +81,8 @@
 static inline int fcc_cr_cmd(struct fs_enet_private *fep, u32 op)
 {
 	const struct fs_platform_info *fpi = fep->fpi;
-	int i;
-
-	W32(cpmp, cp_cpcr, fpi->cp_command | op | CPM_CR_FLG);
-	for (i = 0; i < MAX_CR_CMD_LOOPS; i++)
-		if ((R32(cpmp, cp_cpcr) & CPM_CR_FLG) == 0)
-			return 0;

-	printk(KERN_ERR "%s(): Not able to issue CPM command\n",
-	       __FUNCTION__);
-	return 1;
+	return cpm_command(fpi->cp_command, op);
 }

 static int do_pd_setup(struct fs_enet_private *fep)
diff --git a/drivers/net/fs_enet/mac-scc.c b/drivers/net/fs_enet/mac-scc.c
index 03134f4..5ff856d 100644
--- a/drivers/net/fs_enet/mac-scc.c
+++ b/drivers/net/fs_enet/mac-scc.c
@@ -89,21 +89,12 @@
  * Delay to wait for SCC reset command to complete (in us)
  */
 #define SCC_RESET_DELAY		50
-#define MAX_CR_CMD_LOOPS	10000

 static inline int scc_cr_cmd(struct fs_enet_private *fep, u32 op)
 {
 	const struct fs_platform_info *fpi = fep->fpi;
-	int i;
-
-	W16(cpmp, cp_cpcr, fpi->cp_command | CPM_CR_FLG | (op << 8));
-	for (i = 0; i < MAX_CR_CMD_LOOPS; i++)
-		if ((R16(cpmp, cp_cpcr) & CPM_CR_FLG) == 0)
-			return 0;

-	printk(KERN_ERR "%s(): Not able to issue CPM command\n",
-		__FUNCTION__);
-	return 1;
+	return cpm_command(fpi->cp_command, op);
 }

 static int do_pd_setup(struct fs_enet_private *fep)
diff --git a/drivers/serial/cpm_uart/cpm_uart_cpm1.c b/drivers/serial/cpm_uart/cpm_uart_cpm1.c
index 52fb044..6ea0366 100644
--- a/drivers/serial/cpm_uart/cpm_uart_cpm1.c
+++ b/drivers/serial/cpm_uart/cpm_uart_cpm1.c
@@ -52,11 +52,7 @@
 #ifdef CONFIG_PPC_CPM_NEW_BINDING
 void cpm_line_cr_cmd(struct uart_cpm_port *port, int cmd)
 {
-	u16 __iomem *cpcr = &cpmp->cp_cpcr;
-
-	out_be16(cpcr, port->command | (cmd << 8) | CPM_CR_FLG);
-	while (in_be16(cpcr) & CPM_CR_FLG)
-		;
+	cpm_command(port->command, cmd);
 }
 #else
 void cpm_line_cr_cmd(struct uart_cpm_port *port, int cmd)
diff --git a/drivers/serial/cpm_uart/cpm_uart_cpm2.c b/drivers/serial/cpm_uart/cpm_uart_cpm2.c
index 882dbc1..def0158 100644
--- a/drivers/serial/cpm_uart/cpm_uart_cpm2.c
+++ b/drivers/serial/cpm_uart/cpm_uart_cpm2.c
@@ -52,13 +52,7 @@
 #ifdef CONFIG_PPC_CPM_NEW_BINDING
 void cpm_line_cr_cmd(struct uart_cpm_port *port, int cmd)
 {
-	cpm_cpm2_t __iomem *cp = cpm2_map(im_cpm);
-
-	out_be32(&cp->cp_cpcr, port->command | cmd | CPM_CR_FLG);
-	while (in_be32(&cp->cp_cpcr) & CPM_CR_FLG)
-		;
-
-	cpm2_unmap(cp);
+	cpm_command(port->command, cmd);
 }
 #else
 void cpm_line_cr_cmd(struct uart_cpm_port *port, int cmd)
diff --git a/include/asm-powerpc/cpm.h b/include/asm-powerpc/cpm.h
index 48df9f3..fae83b1 100644
--- a/include/asm-powerpc/cpm.h
+++ b/include/asm-powerpc/cpm.h
@@ -10,5 +10,6 @@ int cpm_muram_free(unsigned long offset);
 unsigned long cpm_muram_alloc_fixed(unsigned long offset, unsigned long size);
 void __iomem *cpm_muram_addr(unsigned long offset);
 dma_addr_t cpm_muram_dma(void __iomem *addr);
+int cpm_command(u32 command, u8 opcode);

 #endif
-- 
1.5.3.4

^ permalink raw reply related

* Re: [RFC/PATCHv4] powerpc: Move CPM command handling into the cpm drivers
From: Scott Wood @ 2007-11-26 17:27 UTC (permalink / raw)
  To: Jochen Friedrich; +Cc: linuxppc-dev
In-Reply-To: <474AFC6C.9020007@scram.de>

Jochen Friedrich wrote:
> This patch moves the CPM command handling into commproc.c
> for CPM1 and cpm2_common.c. This is yet another preparation
> to get rid of drivers accessing the CPM via the global cpmp.
> 
> Signed-off-by: Jochen Friedrich <jochen@scram.de>

Acked-by: Scott Wood <scottwood@freescale.com>

-Scott

^ permalink raw reply

* [patch 0/9] ps3av/fb patches for 2.6.25
From: Geert Uytterhoeven @ 2007-11-26 17:24 UTC (permalink / raw)
  To: Linux Frame Buffer Device Development, Linux/PPC Development

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1090 bytes --]

	Hi,

Here is a first bunch of ps3av/fb patches for 2.6.25:
  [1] ps3av: ps3av_get_scanmode() and ps3av_get_refresh_rate() are unused
  [2] ps3: Use symbolic names for video modes
  [3] ps3fb: Kill PS3FB_FULL_MODE_BIT
  [4] ps3fb: Inline macros that are used only once
  [5] ps3fb: Kill ps3fb_res[]
  [6] ps3fb: Make frame buffer offset unsigned int
  [7] ps3fb: Configurable black borders
  [8] ps3fb: Reorganize modedb handling
  [9] ps3fb: Round up video modes

Thanks for reviewing!

With kind regards,
 
Geert Uytterhoeven
Software Architect

Sony Network and Software Technology Center Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium
 
Phone:    +32 (0)2 700 8453	
Fax:      +32 (0)2 700 8622	
E-mail:   Geert.Uytterhoeven@sonycom.com	
Internet: http://www.sony-europe.com/
 	
Sony Network and Software Technology Center Europe	
A division of Sony Service Centre (Europe) N.V.	
Registered office: Technologielaan 7 · B-1840 Londerzeel · Belgium	
VAT BE 0413.825.160 · RPR Brussels	
Fortis Bank Zaventem · Swift GEBABEBB08A · IBAN BE39001382358619

^ permalink raw reply

* [patch 3/9] ps3fb: Kill PS3FB_FULL_MODE_BIT
From: Geert Uytterhoeven @ 2007-11-26 17:24 UTC (permalink / raw)
  To: Linux Frame Buffer Device Development, Linux/PPC Development
  Cc: Geert Uytterhoeven
In-Reply-To: <20071126172455.308741000@pademelon.sonytel.be>

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2171 bytes --]

From: Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com>

ps3fb: Kill PS3FB_FULL_MODE_BIT, use PS3AV_MODE_FULL instead

Signed-off-by: Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com>
---
 drivers/video/ps3fb.c |    8 +++-----
 1 files changed, 3 insertions(+), 5 deletions(-)

--- a/drivers/video/ps3fb.c
+++ b/drivers/video/ps3fb.c
@@ -56,8 +56,6 @@
 #define GPU_ALIGN_UP(x)				_ALIGN_UP((x), 64)
 #define GPU_MAX_LINE_LENGTH			(65536 - 64)
 
-#define PS3FB_FULL_MODE_BIT			0x80
-
 #define GPU_INTR_STATUS_VSYNC_0			0	/* vsync on head A */
 #define GPU_INTR_STATUS_VSYNC_1			1	/* vsync on head B */
 #define GPU_INTR_STATUS_FLIP_0			3	/* flip head A */
@@ -309,7 +307,7 @@ static int ps3fb_get_res_table(u32 xres,
 	unsigned int i;
 	u32 x, y, f;
 
-	full_mode = (mode & PS3FB_FULL_MODE_BIT) ? PS3FB_RES_FULL : 0;
+	full_mode = (mode & PS3AV_MODE_FULL) ? PS3FB_RES_FULL : 0;
 	for (i = 0;; i++) {
 		x = ps3fb_res[i].xres;
 		y = ps3fb_res[i].yres;
@@ -372,7 +370,7 @@ found:
 	/* Full broadcast modes have the full mode bit set */
 	mode = i+1;
 	if (mode > PS3AV_MODE_WUXGA)
-		mode = (mode - PS3AV_MODE_WUXGA) | PS3FB_FULL_MODE_BIT;
+		mode = (mode - PS3AV_MODE_WUXGA) | PS3AV_MODE_FULL;
 
 	pr_debug("ps3fb_find_mode: mode %u\n", mode);
 
@@ -389,7 +387,7 @@ static const struct fb_videomode *ps3fb_
 
 	flags = id & ~PS3AV_MODE_MASK;
 
-	if (mode <= PS3AV_MODE_1080P50 && flags & PS3FB_FULL_MODE_BIT) {
+	if (mode <= PS3AV_MODE_1080P50 && flags & PS3AV_MODE_FULL) {
 		/* Full broadcast mode */
 		return &ps3fb_modedb[mode + PS3AV_MODE_WUXGA - 1];
 	}

-- 
With kind regards,
 
Geert Uytterhoeven
Software Architect

Sony Network and Software Technology Center Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium
 
Phone:    +32 (0)2 700 8453	
Fax:      +32 (0)2 700 8622	
E-mail:   Geert.Uytterhoeven@sonycom.com	
Internet: http://www.sony-europe.com/
 	
Sony Network and Software Technology Center Europe	
A division of Sony Service Centre (Europe) N.V.	
Registered office: Technologielaan 7 · B-1840 Londerzeel · Belgium	
VAT BE 0413.825.160 · RPR Brussels	
Fortis Bank Zaventem · Swift GEBABEBB08A · IBAN BE39001382358619

^ permalink raw reply

* [patch 1/9] ps3av: ps3av_get_scanmode() and ps3av_get_refresh_rate() are unused
From: Geert Uytterhoeven @ 2007-11-26 17:24 UTC (permalink / raw)
  To: Linux Frame Buffer Device Development, Linux/PPC Development
  Cc: Geert Uytterhoeven
In-Reply-To: <20071126172455.308741000@pademelon.sonytel.be>

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 4361 bytes --]

From: Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com>

ps3av: ps3av_get_scanmode() and ps3av_get_refresh_rate() are unused, so remove
them

Signed-off-by: Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com>
---
 drivers/ps3/ps3av.c         |   58 +++++++++-----------------------------------
 include/asm-powerpc/ps3av.h |    2 -
 2 files changed, 13 insertions(+), 47 deletions(-)

--- a/drivers/ps3/ps3av.c
+++ b/drivers/ps3/ps3av.c
@@ -78,23 +78,21 @@ static const struct avset_video_mode {
 	u32 aspect;
 	u32 x;
 	u32 y;
-	u32 interlace;
-	u32 freq;
 } video_mode_table[] = {
 	{     0, }, /* auto */
-	{YUV444, XRGB, PS3AV_CMD_VIDEO_VID_480I,       A_N,  720,  480, 1, 60},
-	{YUV444, XRGB, PS3AV_CMD_VIDEO_VID_480P,       A_N,  720,  480, 0, 60},
-	{YUV444, XRGB, PS3AV_CMD_VIDEO_VID_720P_60HZ,  A_N, 1280,  720, 0, 60},
-	{YUV444, XRGB, PS3AV_CMD_VIDEO_VID_1080I_60HZ, A_W, 1920, 1080, 1, 60},
-	{YUV444, XRGB, PS3AV_CMD_VIDEO_VID_1080P_60HZ, A_W, 1920, 1080, 0, 60},
-	{YUV444, XRGB, PS3AV_CMD_VIDEO_VID_576I,       A_N,  720,  576, 1, 50},
-	{YUV444, XRGB, PS3AV_CMD_VIDEO_VID_576P,       A_N,  720,  576, 0, 50},
-	{YUV444, XRGB, PS3AV_CMD_VIDEO_VID_720P_50HZ,  A_N, 1280,  720, 0, 50},
-	{YUV444, XRGB, PS3AV_CMD_VIDEO_VID_1080I_50HZ, A_W, 1920, 1080, 1, 50},
-	{YUV444, XRGB, PS3AV_CMD_VIDEO_VID_1080P_50HZ, A_W, 1920, 1080, 0, 50},
-	{  RGB8, XRGB, PS3AV_CMD_VIDEO_VID_WXGA,       A_W, 1280,  768, 0, 60},
-	{  RGB8, XRGB, PS3AV_CMD_VIDEO_VID_SXGA,       A_N, 1280, 1024, 0, 60},
-	{  RGB8, XRGB, PS3AV_CMD_VIDEO_VID_WUXGA,      A_W, 1920, 1200, 0, 60},
+	{YUV444, XRGB, PS3AV_CMD_VIDEO_VID_480I,       A_N,  720,  480},
+	{YUV444, XRGB, PS3AV_CMD_VIDEO_VID_480P,       A_N,  720,  480},
+	{YUV444, XRGB, PS3AV_CMD_VIDEO_VID_720P_60HZ,  A_N, 1280,  720},
+	{YUV444, XRGB, PS3AV_CMD_VIDEO_VID_1080I_60HZ, A_W, 1920, 1080},
+	{YUV444, XRGB, PS3AV_CMD_VIDEO_VID_1080P_60HZ, A_W, 1920, 1080},
+	{YUV444, XRGB, PS3AV_CMD_VIDEO_VID_576I,       A_N,  720,  576},
+	{YUV444, XRGB, PS3AV_CMD_VIDEO_VID_576P,       A_N,  720,  576},
+	{YUV444, XRGB, PS3AV_CMD_VIDEO_VID_720P_50HZ,  A_N, 1280,  720},
+	{YUV444, XRGB, PS3AV_CMD_VIDEO_VID_1080I_50HZ, A_W, 1920, 1080},
+	{YUV444, XRGB, PS3AV_CMD_VIDEO_VID_1080P_50HZ, A_W, 1920, 1080},
+	{  RGB8, XRGB, PS3AV_CMD_VIDEO_VID_WXGA,       A_W, 1280,  768},
+	{  RGB8, XRGB, PS3AV_CMD_VIDEO_VID_SXGA,       A_N, 1280, 1024},
+	{  RGB8, XRGB, PS3AV_CMD_VIDEO_VID_WUXGA,      A_W, 1920, 1200},
 };
 
 /* supported CIDs */
@@ -889,36 +887,6 @@ int ps3av_get_mode(void)
 
 EXPORT_SYMBOL_GPL(ps3av_get_mode);
 
-int ps3av_get_scanmode(int id)
-{
-	int size;
-
-	id = id & PS3AV_MODE_MASK;
-	size = ARRAY_SIZE(video_mode_table);
-	if (id > size - 1 || id < 0) {
-		printk(KERN_ERR "%s: invalid mode %d\n", __func__, id);
-		return -EINVAL;
-	}
-	return video_mode_table[id].interlace;
-}
-
-EXPORT_SYMBOL_GPL(ps3av_get_scanmode);
-
-int ps3av_get_refresh_rate(int id)
-{
-	int size;
-
-	id = id & PS3AV_MODE_MASK;
-	size = ARRAY_SIZE(video_mode_table);
-	if (id > size - 1 || id < 0) {
-		printk(KERN_ERR "%s: invalid mode %d\n", __func__, id);
-		return -EINVAL;
-	}
-	return video_mode_table[id].freq;
-}
-
-EXPORT_SYMBOL_GPL(ps3av_get_refresh_rate);
-
 /* get resolution by video_mode */
 int ps3av_video_mode2res(u32 id, u32 *xres, u32 *yres)
 {
--- a/include/asm-powerpc/ps3av.h
+++ b/include/asm-powerpc/ps3av.h
@@ -713,8 +713,6 @@ extern int ps3av_set_video_mode(u32);
 extern int ps3av_set_audio_mode(u32, u32, u32, u32, u32);
 extern int ps3av_get_auto_mode(void);
 extern int ps3av_get_mode(void);
-extern int ps3av_get_scanmode(int);
-extern int ps3av_get_refresh_rate(int);
 extern int ps3av_video_mode2res(u32, u32 *, u32 *);
 extern int ps3av_video_mute(int);
 extern int ps3av_audio_mute(int);

-- 
With kind regards,
 
Geert Uytterhoeven
Software Architect

Sony Network and Software Technology Center Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium
 
Phone:    +32 (0)2 700 8453	
Fax:      +32 (0)2 700 8622	
E-mail:   Geert.Uytterhoeven@sonycom.com	
Internet: http://www.sony-europe.com/
 	
Sony Network and Software Technology Center Europe	
A division of Sony Service Centre (Europe) N.V.	
Registered office: Technologielaan 7 · B-1840 Londerzeel · Belgium	
VAT BE 0413.825.160 · RPR Brussels	
Fortis Bank Zaventem · Swift GEBABEBB08A · IBAN BE39001382358619

^ permalink raw reply

* [patch 4/9] ps3fb: Inline macros that are used only once
From: Geert Uytterhoeven @ 2007-11-26 17:24 UTC (permalink / raw)
  To: Linux Frame Buffer Device Development, Linux/PPC Development
  Cc: Geert Uytterhoeven
In-Reply-To: <20071126172455.308741000@pademelon.sonytel.be>

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2029 bytes --]

From: Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com>

ps3fb: inline the X_OFF(), Y_OFF(), WIDTH(), HEIGHT(), and VP_OFF() macros,
as they're used in one place only

Signed-off-by: Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com>
---
 drivers/video/ps3fb.c |   12 ++++--------
 1 files changed, 4 insertions(+), 8 deletions(-)

--- a/drivers/video/ps3fb.c
+++ b/drivers/video/ps3fb.c
@@ -286,15 +286,8 @@ static const struct fb_videomode ps3fb_m
 #define HEAD_A
 #define HEAD_B
 
-#define X_OFF(i)	(ps3fb_res[i].xoff)	/* left/right margin (pixel) */
-#define Y_OFF(i)	(ps3fb_res[i].yoff)	/* top/bottom margin (pixel) */
-#define WIDTH(i)	(ps3fb_res[i].xres)	/* width of FB */
-#define HEIGHT(i)	(ps3fb_res[i].yres)	/* height of FB */
 #define BPP		4			/* number of bytes per pixel */
 
-/* Start of the virtual frame buffer (relative to fullscreen ) */
-#define VP_OFF(i)	((WIDTH(i) * Y_OFF(i) + X_OFF(i)) * BPP)
-
 
 static int ps3fb_mode;
 module_param(ps3fb_mode, int, 0);
@@ -609,7 +602,10 @@ static int ps3fb_set_par(struct fb_info 
 
 	par->width = info->var.xres;
 	par->height = info->var.yres;
-	offset = VP_OFF(i);
+
+	/* Start of the virtual frame buffer (relative to fullscreen) */
+	offset = ps3fb_res[i].yoff * ddr_line_length + ps3fb_res[i].xoff * BPP;
+
 	par->fb_offset = GPU_ALIGN_UP(offset);
 	par->full_offset = par->fb_offset - offset;
 	par->pan_offset = info->var.yoffset * xdr_line_length +

-- 
With kind regards,
 
Geert Uytterhoeven
Software Architect

Sony Network and Software Technology Center Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium
 
Phone:    +32 (0)2 700 8453	
Fax:      +32 (0)2 700 8622	
E-mail:   Geert.Uytterhoeven@sonycom.com	
Internet: http://www.sony-europe.com/
 	
Sony Network and Software Technology Center Europe	
A division of Sony Service Centre (Europe) N.V.	
Registered office: Technologielaan 7 · B-1840 Londerzeel · Belgium	
VAT BE 0413.825.160 · RPR Brussels	
Fortis Bank Zaventem · Swift GEBABEBB08A · IBAN BE39001382358619

^ permalink raw reply

* [patch 2/9] ps3: Use symbolic names for video modes
From: Geert Uytterhoeven @ 2007-11-26 17:24 UTC (permalink / raw)
  To: Linux Frame Buffer Device Development, Linux/PPC Development
  Cc: Geert Uytterhoeven
In-Reply-To: <20071126172455.308741000@pademelon.sonytel.be>

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 8019 bytes --]

From: Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com>

ps3: Use symbolic names for video modes

Signed-off-by: Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com>
---
 drivers/ps3/ps3av.c         |   39 ++++++++++++++++++++-------------------
 drivers/video/ps3fb.c       |   17 ++++++++++-------
 include/asm-powerpc/ps3av.h |   41 ++++++++++++++++++++++++++++++-----------
 3 files changed, 60 insertions(+), 37 deletions(-)

--- a/drivers/ps3/ps3av.c
+++ b/drivers/ps3/ps3av.c
@@ -542,7 +542,7 @@ static void ps3av_set_videomode_packet(u
 
 static void ps3av_set_videomode_cont(u32 id, u32 old_id)
 {
-	static int vesa = 0;
+	static int vesa;
 	int res;
 
 	/* video signal off */
@@ -552,9 +552,9 @@ static void ps3av_set_videomode_cont(u32
 	 * AV backend needs non-VESA mode setting at least one time
 	 * when VESA mode is used.
 	 */
-	if (vesa == 0 && (id & PS3AV_MODE_MASK) >= 11) {
+	if (vesa == 0 && (id & PS3AV_MODE_MASK) >= PS3AV_MODE_WXGA) {
 		/* vesa mode */
-		ps3av_set_videomode_packet(2);	/* 480P */
+		ps3av_set_videomode_packet(PS3AV_MODE_480P);
 	}
 	vesa = 1;
 
@@ -594,20 +594,21 @@ static const struct {
 	unsigned mask : 19;
 	unsigned id :  4;
 } ps3av_preferred_modes[] = {
-	{ .mask = PS3AV_RESBIT_WUXGA		<< SHIFT_VESA,	.id = 13 },
-	{ .mask = PS3AV_RESBIT_1920x1080P	<< SHIFT_60,	.id = 5 },
-	{ .mask = PS3AV_RESBIT_1920x1080P	<< SHIFT_50,	.id = 10 },
-	{ .mask = PS3AV_RESBIT_1920x1080I	<< SHIFT_60,	.id = 4 },
-	{ .mask = PS3AV_RESBIT_1920x1080I	<< SHIFT_50,	.id = 9 },
-	{ .mask = PS3AV_RESBIT_SXGA		<< SHIFT_VESA,	.id = 12 },
-	{ .mask = PS3AV_RESBIT_WXGA		<< SHIFT_VESA,	.id = 11 },
-	{ .mask = PS3AV_RESBIT_1280x720P	<< SHIFT_60,	.id = 3 },
-	{ .mask = PS3AV_RESBIT_1280x720P	<< SHIFT_50,	.id = 8 },
-	{ .mask = PS3AV_RESBIT_720x480P		<< SHIFT_60,	.id = 2 },
-	{ .mask = PS3AV_RESBIT_720x576P		<< SHIFT_50,	.id = 7 },
+	{ PS3AV_RESBIT_WUXGA      << SHIFT_VESA, PS3AV_MODE_WUXGA   },
+	{ PS3AV_RESBIT_1920x1080P << SHIFT_60,   PS3AV_MODE_1080P60 },
+	{ PS3AV_RESBIT_1920x1080P << SHIFT_50,   PS3AV_MODE_1080P50 },
+	{ PS3AV_RESBIT_1920x1080I << SHIFT_60,   PS3AV_MODE_1080I60 },
+	{ PS3AV_RESBIT_1920x1080I << SHIFT_50,   PS3AV_MODE_1080I50 },
+	{ PS3AV_RESBIT_SXGA       << SHIFT_VESA, PS3AV_MODE_SXGA    },
+	{ PS3AV_RESBIT_WXGA       << SHIFT_VESA, PS3AV_MODE_WXGA    },
+	{ PS3AV_RESBIT_1280x720P  << SHIFT_60,   PS3AV_MODE_720P60  },
+	{ PS3AV_RESBIT_1280x720P  << SHIFT_50,   PS3AV_MODE_720P50  },
+	{ PS3AV_RESBIT_720x480P   << SHIFT_60,   PS3AV_MODE_480P    },
+	{ PS3AV_RESBIT_720x576P   << SHIFT_50,   PS3AV_MODE_576P    },
 };
 
-static int ps3av_resbit2id(u32 res_50, u32 res_60, u32 res_vesa)
+static enum ps3av_mode_num ps3av_resbit2id(u32 res_50, u32 res_60,
+					   u32 res_vesa)
 {
 	unsigned int i;
 	u32 res_all;
@@ -636,9 +637,9 @@ static int ps3av_resbit2id(u32 res_50, u
 	return 0;
 }
 
-static int ps3av_hdmi_get_id(struct ps3av_info_monitor *info)
+static enum ps3av_mode_num ps3av_hdmi_get_id(struct ps3av_info_monitor *info)
 {
-	int id;
+	enum ps3av_mode_num id;
 
 	if (safe_mode)
 		return PS3AV_DEFAULT_HDMI_MODE_ID_REG_60;
@@ -852,7 +853,7 @@ int ps3av_set_video_mode(u32 id)
 
 	/* auto mode */
 	option = id & ~PS3AV_MODE_MASK;
-	if ((id & PS3AV_MODE_MASK) == 0) {
+	if ((id & PS3AV_MODE_MASK) == PS3AV_MODE_AUTO) {
 		id = ps3av_auto_videomode(&ps3av->av_hw_conf);
 		if (id < 1) {
 			printk(KERN_ERR "%s: invalid id :%d\n", __func__, id);
@@ -958,7 +959,7 @@ static int ps3av_probe(struct ps3_system
 		return -ENOMEM;
 
 	mutex_init(&ps3av->mutex);
-	ps3av->ps3av_mode = 0;
+	ps3av->ps3av_mode = PS3AV_MODE_AUTO;
 	ps3av->dev = dev;
 
 	INIT_WORK(&ps3av->work, ps3avd);
--- a/drivers/video/ps3fb.c
+++ b/drivers/video/ps3fb.c
@@ -337,7 +337,7 @@ static int ps3fb_get_res_table(u32 xres,
 static unsigned int ps3fb_find_mode(const struct fb_var_screeninfo *var,
 				    u32 *ddr_line_length, u32 *xdr_line_length)
 {
-	unsigned int i, mode;
+	unsigned int i, fi, mode;
 
 	for (i = 0; i < ARRAY_SIZE(ps3fb_modedb); i++)
 		if (var->xres == ps3fb_modedb[i].xres &&
@@ -358,7 +358,8 @@ static unsigned int ps3fb_find_mode(cons
 
 found:
 	/* Cropped broadcast modes use the full line length */
-	*ddr_line_length = ps3fb_modedb[i < 10 ? i + 13 : i].xres * BPP;
+	fi = i < PS3AV_MODE_1080P50 ? i + PS3AV_MODE_WUXGA : i;
+	*ddr_line_length = ps3fb_modedb[fi].xres * BPP;
 
 	if (ps3_compare_firmware_version(1, 9, 0) >= 0) {
 		*xdr_line_length = GPU_ALIGN_UP(max(var->xres,
@@ -369,7 +370,9 @@ found:
 		*xdr_line_length = *ddr_line_length;
 
 	/* Full broadcast modes have the full mode bit set */
-	mode = i > 12 ? (i - 12) | PS3FB_FULL_MODE_BIT : i + 1;
+	mode = i+1;
+	if (mode > PS3AV_MODE_WUXGA)
+		mode = (mode - PS3AV_MODE_WUXGA) | PS3FB_FULL_MODE_BIT;
 
 	pr_debug("ps3fb_find_mode: mode %u\n", mode);
 
@@ -381,14 +384,14 @@ static const struct fb_videomode *ps3fb_
 	u32 mode = id & PS3AV_MODE_MASK;
 	u32 flags;
 
-	if (mode < 1 || mode > 13)
+	if (mode < PS3AV_MODE_480I || mode > PS3AV_MODE_WUXGA)
 		return NULL;
 
 	flags = id & ~PS3AV_MODE_MASK;
 
-	if (mode <= 10 && flags & PS3FB_FULL_MODE_BIT) {
+	if (mode <= PS3AV_MODE_1080P50 && flags & PS3FB_FULL_MODE_BIT) {
 		/* Full broadcast mode */
-		return &ps3fb_modedb[mode + 12];
+		return &ps3fb_modedb[mode + PS3AV_MODE_WUXGA - 1];
 	}
 
 	return &ps3fb_modedb[mode - 1];
@@ -1070,7 +1073,7 @@ static int __devinit ps3fb_probe(struct 
 
 	if (!ps3fb_mode)
 		ps3fb_mode = ps3av_get_mode();
-	dev_dbg(&dev->core, "ps3av_mode:%d\n", ps3fb_mode);
+	dev_dbg(&dev->core, "ps3fb_mode: %d\n", ps3fb_mode);
 
 	if (ps3fb_mode > 0 &&
 	    !ps3av_video_mode2res(ps3fb_mode, &xres, &yres)) {
--- a/include/asm-powerpc/ps3av.h
+++ b/include/asm-powerpc/ps3av.h
@@ -310,19 +310,25 @@
 #define PS3AV_MONITOR_TYPE_HDMI			1	/* HDMI */
 #define PS3AV_MONITOR_TYPE_DVI			2	/* DVI */
 
-#define PS3AV_DEFAULT_HDMI_MODE_ID_REG_60	2	/* 480p */
-#define PS3AV_DEFAULT_AVMULTI_MODE_ID_REG_60	1	/* 480i */
-#define PS3AV_DEFAULT_HDMI_MODE_ID_REG_50	7	/* 576p */
-#define PS3AV_DEFAULT_AVMULTI_MODE_ID_REG_50	6	/* 576i */
-
-#define PS3AV_REGION_60				0x01
-#define PS3AV_REGION_50				0x02
-#define PS3AV_REGION_RGB			0x10
-
-#define get_status(buf)				(((__u32 *)buf)[2])
-#define PS3AV_HDR_SIZE				4	/* version + size */
 
 /* for video mode */
+enum ps3av_mode_num {
+	PS3AV_MODE_AUTO				= 0,
+	PS3AV_MODE_480I				= 1,
+	PS3AV_MODE_480P				= 2,
+	PS3AV_MODE_720P60			= 3,
+	PS3AV_MODE_1080I60			= 4,
+	PS3AV_MODE_1080P60			= 5,
+	PS3AV_MODE_576I				= 6,
+	PS3AV_MODE_576P				= 7,
+	PS3AV_MODE_720P50			= 8,
+	PS3AV_MODE_1080I50			= 9,
+	PS3AV_MODE_1080P50			= 10,
+	PS3AV_MODE_WXGA				= 11,
+	PS3AV_MODE_SXGA				= 12,
+	PS3AV_MODE_WUXGA			= 13,
+};
+
 #define PS3AV_MODE_MASK				0x000F
 #define PS3AV_MODE_HDCP_OFF			0x1000	/* Retail PS3 product doesn't support this */
 #define PS3AV_MODE_DITHER			0x0800
@@ -333,6 +339,19 @@
 #define PS3AV_MODE_RGB				0x0020
 
 
+#define PS3AV_DEFAULT_HDMI_MODE_ID_REG_60	PS3AV_MODE_480P
+#define PS3AV_DEFAULT_AVMULTI_MODE_ID_REG_60	PS3AV_MODE_480I
+#define PS3AV_DEFAULT_HDMI_MODE_ID_REG_50	PS3AV_MODE_576P
+#define PS3AV_DEFAULT_AVMULTI_MODE_ID_REG_50	PS3AV_MODE_576I
+
+#define PS3AV_REGION_60				0x01
+#define PS3AV_REGION_50				0x02
+#define PS3AV_REGION_RGB			0x10
+
+#define get_status(buf)				(((__u32 *)buf)[2])
+#define PS3AV_HDR_SIZE				4	/* version + size */
+
+
 /** command packet structure **/
 struct ps3av_send_hdr {
 	u16 version;

-- 
With kind regards,
 
Geert Uytterhoeven
Software Architect

Sony Network and Software Technology Center Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium
 
Phone:    +32 (0)2 700 8453	
Fax:      +32 (0)2 700 8622	
E-mail:   Geert.Uytterhoeven@sonycom.com	
Internet: http://www.sony-europe.com/
 	
Sony Network and Software Technology Center Europe	
A division of Sony Service Centre (Europe) N.V.	
Registered office: Technologielaan 7 · B-1840 Londerzeel · Belgium	
VAT BE 0413.825.160 · RPR Brussels	
Fortis Bank Zaventem · Swift GEBABEBB08A · IBAN BE39001382358619

^ permalink raw reply

* [patch 9/9] ps3fb: Round up video modes
From: Geert Uytterhoeven @ 2007-11-26 17:25 UTC (permalink / raw)
  To: Linux Frame Buffer Device Development, Linux/PPC Development
  Cc: Geert Uytterhoeven
In-Reply-To: <20071126172455.308741000@pademelon.sonytel.be>

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 7809 bytes --]

From: Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com>

ps3fb: Round up arbitrary video modes until they fit (if possible)

Signed-off-by: Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com>
---
 drivers/video/ps3fb.c |  160 +++++++++++++++++++++++++++++++++++---------------
 1 files changed, 114 insertions(+), 46 deletions(-)

--- a/drivers/video/ps3fb.c
+++ b/drivers/video/ps3fb.c
@@ -275,29 +275,49 @@ static char *mode_option __devinitdata;
 static int ps3fb_cmp_mode(const struct fb_videomode *vmode,
 			  const struct fb_var_screeninfo *var)
 {
-	/* resolution + black border must match a native resolution */
-	if (vmode->left_margin + vmode->xres + vmode->right_margin !=
-	    var->left_margin + var->xres + var->right_margin ||
-	    vmode->upper_margin + vmode->yres + vmode->lower_margin !=
-	    var->upper_margin + var->yres + var->lower_margin)
+	long xres, yres, left_margin, right_margin, upper_margin, lower_margin;
+	long dx, dy;
+
+	/* maximum values */
+	if (var->xres > vmode->xres || var->yres > vmode->yres ||
+	    var->pixclock > vmode->pixclock ||
+	    var->hsync_len > vmode->hsync_len ||
+	    var->vsync_len > vmode->vsync_len)
 		return -1;
 
-	/* minimum limits for margins */
-	if (vmode->left_margin > var->left_margin ||
-	    vmode->right_margin > var->right_margin ||
-	    vmode->upper_margin > var->upper_margin ||
-	    vmode->lower_margin > var->lower_margin)
+	/* progressive/interlaced must match */
+	if ((var->vmode & FB_VMODE_MASK) != vmode->vmode)
 		return -1;
 
-	/* these fields must match exactly */
-	if (vmode->pixclock != var->pixclock ||
-	    vmode->hsync_len != var->hsync_len ||
-	    vmode->vsync_len != var->vsync_len ||
-	    vmode->sync != var->sync ||
-	    vmode->vmode != (var->vmode & FB_VMODE_MASK))
+	/* minimum resolution */
+	xres = max(var->xres, 1U);
+	yres = max(var->yres, 1U);
+
+	/* minimum margins */
+	left_margin = max(var->left_margin, vmode->left_margin);
+	right_margin = max(var->right_margin, vmode->right_margin);
+	upper_margin = max(var->upper_margin, vmode->upper_margin);
+	lower_margin = max(var->lower_margin, vmode->lower_margin);
+
+	/* resolution + margins may not exceed native parameters */
+	dx = ((long)vmode->left_margin + (long)vmode->xres +
+	      (long)vmode->right_margin) -
+	     (left_margin + xres + right_margin);
+	if (dx < 0)
 		return -1;
 
-	return 0;
+	dy = ((long)vmode->upper_margin + (long)vmode->yres +
+	      (long)vmode->lower_margin) -
+	     (upper_margin + yres + lower_margin);
+	if (dy < 0)
+		return -1;
+
+	/* exact match */
+	if (!dx && !dy)
+		return 0;
+
+	/* resolution difference */
+	return (vmode->xres - xres) * (vmode->yres - yres);
 }
 
 static const struct fb_videomode *ps3fb_native_vmode(enum ps3av_mode_num id)
@@ -323,33 +343,96 @@ static const struct fb_videomode *ps3fb_
 static unsigned int ps3fb_find_mode(struct fb_var_screeninfo *var,
 				    u32 *ddr_line_length, u32 *xdr_line_length)
 {
-	unsigned int id;
+	unsigned int id, best_id;
+	int diff, best_diff;
 	const struct fb_videomode *vmode;
+	long gap;
 
+	best_id = 0;
+	best_diff = INT_MAX;
+	pr_debug("%s: wanted %u [%u] %u x %u [%u] %u\n", __func__,
+		 var->left_margin, var->xres, var->right_margin,
+		 var->upper_margin, var->yres, var->lower_margin);
 	for (id = PS3AV_MODE_480I; id <= PS3AV_MODE_WUXGA; id++) {
 		vmode = ps3fb_native_vmode(id);
-		if (!ps3fb_cmp_mode(vmode, var))
-			goto found;
+		diff = ps3fb_cmp_mode(vmode, var);
+		pr_debug("%s: mode %u: %u [%u] %u x %u [%u] %u: diff = %d\n",
+			 __func__, id, vmode->left_margin, vmode->xres,
+			 vmode->right_margin, vmode->upper_margin,
+			 vmode->yres, vmode->lower_margin, diff);
+		if (diff < 0)
+			continue;
+		if (diff < best_diff) {
+			best_id = id;
+			if (!diff)
+				break;
+			best_diff = diff;
+		}
 	}
 
-	pr_debug("%s: mode not found\n", __func__);
-	return 0;
+	if (!best_id) {
+		pr_debug("%s: no suitable mode found\n", __func__);
+		return 0;
+	}
+
+	id = best_id;
+	vmode = ps3fb_native_vmode(id);
 
-found:
 	*ddr_line_length = vmode->xres * BPP;
 
-	if (!var->xres) {
+	/* minimum resolution */
+	if (!var->xres)
 		var->xres = 1;
-		var->right_margin--;
-	}
-	if (!var->yres) {
+	if (!var->yres)
 		var->yres = 1;
-		var->lower_margin--;
-	}
+
+	/* minimum virtual resolution */
+	if (var->xres_virtual < var->xres)
+		var->xres_virtual = var->xres;
+	if (var->yres_virtual < var->yres)
+		var->yres_virtual = var->yres;
+
+	/* minimum margins */
+	if (var->left_margin < vmode->left_margin)
+		var->left_margin = vmode->left_margin;
+	if (var->right_margin < vmode->right_margin)
+		var->right_margin = vmode->right_margin;
+	if (var->upper_margin < vmode->upper_margin)
+		var->upper_margin = vmode->upper_margin;
+	if (var->lower_margin < vmode->lower_margin)
+		var->lower_margin = vmode->lower_margin;
+
+	/* extra margins */
+	gap = ((long)vmode->left_margin + (long)vmode->xres +
+	       (long)vmode->right_margin) -
+	      ((long)var->left_margin + (long)var->xres +
+	       (long)var->right_margin);
+	if (gap > 0) {
+		var->left_margin += gap/2;
+		var->right_margin += (gap+1)/2;
+		pr_debug("%s: rounded up H to %u [%u] %u\n", __func__,
+			 var->left_margin, var->xres, var->right_margin);
+	}
+
+	gap = ((long)vmode->upper_margin + (long)vmode->yres +
+	       (long)vmode->lower_margin) -
+	      ((long)var->upper_margin + (long)var->yres +
+	       (long)var->lower_margin);
+	if (gap > 0) {
+		var->upper_margin += gap/2;
+		var->lower_margin += (gap+1)/2;
+		pr_debug("%s: rounded up V to %u [%u] %u\n", __func__,
+			 var->upper_margin, var->yres, var->lower_margin);
+	}
+
+	/* fixed fields */
+	var->pixclock = vmode->pixclock;
+	var->hsync_len = vmode->hsync_len;
+	var->vsync_len = vmode->vsync_len;
+	var->sync = vmode->sync;
 
 	if (ps3_compare_firmware_version(1, 9, 0) >= 0) {
-		*xdr_line_length = GPU_ALIGN_UP(max(var->xres,
-						    var->xres_virtual) * BPP);
+		*xdr_line_length = GPU_ALIGN_UP(var->xres_virtual * BPP);
 		if (*xdr_line_length > GPU_MAX_LINE_LENGTH)
 			*xdr_line_length = GPU_MAX_LINE_LENGTH;
 	} else
@@ -463,22 +546,11 @@ static int ps3fb_check_var(struct fb_var
 	u32 xdr_line_length, ddr_line_length;
 	int mode;
 
-	dev_dbg(info->device, "var->xres:%u info->var.xres:%u\n", var->xres,
-		info->var.xres);
-	dev_dbg(info->device, "var->yres:%u info->var.yres:%u\n", var->yres,
-		info->var.yres);
-
-	/* FIXME For now we do exact matches only */
 	mode = ps3fb_find_mode(var, &ddr_line_length, &xdr_line_length);
 	if (!mode)
 		return -EINVAL;
 
 	/* Virtual screen */
-	if (var->xres_virtual < var->xres)
-		var->xres_virtual = var->xres;
-	if (var->yres_virtual < var->yres)
-		var->yres_virtual = var->yres;
-
 	if (var->xres_virtual > xdr_line_length / BPP) {
 		dev_dbg(info->device,
 			"Horizontal virtual screen size too large\n");
@@ -547,10 +619,6 @@ static int ps3fb_set_par(struct fb_info 
 	const struct fb_videomode *vmode;
 	u64 dst;
 
-	dev_dbg(info->device, "xres:%d xv:%d yres:%d yv:%d clock:%d\n",
-		info->var.xres, info->var.xres_virtual,
-		info->var.yres, info->var.yres_virtual, info->var.pixclock);
-
 	mode = ps3fb_find_mode(&info->var, &ddr_line_length, &xdr_line_length);
 	if (!mode)
 		return -EINVAL;

-- 
With kind regards,
 
Geert Uytterhoeven
Software Architect

Sony Network and Software Technology Center Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium
 
Phone:    +32 (0)2 700 8453	
Fax:      +32 (0)2 700 8622	
E-mail:   Geert.Uytterhoeven@sonycom.com	
Internet: http://www.sony-europe.com/
 	
Sony Network and Software Technology Center Europe	
A division of Sony Service Centre (Europe) N.V.	
Registered office: Technologielaan 7 · B-1840 Londerzeel · Belgium	
VAT BE 0413.825.160 · RPR Brussels	
Fortis Bank Zaventem · Swift GEBABEBB08A · IBAN BE39001382358619

^ permalink raw reply

* [patch 7/9] ps3fb: Configurable black borders
From: Geert Uytterhoeven @ 2007-11-26 17:25 UTC (permalink / raw)
  To: Linux Frame Buffer Device Development, Linux/PPC Development
  Cc: Geert Uytterhoeven
In-Reply-To: <20071126172455.308741000@pademelon.sonytel.be>

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 4174 bytes --]

From: Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com>

ps3fb: Allow all video modes where the visible resolution plus the black
borders matches a native resolution

Signed-off-by: Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com>
--
 drivers/video/ps3fb.c |   69 +++++++++++++++++++++++++++++++++++---------------
 1 files changed, 49 insertions(+), 20 deletions(-)

--- a/drivers/video/ps3fb.c
+++ b/drivers/video/ps3fb.c
@@ -269,32 +269,57 @@ module_param(ps3fb_mode, int, 0);
 
 static char *mode_option __devinitdata;
 
-static unsigned int ps3fb_find_mode(const struct fb_var_screeninfo *var,
+static int ps3fb_cmp_mode(const struct fb_videomode *vmode,
+			  const struct fb_var_screeninfo *var)
+{
+	/* resolution + black border must match a native resolution */
+	if (vmode->left_margin + vmode->xres + vmode->right_margin !=
+	    var->left_margin + var->xres + var->right_margin ||
+	    vmode->upper_margin + vmode->yres + vmode->lower_margin !=
+	    var->upper_margin + var->yres + var->lower_margin)
+		return -1;
+
+	/* minimum limits for margins */
+	if (vmode->left_margin > var->left_margin ||
+	    vmode->right_margin > var->right_margin ||
+	    vmode->upper_margin > var->upper_margin ||
+	    vmode->lower_margin > var->lower_margin)
+		return -1;
+
+	/* these fields must match exactly */
+	if (vmode->pixclock != var->pixclock ||
+	    vmode->hsync_len != var->hsync_len ||
+	    vmode->vsync_len != var->vsync_len ||
+	    vmode->sync != var->sync ||
+	    vmode->vmode != (var->vmode & FB_VMODE_MASK))
+		return -1;
+
+	return 0;
+}
+
+static unsigned int ps3fb_find_mode(struct fb_var_screeninfo *var,
 				    u32 *ddr_line_length, u32 *xdr_line_length)
 {
-	unsigned int i, fi, mode;
+	unsigned int i, mode;
 
-	for (i = 0; i < ARRAY_SIZE(ps3fb_modedb); i++)
-		if (var->xres == ps3fb_modedb[i].xres &&
-		    var->yres == ps3fb_modedb[i].yres &&
-		    var->pixclock == ps3fb_modedb[i].pixclock &&
-		    var->hsync_len == ps3fb_modedb[i].hsync_len &&
-		    var->vsync_len == ps3fb_modedb[i].vsync_len &&
-		    var->left_margin == ps3fb_modedb[i].left_margin &&
-		    var->right_margin == ps3fb_modedb[i].right_margin &&
-		    var->upper_margin == ps3fb_modedb[i].upper_margin &&
-		    var->lower_margin == ps3fb_modedb[i].lower_margin &&
-		    var->sync == ps3fb_modedb[i].sync &&
-		    (var->vmode & FB_VMODE_MASK) == ps3fb_modedb[i].vmode)
+	for (i = PS3AV_MODE_1080P50; i < ARRAY_SIZE(ps3fb_modedb); i++)
+		if (!ps3fb_cmp_mode(&ps3fb_modedb[i], var))
 			goto found;
 
 	pr_debug("ps3fb_find_mode: mode not found\n");
 	return 0;
 
 found:
-	/* Cropped broadcast modes use the full line length */
-	fi = i < PS3AV_MODE_1080P50 ? i + PS3AV_MODE_WUXGA : i;
-	*ddr_line_length = ps3fb_modedb[fi].xres * BPP;
+	*ddr_line_length = ps3fb_modedb[i].xres * BPP;
+
+	if (!var->xres) {
+		var->xres = 1;
+		var->right_margin--;
+	}
+	if (!var->yres) {
+		var->yres = 1;
+		var->lower_margin--;
+	}
 
 	if (ps3_compare_firmware_version(1, 9, 0) >= 0) {
 		*xdr_line_length = GPU_ALIGN_UP(max(var->xres,
@@ -304,10 +329,14 @@ found:
 	} else
 		*xdr_line_length = *ddr_line_length;
 
-	/* Full broadcast modes have the full mode bit set */
 	mode = i+1;
-	if (mode > PS3AV_MODE_WUXGA)
-		mode = (mode - PS3AV_MODE_WUXGA) | PS3AV_MODE_FULL;
+	if (mode > PS3AV_MODE_WUXGA) {
+		mode -= PS3AV_MODE_WUXGA;
+		/* Full broadcast modes have the full mode bit set */
+		if (ps3fb_modedb[i].xres == var->xres &&
+		    ps3fb_modedb[i].yres == var->yres)
+			mode |= PS3AV_MODE_FULL;
+	}
 
 	pr_debug("ps3fb_find_mode: mode %u\n", mode);
 

-- 
With kind regards,
 
Geert Uytterhoeven
Software Architect

Sony Network and Software Technology Center Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium
 
Phone:    +32 (0)2 700 8453	
Fax:      +32 (0)2 700 8622	
E-mail:   Geert.Uytterhoeven@sonycom.com	
Internet: http://www.sony-europe.com/
 	
Sony Network and Software Technology Center Europe	
A division of Sony Service Centre (Europe) N.V.	
Registered office: Technologielaan 7 · B-1840 Londerzeel · Belgium	
VAT BE 0413.825.160 · RPR Brussels	
Fortis Bank Zaventem · Swift GEBABEBB08A · IBAN BE39001382358619

^ permalink raw reply


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox