* Re: [PATCH 2/2] fsl/embedded6xx: don't cast the result of of_get_property
From: Segher Boessenkool @ 2007-09-26 12:55 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linuxppc-dev, Jeremy Kerr
In-Reply-To: <20070926104419.1b92002e.sfr@canb.auug.org.au>
>> - avr_clock = *(u32*)of_get_property(avr, "clock-frequency", &len);
>> - phys_addr = ((u32*)of_get_property(avr, "reg", &len))[0];
>> + phys_addr = of_get_property(avr, "reg", &len);
>> + avr_clock_prop = of_get_property(avr, "clock-frequency", &len);
>
> If you don't use the value of the len variable, then you can pass NULL
> to
> of_get_property.
OTOH, it is almost always an error to not use the length (missing
error check).
Segher
^ permalink raw reply
* [PATCH 7/7] [POWERPC][SPI] spi_mpc83xx: allow use on any processors with QUICC Engine
From: Anton Vorontsov @ 2007-09-26 13:15 UTC (permalink / raw)
To: Kumar Gala; +Cc: David Brownell, spi-devel-general, linuxppc-dev
In-Reply-To: <7881139C-EEF1-41DC-AB0F-115632E892B8@kernel.crashing.org>
On Tue, Sep 25, 2007 at 11:00:38PM -0500, Kumar Gala wrote:
> I'm still in favor of making it PPC_83xx || QUICC_ENGINE.
Submitting... ;-)
- - - -
From: Anton Vorontsov <avorontsov@ru.mvista.com>
Subject: [POWERPC][SPI] spi_mpc83xx: allow use on any processors with QUICC Engine
Currently, all QE SPI controllers are almost the same comparing to
MPC83xx's, thus let's use that driver for them.
Tested to work on MPC85xx in loopback mode.
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
drivers/spi/Kconfig | 13 +++++++------
1 files changed, 7 insertions(+), 6 deletions(-)
diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
index b915711..a77ede5 100644
--- a/drivers/spi/Kconfig
+++ b/drivers/spi/Kconfig
@@ -124,16 +124,17 @@ config SPI_MPC52xx_PSC
Controller in master SPI mode.
config SPI_MPC83xx
- tristate "Freescale MPC83xx SPI controller"
- depends on SPI_MASTER && PPC_83xx && EXPERIMENTAL
+ tristate "Freescale MPC83xx/QUICC Engine SPI controller"
+ depends on SPI_MASTER && (PPC_83xx || QUICC_ENGINE) && EXPERIMENTAL
select SPI_BITBANG
help
- This enables using the Freescale MPC83xx SPI controller in master
- mode.
+ This enables using the Freescale MPC83xx and QUICC Engine SPI
+ controllers in master mode.
Note, this driver uniquely supports the SPI controller on the MPC83xx
- family of PowerPC processors. The MPC83xx uses a simple set of shift
- registers for data (opposed to the CPM based descriptor model).
+ family of PowerPC processors, plus processors with QUICC Engine
+ technology. This driver uses a simple set of shift registers for data
+ (opposed to the CPM based descriptor model).
config SPI_OMAP_UWIRE
tristate "OMAP1 MicroWire"
--
1.5.0.6
^ permalink raw reply related
* Re: [PATCH] add Altivec/VMX state to coredumps
From: Segher Boessenkool @ 2007-09-26 13:21 UTC (permalink / raw)
To: Matt Sealey; +Cc: linuxppc-dev
In-Reply-To: <46FA3CDD.2070409@genesi-usa.com>
>>> Why not put the PVR in core dumps that'd make it all easier..
>>
>> PVR wouldn't be very useful... What if you have altivec disabled ?
>> Also
>> that would mean your gdb has to know about all new processors...
>
> Is that such a big deal? :D
>
> Hypothetically it would be impossible to determine if you were running
> on a G5 with the FPU and AltiVec turned off or an e500 core with SPE,
> given the data saved.
And that is exactly as should be: a core dump represents the execution
state of a user program, it has nothing to do with the machine it was
generated on; it even is possible to restart a core dump generated on
e.g. an e500 on a 970, as long as it doesn't use facilities (e.g., SPE)
that the latter processor / execution environment doesn't provide.
> Is that a misfeature of GDB that we even have to
> worry about this, or some noble plus point of a unified ISA? You
> decide :)
We don't have to worry about it :-)
Segher
^ permalink raw reply
* Re: [PATCH] add Altivec/VMX state to coredumps
From: Kumar Gala @ 2007-09-26 13:32 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev
In-Reply-To: <997c015e13649d06e246d3d2c1369100@kernel.crashing.org>
On Sep 26, 2007, at 8:21 AM, Segher Boessenkool wrote:
>>>> Why not put the PVR in core dumps that'd make it all easier..
>>>
>>> PVR wouldn't be very useful... What if you have altivec disabled ?
>>> Also
>>> that would mean your gdb has to know about all new processors...
>>
>> Is that such a big deal? :D
>>
>> Hypothetically it would be impossible to determine if you were
>> running
>> on a G5 with the FPU and AltiVec turned off or an e500 core with SPE,
>> given the data saved.
>
> And that is exactly as should be: a core dump represents the execution
> state of a user program, it has nothing to do with the machine it was
> generated on; it even is possible to restart a core dump generated on
> e.g. an e500 on a 970, as long as it doesn't use facilities (e.g.,
> SPE)
> that the latter processor / execution environment doesn't provide.
>
>> Is that a misfeature of GDB that we even have to
>> worry about this, or some noble plus point of a unified ISA? You
>> decide :)
>
> We don't have to worry about it :-)
We should worry about it. If one misinterprets the core file you
will get unexpected behavior. I see no reason not to do this
properly and mark the sections such that its clear if its AltiVec or
SPE state, rather than overloading the x86 XFPU type.
- k
^ permalink raw reply
* Re: [PATCH] add Altivec/VMX state to coredumps
From: Segher Boessenkool @ 2007-09-26 13:38 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <AE678FA4-5ABF-4EAC-B691-CCE5D277955F@kernel.crashing.org>
>>>>> Why not put the PVR in core dumps that'd make it all easier..
>>>>
>>>> PVR wouldn't be very useful... What if you have altivec disabled ?
>>>> Also
>>>> that would mean your gdb has to know about all new processors...
>>>
>>> Is that such a big deal? :D
>>>
>>> Hypothetically it would be impossible to determine if you were
>>> running
>>> on a G5 with the FPU and AltiVec turned off or an e500 core with SPE,
>>> given the data saved.
>>
>> And that is exactly as should be: a core dump represents the execution
>> state of a user program, it has nothing to do with the machine it was
>> generated on; it even is possible to restart a core dump generated on
>> e.g. an e500 on a 970, as long as it doesn't use facilities (e.g.,
>> SPE)
>> that the latter processor / execution environment doesn't provide.
>>
>>> Is that a misfeature of GDB that we even have to
>>> worry about this, or some noble plus point of a unified ISA? You
>>> decide :)
>>
>> We don't have to worry about it :-)
>
> We should worry about it. If one misinterprets the core file you will
> get unexpected behavior.
I read this as "worry about the PVR".
> I see no reason not to do this properly and mark the sections such
> that its clear if its AltiVec or SPE state, rather than overloading
> the x86 XFPU type.
Yes, certainly, I thought we all agreed on that automatically :-)
Segher
^ permalink raw reply
* Re: [PATCH] add Altivec/VMX state to coredumps
From: Matt Sealey @ 2007-09-26 14:00 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev
In-Reply-To: <997c015e13649d06e246d3d2c1369100@kernel.crashing.org>
Segher Boessenkool wrote:
>>>> Why not put the PVR in core dumps that'd make it all easier..
>>>
>>> PVR wouldn't be very useful... What if you have altivec disabled ? Also
>>> that would mean your gdb has to know about all new processors...
>>
>> Is that such a big deal? :D
>>
>> Hypothetically it would be impossible to determine if you were running
>> on a G5 with the FPU and AltiVec turned off or an e500 core with SPE,
>> given the data saved.
>
> And that is exactly as should be: a core dump represents the execution
> state of a user program, it has nothing to do with the machine it was
> generated on; it even is possible to restart a core dump generated on
> e.g. an e500 on a 970, as long as it doesn't use facilities (e.g., SPE)
> that the latter processor / execution environment doesn't provide.
A hypothetical question for you then..
What happens if you get a core dump for a G4 app which dynamically detects
AltiVec presence (from PVR or /proc) then crashes before AltiVec is enabled
in the kernel for that task (i.e. before any vector exception) and you run
it on your G3 and it magically carries on (maybe a race condition or so)
and causes a vector exception later?
Isn't that kind of useless? Wouldn't it?
--
Matt Sealey <matt@genesi-usa.com>
Genesi, Manager, Developer Relations
^ permalink raw reply
* [PATCH] powerpc: fix pci domain detection
From: Arnd Bergmann @ 2007-09-26 14:02 UTC (permalink / raw)
To: linuxppc-dev; +Cc: linux-pci, paulus, linux-kernel
The /proc/bus/pci/* files list PCI domain numbers only for
devices that claim to be on a multi-domain system. The check
for this is broken on powerpc, because the buid value is
truncated to 32 bits.
There is at least one machine (IBM QS21) that only uses
the high-order bits of the buid, so the return value
of pci_proc_domain() ends up being always zero, which
makes /proc/bus/pci useless.
Change the logic to always return '1' for a nonzero
buid value.
Signed-off-by: Arnd Bergmann <arnd.bergmann@de.ibm.com>
diff --git a/arch/powerpc/kernel/pci_64.c b/arch/powerpc/kernel/pci_64.c
index 291ffbc..9f63bdc 100644
--- a/arch/powerpc/kernel/pci_64.c
+++ b/arch/powerpc/kernel/pci_64.c
@@ -588,7 +588,7 @@ int pci_proc_domain(struct pci_bus *bus)
return 0;
else {
struct pci_controller *hose = pci_bus_to_host(bus);
- return hose->buid;
+ return hose->buid != 0;
}
}
^ permalink raw reply related
* changing the EDLK components
From: Murat Artun @ 2007-09-26 14:25 UTC (permalink / raw)
To: linuxppc-embedded
Hello,
In fact I have asked a variant of this question before.
I want to learn the way of building a GNU Automake project and adding
it into ELDK. This could be needed because the current version of an
ELDK component is old to meet the requirements or a library which is
not an ELDK component is to be used in our ppc system.
Section "3.7. Rebuilding ELDK Components" gives details of rebuilding
the components whose source rpms are provided with ELDK.
As I said above I asked a variant of this question to understand how
to build a library in a clean way which is not a part of ELDK.
As now, I need to upgrade an ELDK component. Namely, I need version
0.9.8 of OpenSSL, where latest ELDK release has OpenSSL with version
0.9.7f. I want to learn if it is necessary for me to follow the same
procedure stated in documentation in section "3.7. Rebuilding ELDK
Components". If this is the case, could anyone point me to resources
about how to prepare source rpms from an Automake project to prepare
the source rpm of version 0.9.8 of OpenSSL? Of course building the new
version of the component and placing everything by hand is always a
solution, but I want to understand the clean way of doing this.
Thanks and regards...
--
M u r at A r t u n, MSc.
Design Engineer
"be conservative in what you do, be liberal in what you accept from others"
^ permalink raw reply
* Re: git files from secret lab
From: Grant Likely @ 2007-09-26 15:00 UTC (permalink / raw)
To: Mead, Joseph; +Cc: linuxppc-embedded
In-Reply-To: <D1AFFAE2CC4BD54CA4C1543CFF4A4FCC5972C9@exchangemb3.bnl.gov>
On 9/26/07, Mead, Joseph <mead@bnl.gov> wrote:
> Hi,
>
> I'm trying to download the xilinx patches from Grant's git repository,
> but don't quite understand what I am doing.
>
> I cloned the tree from Linus' tree
>
> git clone
> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
> (this worked fine)
>
> cd linux-2.6
What version of git are you running (git --version). That tree is
using the virtual hosting feature of newer versions of git. You need
to be running at least version 1.5.
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]: PCI Error Recovery: Symbios SCSI First Failure
From: Matthew Wilcox @ 2007-09-26 15:02 UTC (permalink / raw)
To: Linas Vepstas; +Cc: linuxppc-dev, linux-pci, linux-kernel, linux-scsi
In-Reply-To: <20070420204720.GM31947@austin.ibm.com>
On Fri, Apr 20, 2007 at 03:47:20PM -0500, Linas Vepstas wrote:
> Implement the so-called "first failure data capture" (FFDC) for the
> symbios PCI error recovery. After a PCI error event is reported,
> the driver requests that MMIO be enabled. Once enabled, it
> then reads and dumps assorted status registers, and concludes
> by requesting the usual reset sequence.
> + /* Request that MMIO be enabled, so register dump can be taken. */
> + return PCI_ERS_RESULT_CAN_RECOVER;
> +}
I'm a little concerned by the mention of MMIO. It's entirely possible
for the sym2 driver to be using ioports to access the card rather than
MMIO. Is it simply that it can't on the platform you test on?
--
Intel are signing my paycheques ... these opinions are still mine
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours. We can't possibly take such
a retrograde step."
^ permalink raw reply
* git files from secret lab
From: Mead, Joseph @ 2007-09-26 14:53 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <4e5a3720709260725x6d2e9faemc6a6053379610df8@mail.gmail.com>
Hi,=20
I'm trying to download the xilinx patches from Grant's git repository,
but don't quite understand what I am doing.
I cloned the tree from Linus' tree
git clone
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
(this worked fine)
cd linux-2.6
git fetch git://git.secretlab.ca/git/linux-2.6.git virtex-dev:virtex-dev
I get the error message:
Fatal: unexpected EOF
Fetch failure: git://git.secretlab.ca/git/linux-2.6.git
Thanks,
Joe
^ permalink raw reply
* Re: [PATCH 8/15] bootwrapper: convert flatdevtree to version 16
From: Milton Miller @ 2007-09-26 16:19 UTC (permalink / raw)
To: David Gibson; +Cc: ppcdev, Paul Mackerras
In-Reply-To: <20070925034616.GB2525@localhost.localdomain>
On Sep 24, 2007, at 10:46 PM, David Gibson wrote:
> On Mon, Sep 24, 2007 at 01:54:32AM -0500, Milton Miller wrote:
>> On Sep 23, 2007, at 10:36 PM, David Gibson wrote:
>>> On Fri, Sep 21, 2007 at 06:05:06PM -0500, Milton Miller wrote:
> [snip]
>>>> +#define MIN_VERSION 2
>>>> +#define OUT_VERSION 16
>>>
>>> Should output version 17. In any case, don't try to be so general -
>>> just convert v123 (all basically the same) to latest (i.e. v17)
>>> without all the #if nonsense.
>>
>> Outputing v17 instead of 16 requires more words to be added to the
>> header, and the library does fine with v16.
>
> For now. libfdt will want v17. Although it will (eventually) have
> it's own v16->v17 conversion code.
If libfdt gets merged without supporting v16 input, then that will be a
regression. This code isn't pretending to address that. The current
flat tree code works with v16.
>> Actually the v1 trees has
>> some other differences such as initrd addresses were kernel linear not
>> real, cpus were assigned logical numbers ... so while the structure
>> didn't change except for the header field, the contents did.
>
> !? what's your source for this. v2 and v3 were absolutely supposed to
> be backwards compatible with v1 which would not be the case with
> silent semantic changes such as this.
What's your souce for saying the were supposed to be backwards
compatable? That dtc fills out the struct header so?
My source is my involvment when v2 was defined (they were discovered
while writing my device tree generation code):
The actual binary structure is compatable, just not the contents of the
properties nor how any slave cpus wait (for some trees it doesn't
matter).
http://git.kernel.org/?p=linux/kernel/git/horms/kexec-tools-
testing.git;a=blob;f=kexec/arch/ppc64/fs2dt.c;
hb=b84b87747a16f0afbef6f6802bb794a94f4961d9
And some more changes just before that:
http://git.kernel.org/?p=linux/kernel/git/torvalds/old-2.6-bkcvs.git;
a=history;f=arch/ppc64/kernel/prom_init.c;
h=e570799a84cc5328e9f0fd44592cb0b828d8c13a;
hb=4ae24c4e8a8f68950a7774ca1cdfe69bfe4e2ffc
So its mostly when the kernel generated and required v1 trees, it was
ppc64 only and had these other content and handoff semantics. If it
were to get a v1 tree, it only copes for the boot cpu determination
I'm not aware of any code other than the kernel that would actually
generate a v1 tree (other than dtc, which always supporteed v2, and
doesn't care about these differences).
>> Actually,
>> when converting v3 to v16 some of the code issn't needed, the ifs
>> allow
>> the code size to be reduced.
>
> Yes, but it never will be, because the only reason we'd include this
> file is for converting old kexec-tools device trees which are v2 not
> v3.
>
>>>> +#define OUT_COMPAT 16
>>>> +
>>>> +#ifdef NO_CHECK
>>>> +static int check_v123_tree(u32 *start, u32 *limit)
>>>> +{
>>>> + return 0;
>>>> +}
>>>> +#else
>>>> +/**
>>>> + * check_v123_tree - check integrety of a version 1, 2, or 3 tree
>>>> + * @start: the start of the device tree struct
>>>> + * @limit: the end of the region for the struct
>>>> + * structural checks on device_tree
>>>> + */
>>>> +static int check_v123_tree(u32 *start, u32 *limit)
>>>
>>> What is the point of this check? If the device tree is corrupt,
>>> we're
>>> stuffed anyway, so why bother?
>>
>> Hence the ifdef NO_CHECK. When developing, sometimes its nice to
>> know
>> if its your input or your program. These functions are destructive to
>> an improperlly formed tree, and in non-obvious ways. When debugging,
>> it's not hard to hardcode console write or read the printf string
>> buffer with a hardware debugger to see error messages. That said, it
>> could be removed.
>
> Right. Debugging code shouldn't pollute final patches.
There debug code, and validation code. I call this the later. It
validates that the information that should be redundant is in fact
redundant before its removed. The response of the kernel to the tree
may be different if this check fails..
> [snip]
>>>> +#if MIN_VERSION < 3 || OUT_VERSION > 16
>>>> +/**
>>>> + * move_nops_fwd - move nops in a v16 dt_struct to the beginning
>>>> + * @start - device tree starting address
>>>> + * @count - number of %OF_DT_NOP cells to move
>>>> + */
>>>> +static void move_nops_fwd(u32 *start, int count)
>>>
>>> What on earth is the point of this. The NOPs are perfectly valid
>>> scattered within the tree, why go to all this trouble to shuffle them
>>> about.
>>
>> And if you notice, there is a "how many to move" argument. The point
>> of moving them to the front of the tree is the v17 device tree header
>> takes more space than the v3 one, and the v2 header is smaller than
>> both v17 and v16 header. Since I am converting the tree in place, the
>> space has to come from somewhere. Since we are pretty much guaranteed
>> to get several nops, this function moves them forward so they can be
>> overwritten. In practice we move 1-3 NOPS from the early properties >
>> 8 bytes and early grandchild nodes (eg /cpus/PowerPC,xxx).
>
> This is a hell of a lot of bother to go to for a few bytes.
> Allocating a big-enough buffer for any reasonable devtree in BSS and
> memmove()ing into there would be far simpler.
How big is enough? Who is going to do the research for the various
firmware levels of the big machines to find out how big the tree is?
Sure there are other ways to get the tree to version 16, one way is to
change what is generated. We could update kexec-tools fs2dt to
geneerate a v16 tree to support zImages.
A question for the list: does anyone else have firmware/environment
that supplies a tree < v16?
> [snip]
>>>> + if (tree->last_comp_version > 3)
>>>> + return; /* don't know what to do */
>>>
>>> Rather, don't need to do anything.
>>
>> If the tree is >= 16 then we don't presently need to do anything. If
>> there is a theoritical v4 tree we don't know what to do. And if
>> output
>> version is 17 but input is 16 we don't know what to do either, because
>> there likely aren't nops in the tree to consume. I suppose we could
>> preceed it with a check for version == OUTPUT_VERSION, but then I'm
>> sure I'd get pointless differentation :-).
>
> There will never be a v4. Or anything between v3 and v16.
I could see a v4 defined as v3 + the extra header in v17, not that I am
proposing that. Someone decided to skip to v16 for a reason. If we
knew there would never be v4-v15, why did we skip them?
[too general]
> [snip]
>>>> + /*
>>>> + * move mem_rsvmap and dt_strings if they are before dt_struct
>>>> + * onto our nops . Adjust start addresses for the 3 sections.
>>>> + */
>>>
>>> Hrm. Do we really need to worry about this case. You may be
>>> producing v2 trees in kexec-tools, but do they actually have the
>>> blocks out of order? dtc certainly never produced them that way.
>>
>> Out of order? There has never been a spec as to the order of the
>> blocks, only the implicit assumption that they follow the device tree
>> header in a reasonably packed sequence. booting-without-of says it
>> must be in ram,; the offsets are unsigned 32 bit quantities.
>
>> As to the order, used, the first implemntation was the kernel which
>> writes memreserve, strings, then struct (both the openfirmware client
>> in prom_init and the iSeries procedural library in dt.c). The second
>> implentation written is a procedural based library (similar to
>> iseries,
>> never published, but still used internally) that starts with a
>> pre-built header and string table, builds the dt_struct as the
>> functions are called, and when finished copies the memreserve table
>> and
>> fills in the dt_size, total size, and memreserve offset.
>
> Hrm. Yes, well, the iSeries tree is weird in a bunch of ways.
My point is its the same as the client interface code, and proves the
point the order is not specified nor need it be. And since the order
is the same in platforms/iseries/dt.c and kernel/prom_init.c, I fail to
see your point of calling the iseries code wierd. It's building a
device tree via the structured programming methods of calling
functions, each of which creates a node and the properties for that
node. Doesn't sound that much different than how a ieee bytecode
program would create the device tree and fill out properties, and I
would expect any firmware who created the device tree from scratch (as
oposed to editing a paritially built tree like the fixup hooks
presently in the wrapper) would be structured similarly. Since it
doesn't ahve a dynamic insertion library, it must fill in all the
properties of a node completely before its children, and must travel
some depth first order when creating the tree. I don't see any reason
to call it wierd.
>
>> fs2dt writes memreserve, struct, then strings. Aparently the same as
>> dtc. But yes, the strings can be before the struct, and the mem
>> reserve may or may not be when the strings are before the struct.
>
> Again. We don't need to deal with the general case here - just the
> real case of trees produced by old kexec-tools.
This function isn't conver_kexec_tree_inplacee. While my justification
for merging this code is it can be used as the target for kexec with
kexec-tools, its not my only use. I also have my internal library that
generates a v3 tree with the pieces ordered differently. If the code
is changed from its general support to support only the tree generated
by kexec-tools, then merging has little benifit to me and in fact it is
harder (I have to maintain a diff to a changing target vs adding a file
to the makefile).
I'll write a later reply that talks about what subsets of this series
make sense to merge.
milton
^ permalink raw reply
* [patch 0/8] PS3 AV Settings Driver patches for 2.6.24
From: Geert Uytterhoeven @ 2007-09-26 16:33 UTC (permalink / raw)
To: Antonino A. Daplas, linux-fbdev-devel; +Cc: linuxppc-dev, cbe-oss-dev
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1512 bytes --]
Hi,
Here are some new patches for the PS3 AV Settings Driver (ps3av), which is
used in close collaboration with the PS3 Virtual Frame Buffer Device Driver
(ps3fb):
[1] ps3av: eliminate unneeded temporary variables
[2] ps3av: eliminate PS3AV_DEBUG
[3] ps3av: use PS3 video mode ids in autodetect code
[4] ps3av: treat DVI-D like HDMI in autodetect
[5] ps3av: add autodetection for VESA modes
[6] ps3av: add quirk database for broken monitors
[7] ps3av: remove unused ps3av_set_mode()
[8] ps3av: don't distinguish between `boot' and `non-boot' autodetection
Please review, and queue for 2.6.24 if they're ok. Thanks!
Question: As several DVI-D displays advertise they support 1080i modes while
they actually don't (cfr. the quirk database), perhaps I should drop 1080i
modes completely from the ps3av_preferred_modes[] table? Usually 720p looks
better than 1080i anyway. What do you think?
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/8] ps3av: eliminate unneeded temporary variables
From: Geert Uytterhoeven @ 2007-09-26 16:33 UTC (permalink / raw)
To: Antonino A. Daplas, linux-fbdev-devel
Cc: Geert Uytterhoeven, linuxppc-dev, cbe-oss-dev
In-Reply-To: <20070926163308.772580000@pademelon.sonytel.be>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2224 bytes --]
ps3av: eliminate unneeded temporary variables
Signed-off-by: Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com>
---
drivers/ps3/ps3av_cmd.c | 17 ++++++-----------
1 files changed, 6 insertions(+), 11 deletions(-)
--- a/drivers/ps3/ps3av_cmd.c
+++ b/drivers/ps3/ps3av_cmd.c
@@ -512,7 +512,6 @@ static const u32 ps3av_ns_table[][5] = {
static void ps3av_cnv_ns(u8 *ns, u32 fs, u32 video_vid)
{
u32 av_vid, ns_val;
- u8 *p = ns;
int d;
d = ns_val = 0;
@@ -551,24 +550,22 @@ static void ps3av_cnv_ns(u8 *ns, u32 fs,
else
ns_val = ps3av_ns_table[PS3AV_CMD_AUDIO_FS_44K-BASE][d];
- *p++ = ns_val & 0x000000FF;
- *p++ = (ns_val & 0x0000FF00) >> 8;
- *p = (ns_val & 0x00FF0000) >> 16;
+ *ns++ = ns_val & 0x000000FF;
+ *ns++ = (ns_val & 0x0000FF00) >> 8;
+ *ns = (ns_val & 0x00FF0000) >> 16;
}
#undef BASE
static u8 ps3av_cnv_enable(u32 source, const u8 *enable)
{
- const u8 *p;
u8 ret = 0;
if (source == PS3AV_CMD_AUDIO_SOURCE_SPDIF) {
ret = 0x03;
} else if (source == PS3AV_CMD_AUDIO_SOURCE_SERIAL) {
- p = enable;
- ret = ((p[0] << 4) + (p[1] << 5) + (p[2] << 6) + (p[3] << 7)) |
- 0x01;
+ ret = ((enable[0] << 4) + (enable[1] << 5) + (enable[2] << 6) +
+ (enable[3] << 7)) | 0x01;
} else
printk(KERN_ERR "%s failed, source:%x\n", __func__, source);
return ret;
@@ -576,11 +573,9 @@ static u8 ps3av_cnv_enable(u32 source, c
static u8 ps3av_cnv_fifomap(const u8 *map)
{
- const u8 *p;
u8 ret = 0;
- p = map;
- ret = p[0] + (p[1] << 2) + (p[2] << 4) + (p[3] << 6);
+ ret = map[0] + (map[1] << 2) + (map[2] << 4) + (map[3] << 6);
return ret;
}
--
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/8] ps3av: eliminate PS3AV_DEBUG
From: Geert Uytterhoeven @ 2007-09-26 16:33 UTC (permalink / raw)
To: Antonino A. Daplas, linux-fbdev-devel
Cc: Geert Uytterhoeven, linuxppc-dev, cbe-oss-dev
In-Reply-To: <20070926163308.772580000@pademelon.sonytel.be>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 8694 bytes --]
ps3av: eliminate PS3AV_DEBUG
- Move ps3av_cmd_av_monitor_info_dump from ps3av_cmd.c to ps3av.c, as it's
used there only
- Integrate ps3av_cmd_av_hw_conf_dump() into its sole user
- Use pr_debug() for printing debug info
Signed-off-by: Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com>
---
drivers/ps3/ps3av.c | 72 ++++++++++++++++++++++++++++++++++++++++----
drivers/ps3/ps3av_cmd.c | 66 ----------------------------------------
include/asm-powerpc/ps3av.h | 7 ----
3 files changed, 67 insertions(+), 78 deletions(-)
--- a/drivers/ps3/ps3av.c
+++ b/drivers/ps3/ps3av.c
@@ -656,6 +656,64 @@ static int ps3av_hdmi_get_vid(struct ps3
return vid;
}
+static void ps3av_monitor_info_dump(const struct ps3av_pkt_av_get_monitor_info *monitor_info)
+{
+ const struct ps3av_info_monitor *info = &monitor_info->info;
+ const struct ps3av_info_audio *audio = info->audio;
+ char id[sizeof(info->monitor_id)*3+1];
+ int i;
+
+ pr_debug("Monitor Info: size %u\n", monitor_info->send_hdr.size);
+
+ pr_debug("avport: %02x\n", info->avport);
+ for (i = 0; i < sizeof(info->monitor_id); i++)
+ sprintf(&id[i*3], " %02x", info->monitor_id[i]);
+ pr_debug("monitor_id: %s\n", id);
+ pr_debug("monitor_type: %02x\n", info->monitor_type);
+ pr_debug("monitor_name: %.*s\n", (int)sizeof(info->monitor_name),
+ info->monitor_name);
+
+ /* resolution */
+ pr_debug("resolution_60: bits: %08x native: %08x\n",
+ info->res_60.res_bits, info->res_60.native);
+ pr_debug("resolution_50: bits: %08x native: %08x\n",
+ info->res_50.res_bits, info->res_50.native);
+ pr_debug("resolution_other: bits: %08x native: %08x\n",
+ info->res_other.res_bits, info->res_other.native);
+ pr_debug("resolution_vesa: bits: %08x native: %08x\n",
+ info->res_vesa.res_bits, info->res_vesa.native);
+
+ /* color space */
+ pr_debug("color space rgb: %02x\n", info->cs.rgb);
+ pr_debug("color space yuv444: %02x\n", info->cs.yuv444);
+ pr_debug("color space yuv422: %02x\n", info->cs.yuv422);
+
+ /* color info */
+ pr_debug("color info red: X %04x Y %04x\n", info->color.red_x,
+ info->color.red_y);
+ pr_debug("color info green: X %04x Y %04x\n", info->color.green_x,
+ info->color.green_y);
+ pr_debug("color info blue: X %04x Y %04x\n", info->color.blue_x,
+ info->color.blue_y);
+ pr_debug("color info white: X %04x Y %04x\n", info->color.white_x,
+ info->color.white_y);
+ pr_debug("color info gamma: %08x\n", info->color.gamma);
+
+ /* other info */
+ pr_debug("supported_AI: %02x\n", info->supported_ai);
+ pr_debug("speaker_info: %02x\n", info->speaker_info);
+ pr_debug("num of audio: %02x\n", info->num_of_audio_block);
+
+ /* audio block */
+ for (i = 0; i < info->num_of_audio_block; i++) {
+ pr_debug("audio[%d] type: %02x max_ch: %02x fs: %02x sbit: "
+ "%02x\n",
+ i, audio->type, audio->max_num_of_ch, audio->fs,
+ audio->sbit);
+ audio++;
+ }
+}
+
static int ps3av_auto_videomode(struct ps3av_pkt_av_get_hw_conf *av_hw_conf,
int boot)
{
@@ -671,7 +729,7 @@ static int ps3av_auto_videomode(struct p
if (res < 0)
return -1;
- ps3av_cmd_av_monitor_info_dump(&monitor_info);
+ ps3av_monitor_info_dump(&monitor_info);
info = &monitor_info.info;
/* check DVI */
if (info->monitor_type == PS3AV_MONITOR_TYPE_DVI) {
@@ -727,23 +785,27 @@ static int ps3av_auto_videomode(struct p
static int ps3av_get_hw_conf(struct ps3av *ps3av)
{
int i, j, k, res;
+ const struct ps3av_pkt_av_get_hw_conf *hw_conf;
/* get av_hw_conf */
res = ps3av_cmd_av_get_hw_conf(&ps3av->av_hw_conf);
if (res < 0)
return -1;
- ps3av_cmd_av_hw_conf_dump(&ps3av->av_hw_conf);
+ hw_conf = &ps3av->av_hw_conf;
+ pr_debug("av_h_conf: num of hdmi: %u\n", hw_conf->num_of_hdmi);
+ pr_debug("av_h_conf: num of avmulti: %u\n", hw_conf->num_of_avmulti);
+ pr_debug("av_h_conf: num of spdif: %u\n", hw_conf->num_of_spdif);
for (i = 0; i < PS3AV_HEAD_MAX; i++)
ps3av->head[i] = PS3AV_CMD_VIDEO_HEAD_A + i;
for (i = 0; i < PS3AV_OPT_PORT_MAX; i++)
ps3av->opt_port[i] = PS3AV_CMD_AVPORT_SPDIF_0 + i;
- for (i = 0; i < ps3av->av_hw_conf.num_of_hdmi; i++)
+ for (i = 0; i < hw_conf->num_of_hdmi; i++)
ps3av->av_port[i] = PS3AV_CMD_AVPORT_HDMI_0 + i;
- for (j = 0; j < ps3av->av_hw_conf.num_of_avmulti; j++)
+ for (j = 0; j < hw_conf->num_of_avmulti; j++)
ps3av->av_port[i + j] = PS3AV_CMD_AVPORT_AVMULTI_0 + j;
- for (k = 0; k < ps3av->av_hw_conf.num_of_spdif; k++)
+ for (k = 0; k < hw_conf->num_of_spdif; k++)
ps3av->av_port[i + j + k] = PS3AV_CMD_AVPORT_SPDIF_0 + k;
/* set all audio port */
--- a/drivers/ps3/ps3av_cmd.c
+++ b/drivers/ps3/ps3av_cmd.c
@@ -922,72 +922,6 @@ int ps3av_cmd_video_get_monitor_info(str
return res;
}
-#ifdef PS3AV_DEBUG
-void ps3av_cmd_av_hw_conf_dump(const struct ps3av_pkt_av_get_hw_conf *hw_conf)
-{
- printk("av_h_conf:num of hdmi:%d\n", hw_conf->num_of_hdmi);
- printk("av_h_conf:num of avmulti:%d\n", hw_conf->num_of_avmulti);
- printk("av_h_conf:num of spdif:%d\n", hw_conf->num_of_spdif);
-}
-
-void ps3av_cmd_av_monitor_info_dump(const struct ps3av_pkt_av_get_monitor_info *monitor_info)
-{
- const struct ps3av_info_monitor *info = &monitor_info->info;
- const struct ps3av_info_audio *audio = info->audio;
- int i;
-
- printk("Monitor Info: size%d\n", monitor_info->send_hdr.size);
-
- printk("avport:%02x\n", info->avport);
- printk("monitor_id:");
- for (i = 0; i < 10; i++)
- printk("%02x ", info->monitor_id[i]);
- printk("\nmonitor_type:%02x\n", info->monitor_type);
- printk("monitor_name:");
- for (i = 0; i < 16; i++)
- printk("%c", info->monitor_name[i]);
-
- /* resolution */
- printk("\nresolution_60: bits:%08x native:%08x\n",
- info->res_60.res_bits, info->res_60.native);
- printk("resolution_50: bits:%08x native:%08x\n",
- info->res_50.res_bits, info->res_50.native);
- printk("resolution_other: bits:%08x native:%08x\n",
- info->res_other.res_bits, info->res_other.native);
- printk("resolution_vesa: bits:%08x native:%08x\n",
- info->res_vesa.res_bits, info->res_vesa.native);
-
- /* color space */
- printk("color space rgb:%02x\n", info->cs.rgb);
- printk("color space yuv444:%02x\n", info->cs.yuv444);
- printk("color space yuv422:%02x\n", info->cs.yuv422);
-
- /* color info */
- printk("color info red:X %04x Y %04x\n",
- info->color.red_x, info->color.red_y);
- printk("color info green:X %04x Y %04x\n",
- info->color.green_x, info->color.green_y);
- printk("color info blue:X %04x Y %04x\n",
- info->color.blue_x, info->color.blue_y);
- printk("color info white:X %04x Y %04x\n",
- info->color.white_x, info->color.white_y);
- printk("color info gamma: %08x\n", info->color.gamma);
-
- /* other info */
- printk("supported_AI:%02x\n", info->supported_ai);
- printk("speaker_info:%02x\n", info->speaker_info);
- printk("num of audio:%02x\n", info->num_of_audio_block);
-
- /* audio block */
- for (i = 0; i < info->num_of_audio_block; i++) {
- printk("audio[%d] type:%02x max_ch:%02x fs:%02x sbit:%02x\n",
- i, audio->type, audio->max_num_of_ch, audio->fs,
- audio->sbit);
- audio++;
- }
-}
-#endif /* PS3AV_DEBUG */
-
#define PS3AV_AV_LAYOUT_0 (PS3AV_CMD_AV_LAYOUT_32 \
| PS3AV_CMD_AV_LAYOUT_44 \
| PS3AV_CMD_AV_LAYOUT_48)
--- a/include/asm-powerpc/ps3av.h
+++ b/include/asm-powerpc/ps3av.h
@@ -697,13 +697,6 @@ extern int ps3av_cmd_audio_mute(int, u32
extern int ps3av_cmd_audio_active(int, u32);
extern int ps3av_cmd_avb_param(struct ps3av_pkt_avb_param *, u32);
extern int ps3av_cmd_av_get_hw_conf(struct ps3av_pkt_av_get_hw_conf *);
-#ifdef PS3AV_DEBUG
-extern void ps3av_cmd_av_hw_conf_dump(const struct ps3av_pkt_av_get_hw_conf *);
-extern void ps3av_cmd_av_monitor_info_dump(const struct ps3av_pkt_av_get_monitor_info *);
-#else
-static inline void ps3av_cmd_av_hw_conf_dump(const struct ps3av_pkt_av_get_hw_conf *hw_conf) {}
-static inline void ps3av_cmd_av_monitor_info_dump(const struct ps3av_pkt_av_get_monitor_info *monitor_info) {}
-#endif
extern int ps3av_cmd_video_get_monitor_info(struct ps3av_pkt_av_get_monitor_info *,
u32);
--
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/8] ps3av: use PS3 video mode ids in autodetect code
From: Geert Uytterhoeven @ 2007-09-26 16:33 UTC (permalink / raw)
To: Antonino A. Daplas, linux-fbdev-devel
Cc: Geert Uytterhoeven, linuxppc-dev, cbe-oss-dev
In-Reply-To: <20070926163308.772580000@pademelon.sonytel.be>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 6965 bytes --]
ps3av: use PS3 video mode ids in autodetect code
It doesn't make much sense to use the PS3AV_CMD_VIDEO_VID_* values in the
autodetection code, just to convert them to PS3 video mode ids afterwards.
Signed-off-by: Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com>
---
drivers/ps3/ps3av.c | 90 +++++++++++++++++++-------------------------
include/asm-powerpc/ps3av.h | 11 ++---
2 files changed, 46 insertions(+), 55 deletions(-)
--- a/drivers/ps3/ps3av.c
+++ b/drivers/ps3/ps3av.c
@@ -585,75 +585,65 @@ static void ps3avd(struct work_struct *w
complete(&ps3av->done);
}
-static int ps3av_vid2table_id(int vid)
+static int ps3av_resbit2id(u32 res_50, u32 res_60)
{
- int i;
-
- for (i = 1; i < ARRAY_SIZE(video_mode_table); i++)
- if (video_mode_table[i].vid == vid)
- return i;
- return -1;
-}
-
-static int ps3av_resbit2vid(u32 res_50, u32 res_60)
-{
- int vid = -1;
+ int id = 0;
if (res_50 > res_60) { /* if res_50 == res_60, res_60 will be used */
if (res_50 & PS3AV_RESBIT_1920x1080P)
- vid = PS3AV_CMD_VIDEO_VID_1080P_50HZ;
+ id = 10;
else if (res_50 & PS3AV_RESBIT_1920x1080I)
- vid = PS3AV_CMD_VIDEO_VID_1080I_50HZ;
+ id = 9;
else if (res_50 & PS3AV_RESBIT_1280x720P)
- vid = PS3AV_CMD_VIDEO_VID_720P_50HZ;
+ id = 8;
else if (res_50 & PS3AV_RESBIT_720x576P)
- vid = PS3AV_CMD_VIDEO_VID_576P;
+ id = 7;
else
- vid = -1;
+ id = 0;
} else {
if (res_60 & PS3AV_RESBIT_1920x1080P)
- vid = PS3AV_CMD_VIDEO_VID_1080P_60HZ;
+ id = 5;
else if (res_60 & PS3AV_RESBIT_1920x1080I)
- vid = PS3AV_CMD_VIDEO_VID_1080I_60HZ;
+ id = 4;
else if (res_60 & PS3AV_RESBIT_1280x720P)
- vid = PS3AV_CMD_VIDEO_VID_720P_60HZ;
+ id = 3;
else if (res_60 & PS3AV_RESBIT_720x480P)
- vid = PS3AV_CMD_VIDEO_VID_480P;
+ id = 2;
else
- vid = -1;
+ id = 0;
}
- return vid;
+ return id;
}
-static int ps3av_hdmi_get_vid(struct ps3av_info_monitor *info)
+static int ps3av_hdmi_get_id(struct ps3av_info_monitor *info)
{
u32 res_50, res_60;
- int vid = -1;
+ int id;
if (info->monitor_type != PS3AV_MONITOR_TYPE_HDMI)
- return -1;
+ return 0;
/* check native resolution */
res_50 = info->res_50.native & PS3AV_RES_MASK_50;
res_60 = info->res_60.native & PS3AV_RES_MASK_60;
if (res_50 || res_60) {
- vid = ps3av_resbit2vid(res_50, res_60);
- return vid;
+ id = ps3av_resbit2id(res_50, res_60);
+ return id;
}
/* check resolution */
res_50 = info->res_50.res_bits & PS3AV_RES_MASK_50;
res_60 = info->res_60.res_bits & PS3AV_RES_MASK_60;
if (res_50 || res_60) {
- vid = ps3av_resbit2vid(res_50, res_60);
- return vid;
+ id = ps3av_resbit2id(res_50, res_60);
+ return id;
}
if (ps3av->region & PS3AV_REGION_60)
- vid = PS3AV_DEFAULT_HDMI_VID_REG_60;
+ id = PS3AV_DEFAULT_HDMI_MODE_ID_REG_60;
else
- vid = PS3AV_DEFAULT_HDMI_VID_REG_50;
- return vid;
+ id = PS3AV_DEFAULT_HDMI_MODE_ID_REG_50;
+ return id;
}
static void ps3av_monitor_info_dump(const struct ps3av_pkt_av_get_monitor_info *monitor_info)
@@ -717,11 +707,11 @@ static void ps3av_monitor_info_dump(cons
static int ps3av_auto_videomode(struct ps3av_pkt_av_get_hw_conf *av_hw_conf,
int boot)
{
- int i, res, vid = -1, dvi = 0, rgb = 0;
+ int i, res, id = 0, dvi = 0, rgb = 0;
struct ps3av_pkt_av_get_monitor_info monitor_info;
struct ps3av_info_monitor *info;
- /* get vid for hdmi */
+ /* get mode id for hdmi */
for (i = 0; i < av_hw_conf->num_of_hdmi; i++) {
res = ps3av_cmd_video_get_monitor_info(&monitor_info,
PS3AV_CMD_AVPORT_HDMI_0 +
@@ -737,49 +727,49 @@ static int ps3av_auto_videomode(struct p
break;
}
/* check HDMI */
- vid = ps3av_hdmi_get_vid(info);
- if (vid != -1) {
- /* got valid vid */
+ id = ps3av_hdmi_get_id(info);
+ if (id) {
+ /* got valid mode id */
break;
}
}
if (dvi) {
/* DVI mode */
- vid = PS3AV_DEFAULT_DVI_VID;
- } else if (vid == -1) {
+ id = PS3AV_DEFAULT_DVI_MODE_ID;
+ } else if (!id) {
/* no HDMI interface or HDMI is off */
if (ps3av->region & PS3AV_REGION_60)
- vid = PS3AV_DEFAULT_AVMULTI_VID_REG_60;
+ id = PS3AV_DEFAULT_AVMULTI_MODE_ID_REG_60;
else
- vid = PS3AV_DEFAULT_AVMULTI_VID_REG_50;
+ id = PS3AV_DEFAULT_AVMULTI_MODE_ID_REG_50;
if (ps3av->region & PS3AV_REGION_RGB)
rgb = PS3AV_MODE_RGB;
} else if (boot) {
- /* HDMI: using DEFAULT HDMI_VID while booting up */
+ /* HDMI: using DEFAULT HDMI_MODE_ID while booting up */
info = &monitor_info.info;
if (ps3av->region & PS3AV_REGION_60) {
if (info->res_60.res_bits & PS3AV_RESBIT_720x480P)
- vid = PS3AV_DEFAULT_HDMI_VID_REG_60;
+ id = PS3AV_DEFAULT_HDMI_MODE_ID_REG_60;
else if (info->res_50.res_bits & PS3AV_RESBIT_720x576P)
- vid = PS3AV_DEFAULT_HDMI_VID_REG_50;
+ id = PS3AV_DEFAULT_HDMI_MODE_ID_REG_50;
else {
/* default */
- vid = PS3AV_DEFAULT_HDMI_VID_REG_60;
+ id = PS3AV_DEFAULT_HDMI_MODE_ID_REG_60;
}
} else {
if (info->res_50.res_bits & PS3AV_RESBIT_720x576P)
- vid = PS3AV_DEFAULT_HDMI_VID_REG_50;
+ id = PS3AV_DEFAULT_HDMI_MODE_ID_REG_50;
else if (info->res_60.res_bits & PS3AV_RESBIT_720x480P)
- vid = PS3AV_DEFAULT_HDMI_VID_REG_60;
+ id = PS3AV_DEFAULT_HDMI_MODE_ID_REG_60;
else {
/* default */
- vid = PS3AV_DEFAULT_HDMI_VID_REG_50;
+ id = PS3AV_DEFAULT_HDMI_MODE_ID_REG_50;
}
}
}
- return (ps3av_vid2table_id(vid) | dvi | rgb);
+ return id | dvi | rgb;
}
static int ps3av_get_hw_conf(struct ps3av *ps3av)
--- a/include/asm-powerpc/ps3av.h
+++ b/include/asm-powerpc/ps3av.h
@@ -300,11 +300,12 @@
#define PS3AV_MONITOR_TYPE_HDMI 1 /* HDMI */
#define PS3AV_MONITOR_TYPE_DVI 2 /* DVI */
-#define PS3AV_DEFAULT_HDMI_VID_REG_60 PS3AV_CMD_VIDEO_VID_480P
-#define PS3AV_DEFAULT_AVMULTI_VID_REG_60 PS3AV_CMD_VIDEO_VID_480I
-#define PS3AV_DEFAULT_HDMI_VID_REG_50 PS3AV_CMD_VIDEO_VID_576P
-#define PS3AV_DEFAULT_AVMULTI_VID_REG_50 PS3AV_CMD_VIDEO_VID_576I
-#define PS3AV_DEFAULT_DVI_VID PS3AV_CMD_VIDEO_VID_480P
+
+#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_DEFAULT_DVI_MODE_ID 2 /* 480p */
#define PS3AV_REGION_60 0x01
#define PS3AV_REGION_50 0x02
--
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/8] ps3av: treat DVI-D like HDMI in autodetect
From: Geert Uytterhoeven @ 2007-09-26 16:33 UTC (permalink / raw)
To: Antonino A. Daplas, linux-fbdev-devel
Cc: Geert Uytterhoeven, linuxppc-dev, cbe-oss-dev
In-Reply-To: <20070926163308.772580000@pademelon.sonytel.be>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2765 bytes --]
ps3av: treat DVI-D monitors like HDMI monitors when autodetecting the best
video mode
Signed-off-by: Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com>
---
drivers/ps3/ps3av.c | 24 ++++++++----------------
include/asm-powerpc/ps3av.h | 1 -
2 files changed, 8 insertions(+), 17 deletions(-)
--- a/drivers/ps3/ps3av.c
+++ b/drivers/ps3/ps3av.c
@@ -620,9 +620,6 @@ static int ps3av_hdmi_get_id(struct ps3a
u32 res_50, res_60;
int id;
- if (info->monitor_type != PS3AV_MONITOR_TYPE_HDMI)
- return 0;
-
/* check native resolution */
res_50 = info->res_50.native & PS3AV_RES_MASK_50;
res_60 = info->res_60.native & PS3AV_RES_MASK_60;
@@ -712,7 +709,7 @@ static int ps3av_auto_videomode(struct p
struct ps3av_info_monitor *info;
/* get mode id for hdmi */
- for (i = 0; i < av_hw_conf->num_of_hdmi; i++) {
+ for (i = 0; i < av_hw_conf->num_of_hdmi && !id; i++) {
res = ps3av_cmd_video_get_monitor_info(&monitor_info,
PS3AV_CMD_AVPORT_HDMI_0 +
i);
@@ -720,24 +717,19 @@ static int ps3av_auto_videomode(struct p
return -1;
ps3av_monitor_info_dump(&monitor_info);
+
info = &monitor_info.info;
- /* check DVI */
- if (info->monitor_type == PS3AV_MONITOR_TYPE_DVI) {
+ switch (info->monitor_type) {
+ case PS3AV_MONITOR_TYPE_DVI:
dvi = PS3AV_MODE_DVI;
- break;
- }
- /* check HDMI */
- id = ps3av_hdmi_get_id(info);
- if (id) {
- /* got valid mode id */
+ /* fall through */
+ case PS3AV_MONITOR_TYPE_HDMI:
+ id = ps3av_hdmi_get_id(info);
break;
}
}
- if (dvi) {
- /* DVI mode */
- id = PS3AV_DEFAULT_DVI_MODE_ID;
- } else if (!id) {
+ if (!id) {
/* no HDMI interface or HDMI is off */
if (ps3av->region & PS3AV_REGION_60)
id = PS3AV_DEFAULT_AVMULTI_MODE_ID_REG_60;
--- a/include/asm-powerpc/ps3av.h
+++ b/include/asm-powerpc/ps3av.h
@@ -305,7 +305,6 @@
#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_DEFAULT_DVI_MODE_ID 2 /* 480p */
#define PS3AV_REGION_60 0x01
#define PS3AV_REGION_50 0x02
--
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 5/8] ps3av: add autodetection for VESA modes
From: Geert Uytterhoeven @ 2007-09-26 16:33 UTC (permalink / raw)
To: Antonino A. Daplas, linux-fbdev-devel
Cc: Geert Uytterhoeven, linuxppc-dev, cbe-oss-dev
In-Reply-To: <20070926163308.772580000@pademelon.sonytel.be>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 5737 bytes --]
ps3av: add autodetection for VESA modes
Signed-off-by: Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com>
---
drivers/ps3/ps3av.c | 93 ++++++++++++++++++++++++++------------------
include/asm-powerpc/ps3av.h | 11 ++++-
2 files changed, 67 insertions(+), 37 deletions(-)
--- a/drivers/ps3/ps3av.c
+++ b/drivers/ps3/ps3av.c
@@ -585,54 +585,73 @@ static void ps3avd(struct work_struct *w
complete(&ps3av->done);
}
-static int ps3av_resbit2id(u32 res_50, u32 res_60)
+#define SHIFT_50 0
+#define SHIFT_60 4
+#define SHIFT_VESA 8
+
+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 },
+};
+
+static int ps3av_resbit2id(u32 res_50, u32 res_60, u32 res_vesa)
{
- int id = 0;
+ unsigned int i;
+ u32 res_all;
- if (res_50 > res_60) { /* if res_50 == res_60, res_60 will be used */
- if (res_50 & PS3AV_RESBIT_1920x1080P)
- id = 10;
- else if (res_50 & PS3AV_RESBIT_1920x1080I)
- id = 9;
- else if (res_50 & PS3AV_RESBIT_1280x720P)
- id = 8;
- else if (res_50 & PS3AV_RESBIT_720x576P)
- id = 7;
- else
- id = 0;
- } else {
- if (res_60 & PS3AV_RESBIT_1920x1080P)
- id = 5;
- else if (res_60 & PS3AV_RESBIT_1920x1080I)
- id = 4;
- else if (res_60 & PS3AV_RESBIT_1280x720P)
- id = 3;
- else if (res_60 & PS3AV_RESBIT_720x480P)
- id = 2;
- else
- id = 0;
- }
- return id;
+ /*
+ * We mask off the resolution bits we care about and combine the
+ * results in one bitfield, so make sure there's no overlap
+ */
+ BUILD_BUG_ON(PS3AV_RES_MASK_50 << SHIFT_50 &
+ PS3AV_RES_MASK_60 << SHIFT_60);
+ BUILD_BUG_ON(PS3AV_RES_MASK_50 << SHIFT_50 &
+ PS3AV_RES_MASK_VESA << SHIFT_VESA);
+ BUILD_BUG_ON(PS3AV_RES_MASK_60 << SHIFT_60 &
+ PS3AV_RES_MASK_VESA << SHIFT_VESA);
+ res_all = (res_50 & PS3AV_RES_MASK_50) << SHIFT_50 |
+ (res_60 & PS3AV_RES_MASK_60) << SHIFT_60 |
+ (res_vesa & PS3AV_RES_MASK_VESA) << SHIFT_VESA;
+
+ if (!res_all)
+ return 0;
+
+ for (i = 0; i < ARRAY_SIZE(ps3av_preferred_modes); i++)
+ if (res_all & ps3av_preferred_modes[i].mask)
+ return ps3av_preferred_modes[i].id;
+
+ return 0;
}
static int ps3av_hdmi_get_id(struct ps3av_info_monitor *info)
{
- u32 res_50, res_60;
int id;
/* check native resolution */
- res_50 = info->res_50.native & PS3AV_RES_MASK_50;
- res_60 = info->res_60.native & PS3AV_RES_MASK_60;
- if (res_50 || res_60) {
- id = ps3av_resbit2id(res_50, res_60);
+ id = ps3av_resbit2id(info->res_50.native, info->res_60.native,
+ info->res_vesa.native);
+ if (id) {
+ pr_debug("%s: Using native mode %d\n", __func__, id);
return id;
}
- /* check resolution */
- res_50 = info->res_50.res_bits & PS3AV_RES_MASK_50;
- res_60 = info->res_60.res_bits & PS3AV_RES_MASK_60;
- if (res_50 || res_60) {
- id = ps3av_resbit2id(res_50, res_60);
+ /* check supported resolutions */
+ id = ps3av_resbit2id(info->res_50.res_bits, info->res_60.res_bits,
+ info->res_vesa.res_bits);
+ if (id) {
+ pr_debug("%s: Using supported mode %d\n", __func__, id);
return id;
}
@@ -640,6 +659,7 @@ static int ps3av_hdmi_get_id(struct ps3a
id = PS3AV_DEFAULT_HDMI_MODE_ID_REG_60;
else
id = PS3AV_DEFAULT_HDMI_MODE_ID_REG_50;
+ pr_debug("%s: Using default mode %d\n", __func__, id);
return id;
}
@@ -737,6 +757,7 @@ static int ps3av_auto_videomode(struct p
id = PS3AV_DEFAULT_AVMULTI_MODE_ID_REG_50;
if (ps3av->region & PS3AV_REGION_RGB)
rgb = PS3AV_MODE_RGB;
+ pr_debug("%s: Using avmulti mode %d\n", __func__, id);
} else if (boot) {
/* HDMI: using DEFAULT HDMI_MODE_ID while booting up */
info = &monitor_info.info;
--- a/include/asm-powerpc/ps3av.h
+++ b/include/asm-powerpc/ps3av.h
@@ -283,7 +283,7 @@
#define PS3AV_CMD_VIDEO_CS_YUV422 0x0002
#define PS3AV_CMD_VIDEO_CS_YUV444 0x0003
-/* for automode */
+/* for broadcast automode */
#define PS3AV_RESBIT_720x480P 0x0003 /* 0x0001 | 0x0002 */
#define PS3AV_RESBIT_720x576P 0x0003 /* 0x0001 | 0x0002 */
#define PS3AV_RESBIT_1280x720P 0x0004
@@ -298,6 +298,15 @@
| PS3AV_RESBIT_1920x1080I \
| PS3AV_RESBIT_1920x1080P)
+/* for VESA automode */
+#define PS3AV_RESBIT_VGA 0x0001
+#define PS3AV_RESBIT_WXGA 0x0002
+#define PS3AV_RESBIT_SXGA 0x0004
+#define PS3AV_RESBIT_WUXGA 0x0008
+#define PS3AV_RES_MASK_VESA (PS3AV_RESBIT_WXGA |\
+ PS3AV_RESBIT_SXGA |\
+ PS3AV_RESBIT_WUXGA)
+
#define PS3AV_MONITOR_TYPE_HDMI 1 /* HDMI */
#define PS3AV_MONITOR_TYPE_DVI 2 /* DVI */
--
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 6/8] ps3av: add quirk database for broken monitors
From: Geert Uytterhoeven @ 2007-09-26 16:33 UTC (permalink / raw)
To: Antonino A. Daplas, linux-fbdev-devel
Cc: Geert Uytterhoeven, linuxppc-dev, cbe-oss-dev
In-Reply-To: <20070926163308.772580000@pademelon.sonytel.be>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2502 bytes --]
ps3av: add a quirk database for broken monitors where the `best' advertised
video mode doesn't work
Signed-off-by: Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com>
---
drivers/ps3/ps3av.c | 41 +++++++++++++++++++++++++++++++++++++++++
1 files changed, 41 insertions(+)
--- a/drivers/ps3/ps3av.c
+++ b/drivers/ps3/ps3av.c
@@ -721,6 +721,45 @@ static void ps3av_monitor_info_dump(cons
}
}
+static const struct ps3av_monitor_quirk {
+ const char *monitor_name;
+ u32 clear_60, clear_50, clear_vesa;
+} ps3av_monitor_quirks[] = {
+ {
+ .monitor_name = "DELL 2007WFP",
+ .clear_60 = PS3AV_RESBIT_1920x1080I
+ }, {
+ .monitor_name = "L226WTQ",
+ .clear_60 = PS3AV_RESBIT_1920x1080I |
+ PS3AV_RESBIT_1920x1080P
+ }, {
+ .monitor_name = "SyncMaster",
+ .clear_60 = PS3AV_RESBIT_1920x1080I
+ }
+};
+
+static void ps3av_fixup_monitor_info(struct ps3av_info_monitor *info)
+{
+ unsigned int i;
+ const struct ps3av_monitor_quirk *quirk;
+
+ for (i = 0; i < ARRAY_SIZE(ps3av_monitor_quirks); i++) {
+ quirk = &ps3av_monitor_quirks[i];
+ if (!strncmp(info->monitor_name, quirk->monitor_name,
+ sizeof(info->monitor_name))) {
+ pr_info("%s: Applying quirk for %s\n", __func__,
+ quirk->monitor_name);
+ info->res_60.res_bits &= ~quirk->clear_60;
+ info->res_60.native &= ~quirk->clear_60;
+ info->res_50.res_bits &= ~quirk->clear_50;
+ info->res_50.native &= ~quirk->clear_50;
+ info->res_vesa.res_bits &= ~quirk->clear_vesa;
+ info->res_vesa.native &= ~quirk->clear_vesa;
+ break;
+ }
+ }
+}
+
static int ps3av_auto_videomode(struct ps3av_pkt_av_get_hw_conf *av_hw_conf,
int boot)
{
@@ -739,6 +778,8 @@ static int ps3av_auto_videomode(struct p
ps3av_monitor_info_dump(&monitor_info);
info = &monitor_info.info;
+ ps3av_fixup_monitor_info(info);
+
switch (info->monitor_type) {
case PS3AV_MONITOR_TYPE_DVI:
dvi = PS3AV_MODE_DVI;
--
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/8] ps3av: remove unused ps3av_set_mode()
From: Geert Uytterhoeven @ 2007-09-26 16:33 UTC (permalink / raw)
To: Antonino A. Daplas, linux-fbdev-devel
Cc: Geert Uytterhoeven, linuxppc-dev, cbe-oss-dev
In-Reply-To: <20070926163308.772580000@pademelon.sonytel.be>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1898 bytes --]
ps3av: remove unused ps3av_set_mode()
Signed-off-by: Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com>
---
drivers/ps3/ps3av.c | 21 ---------------------
include/asm-powerpc/ps3av.h | 1 -
2 files changed, 22 deletions(-)
--- a/drivers/ps3/ps3av.c
+++ b/drivers/ps3/ps3av.c
@@ -903,27 +903,6 @@ int ps3av_get_auto_mode(int boot)
EXPORT_SYMBOL_GPL(ps3av_get_auto_mode);
-int ps3av_set_mode(u32 id, int boot)
-{
- int res;
-
- res = ps3av_set_video_mode(id, boot);
- if (res)
- return res;
-
- res = ps3av_set_audio_mode(PS3AV_CMD_AUDIO_NUM_OF_CH_2,
- PS3AV_CMD_AUDIO_FS_48K,
- PS3AV_CMD_AUDIO_WORD_BITS_16,
- PS3AV_CMD_AUDIO_FORMAT_PCM,
- PS3AV_CMD_AUDIO_SOURCE_SERIAL);
- if (res)
- return res;
-
- return 0;
-}
-
-EXPORT_SYMBOL_GPL(ps3av_set_mode);
-
int ps3av_get_mode(void)
{
return ps3av ? ps3av->ps3av_mode : 0;
--- a/include/asm-powerpc/ps3av.h
+++ b/include/asm-powerpc/ps3av.h
@@ -712,7 +712,6 @@ extern int ps3av_cmd_video_get_monitor_i
extern int ps3av_set_video_mode(u32, int);
extern int ps3av_set_audio_mode(u32, u32, u32, u32, u32);
extern int ps3av_get_auto_mode(int);
-extern int ps3av_set_mode(u32, int);
extern int ps3av_get_mode(void);
extern int ps3av_get_scanmode(int);
extern int ps3av_get_refresh_rate(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 8/8] ps3av: dont distinguish between `boot and `non-boot autodetection
From: Geert Uytterhoeven @ 2007-09-26 16:33 UTC (permalink / raw)
To: Antonino A. Daplas, linux-fbdev-devel
Cc: Geert Uytterhoeven, linuxppc-dev, cbe-oss-dev
In-Reply-To: <20070926163308.772580000@pademelon.sonytel.be>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 4958 bytes --]
ps3av: don't distinguish between `boot' and `non-boot' autodetection now the
autodetection code has been improved
Signed-off-by: Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com>
---
drivers/ps3/ps3av.c | 35 ++++++-----------------------------
drivers/video/ps3fb.c | 6 ++----
include/asm-powerpc/ps3av.h | 4 ++--
3 files changed, 10 insertions(+), 35 deletions(-)
--- a/drivers/ps3/ps3av.c
+++ b/drivers/ps3/ps3av.c
@@ -760,8 +760,7 @@ static void ps3av_fixup_monitor_info(str
}
}
-static int ps3av_auto_videomode(struct ps3av_pkt_av_get_hw_conf *av_hw_conf,
- int boot)
+static int ps3av_auto_videomode(struct ps3av_pkt_av_get_hw_conf *av_hw_conf)
{
int i, res, id = 0, dvi = 0, rgb = 0;
struct ps3av_pkt_av_get_monitor_info monitor_info;
@@ -799,28 +798,6 @@ static int ps3av_auto_videomode(struct p
if (ps3av->region & PS3AV_REGION_RGB)
rgb = PS3AV_MODE_RGB;
pr_debug("%s: Using avmulti mode %d\n", __func__, id);
- } else if (boot) {
- /* HDMI: using DEFAULT HDMI_MODE_ID while booting up */
- info = &monitor_info.info;
- if (ps3av->region & PS3AV_REGION_60) {
- if (info->res_60.res_bits & PS3AV_RESBIT_720x480P)
- id = PS3AV_DEFAULT_HDMI_MODE_ID_REG_60;
- else if (info->res_50.res_bits & PS3AV_RESBIT_720x576P)
- id = PS3AV_DEFAULT_HDMI_MODE_ID_REG_50;
- else {
- /* default */
- id = PS3AV_DEFAULT_HDMI_MODE_ID_REG_60;
- }
- } else {
- if (info->res_50.res_bits & PS3AV_RESBIT_720x576P)
- id = PS3AV_DEFAULT_HDMI_MODE_ID_REG_50;
- else if (info->res_60.res_bits & PS3AV_RESBIT_720x480P)
- id = PS3AV_DEFAULT_HDMI_MODE_ID_REG_60;
- else {
- /* default */
- id = PS3AV_DEFAULT_HDMI_MODE_ID_REG_50;
- }
- }
}
return id | dvi | rgb;
@@ -862,7 +839,7 @@ static int ps3av_get_hw_conf(struct ps3a
}
/* set mode using id */
-int ps3av_set_video_mode(u32 id, int boot)
+int ps3av_set_video_mode(u32 id)
{
int size;
u32 option;
@@ -876,7 +853,7 @@ int ps3av_set_video_mode(u32 id, int boo
/* auto mode */
option = id & ~PS3AV_MODE_MASK;
if ((id & PS3AV_MODE_MASK) == 0) {
- id = ps3av_auto_videomode(&ps3av->av_hw_conf, boot);
+ id = ps3av_auto_videomode(&ps3av->av_hw_conf);
if (id < 1) {
printk(KERN_ERR "%s: invalid id :%d\n", __func__, id);
return -EINVAL;
@@ -896,9 +873,9 @@ int ps3av_set_video_mode(u32 id, int boo
EXPORT_SYMBOL_GPL(ps3av_set_video_mode);
-int ps3av_get_auto_mode(int boot)
+int ps3av_get_auto_mode(void)
{
- return ps3av_auto_videomode(&ps3av->av_hw_conf, boot);
+ return ps3av_auto_videomode(&ps3av->av_hw_conf);
}
EXPORT_SYMBOL_GPL(ps3av_get_auto_mode);
@@ -1044,7 +1021,7 @@ static int ps3av_probe(struct ps3_system
res);
ps3av_get_hw_conf(ps3av);
- id = ps3av_auto_videomode(&ps3av->av_hw_conf, 1);
+ id = ps3av_auto_videomode(&ps3av->av_hw_conf);
mutex_lock(&ps3av->mutex);
ps3av->ps3av_mode = id;
mutex_unlock(&ps3av->mutex);
--- a/drivers/video/ps3fb.c
+++ b/drivers/video/ps3fb.c
@@ -548,7 +548,6 @@ static int ps3fb_set_par(struct fb_info
unsigned int mode;
int i;
unsigned long offset;
- static int first = 1;
DPRINTK("xres:%d xv:%d yres:%d yv:%d clock:%d\n",
info->var.xres, info->var.xres_virtual,
@@ -572,10 +571,9 @@ static int ps3fb_set_par(struct fb_info
/* Keep the special bits we cannot set using fb_var_screeninfo */
ps3fb_mode = (ps3fb_mode & ~PS3AV_MODE_MASK) | mode;
- if (ps3av_set_video_mode(ps3fb_mode, first))
+ if (ps3av_set_video_mode(ps3fb_mode))
return -EINVAL;
- first = 0;
return 0;
}
@@ -737,7 +735,7 @@ static int ps3fb_ioctl(struct fb_info *i
break;
if (!(val & PS3AV_MODE_MASK)) {
- u32 id = ps3av_get_auto_mode(0);
+ u32 id = ps3av_get_auto_mode();
if (id > 0)
val = (val & ~PS3AV_MODE_MASK) | id;
}
--- a/include/asm-powerpc/ps3av.h
+++ b/include/asm-powerpc/ps3av.h
@@ -709,9 +709,9 @@ extern int ps3av_cmd_av_get_hw_conf(stru
extern int ps3av_cmd_video_get_monitor_info(struct ps3av_pkt_av_get_monitor_info *,
u32);
-extern int ps3av_set_video_mode(u32, int);
+extern int ps3av_set_video_mode(u32);
extern int ps3av_set_audio_mode(u32, u32, u32, u32, u32);
-extern int ps3av_get_auto_mode(int);
+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);
--
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] Added missing CEURNR register
From: Emil Medve @ 2007-09-26 17:03 UTC (permalink / raw)
To: kumar.gala, paulus, linuxppc-dev, linuxppc-embedded; +Cc: Emil Medve
According to the publicly available MPC8360E RM (rev. 1 from 09/2006 and rev. 2
from 05/2007) and MPC8323E RM (rev. 1 from 09/2006), CEURNR is the QE microcode
revision number register and is located at offset 0x1b8 within the QE internal
register space
Signed-off-by: Emil Medve <Emilian.Medve@Freescale.com>
---
I'm writing a driver and I felt the need to know the microcode revision
This patch is against Paul's tree: c4d5e375470862fd741f93bf0686d7ac2f7fdce4
powerpc> scripts/checkpatch.pl 0001-Added-missing-CEURNR-register.patch
Your patch has no obvious style problems and is ready for submission.
include/asm-powerpc/immap_qe.h | 5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/include/asm-powerpc/immap_qe.h b/include/asm-powerpc/immap_qe.h
index 1020b7f..02548f7 100644
--- a/include/asm-powerpc/immap_qe.h
+++ b/include/asm-powerpc/immap_qe.h
@@ -86,8 +86,9 @@ struct cp_qe {
__be16 ceexe4; /* QE external request 4 event register */
u8 res11[0x2];
__be16 ceexm4; /* QE external request 4 mask register */
- u8 res12[0x2];
- u8 res13[0x280];
+ u8 res12[0x3A];
+ __be32 ceurnr; /* QE microcode revision number register */
+ u8 res13[0x244];
} __attribute__ ((packed));
/* QE Multiplexer */
--
1.5.3.GIT
^ permalink raw reply related
* RE: git files from secret lab
From: Ming Liu @ 2007-09-26 18:06 UTC (permalink / raw)
To: mead, linuxppc-embedded
In-Reply-To: <D1AFFAE2CC4BD54CA4C1543CFF4A4FCC5972C9@exchangemb3.bnl.gov>
You should perhaps update your git tools into a newer version.
BR
Ming
>From: "Mead, Joseph" <mead@bnl.gov>
>To: <linuxppc-embedded@ozlabs.org>
>Subject: git files from secret lab
>Date: Wed, 26 Sep 2007 10:53:32 -0400
>
>Hi,
>
>I'm trying to download the xilinx patches from Grant's git repository,
>but don't quite understand what I am doing.
>
>I cloned the tree from Linus' tree
>
>git clone
>git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
>(this worked fine)
>
>cd linux-2.6
>
>git fetch git://git.secretlab.ca/git/linux-2.6.git virtex-dev:virtex-dev
>
>I get the error message:
>Fatal: unexpected EOF
>Fetch failure: git://git.secretlab.ca/git/linux-2.6.git
>
>
>
>Thanks,
>Joe
>
>
>
>
>_______________________________________________
>Linuxppc-embedded mailing list
>Linuxppc-embedded@ozlabs.org
>https://ozlabs.org/mailman/listinfo/linuxppc-embedded
_________________________________________________________________
与联机的朋友进行交流，请使用 MSN Messenger: http://messenger.msn.com/cn
^ permalink raw reply
* Re: [PATCH v2 1/4] Implement {read,update}_persistent_clock.
From: Steven Rostedt @ 2007-09-26 19:04 UTC (permalink / raw)
To: Tony Breeds
Cc: linuxppc-dev, Thomas Gleixner, Paul Mackerras, Realtime Kernel
In-Reply-To: <1190345162.620000.305760830507.qpush@thor>
Tony,
I'm about to release a new -rt patch based on -rc8. This patch series
blew up totally in trying to get it applied. I'm leaving it out, so after
I release the next series, could you update these patches.
Thanks,
-- Steve
^ permalink raw reply
* Re: [PATCH v2 1/4] Implement {read,update}_persistent_clock.
From: Sergei Shtylyov @ 2007-09-26 19:39 UTC (permalink / raw)
To: Steven Rostedt
Cc: linuxppc-dev, Thomas Gleixner, Paul Mackerras, Realtime Kernel
In-Reply-To: <Pine.LNX.4.58.0709261502590.4465@gandalf.stny.rr.com>
Hello.
Steven Rostedt wrote:
> Tony,
> I'm about to release a new -rt patch based on -rc8. This patch series
> blew up totally in trying to get it applied. I'm leaving it out, so after
> I release the next series, could you update these patches.
No wonder here: the -rt patch already has much of this code since around
2.6.21. They have been submitted by me, mostly... and this patchset is
against the Linus' tree.
WBR, Sergei
^ 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