* Re: dtc: Fold comment handling test into testsuite
From: Jon Loeliger @ 2008-02-15 14:12 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev
In-Reply-To: <20080215041416.GA6221@localhost.localdomain>
So, like, the other day David Gibson mumbled:
> For ages dtc has included a sample dts, comment-test.dts, for checking
> various lexical corner cases in comment processing. In fact, it
> predates the automated testsuite, and has never been integrated into
> it. This patch addresses this oversight, folding the comment handling
> test in with the rest of the testsuite.
>
> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Applied.
Thanks,
jdl
^ permalink raw reply
* [PATCH] booting-without-of: add Xilinx uart 16550.
From: Pavel Kiryukhin @ 2008-02-15 13:40 UTC (permalink / raw)
To: linuxppc-dev
Add uart 16550 properties description to Xilinx portion of booting-without-of.txt
Signed-off-by: Pavel Kiryukhin <pkiryukhin@ru.mvista.com>
---
Documentation/powerpc/booting-without-of.txt | 16 ++++++++++++++--
1 files changed, 14 insertions(+), 2 deletions(-)
diff --git a/Documentation/powerpc/booting-without-of.txt b/Documentation/powerpc/booting-without-of.txt
index 7b4e8a7..dd77bbc 100644
--- a/Documentation/powerpc/booting-without-of.txt
+++ b/Documentation/powerpc/booting-without-of.txt
@@ -2575,10 +2575,22 @@ platforms are moved over to use the flattened-device-tree model.
Xilinx uartlite devices are simple fixed speed serial ports.
- Requred properties:
+ Required properties:
- current-speed : Baud rate of uartlite
- v) Xilinx hwicap
+ v) Xilinx Uart 16550
+
+ Xilinx uart 16550 device registers are compatible with all standard 16540
+ and 16550 UARTs.
+
+ Required properties:
+ - current-speed : Baud rate of uart.
+ - clock-frequency : Baud rate generator reference clock. May be driven
+ by OPB_Clk (100 MHz).
+ - reg-shift : registers offset shift (standard uart_port field).
+ Property is optional if regshift is zero.
+
+ vi) Xilinx hwicap
Xilinx hwicap devices provide access to the configuration logic
of the FPGA through the Internal Configuration Access Port
--
1.5.4.1
^ permalink raw reply related
* [PATCH v2] [POWERPC] Enable correct operation of serial ports with nonzero regshift.
From: Pavel Kiryukhin @ 2008-02-15 13:30 UTC (permalink / raw)
To: linuxppc-dev
Add regshift reading to serial drivers.
This enables correct operation of serial ports with
nonzero regshift such as Xilinx opb 16550 uart.
Signed-off-by: Pavel Kiryukhin <pkiryukhin@ru.mvista.com>
arch/powerpc/kernel/legacy_serial.c | 6 +++++-
drivers/serial/of_serial.c | 6 ++++--
2 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/kernel/legacy_serial.c b/arch/powerpc/kernel/legacy_serial.c
index 61dd174..949e41c 100644
--- a/arch/powerpc/kernel/legacy_serial.c
+++ b/arch/powerpc/kernel/legacy_serial.c
@@ -50,7 +50,7 @@ static int __init add_legacy_port(struct device_node *np, int want_index,
phys_addr_t taddr, unsigned long irq,
upf_t flags, int irq_check_parent)
{
- const u32 *clk, *spd;
+ const u32 *clk, *spd, *regshift;
u32 clock = BASE_BAUD * 16;
int index;
@@ -62,6 +62,9 @@ static int __init add_legacy_port(struct device_node *np, int want_index,
/* get default speed if present */
spd = of_get_property(np, "current-speed", NULL);
+ /* get regshift if present*/
+ regshift = of_get_property(np, "reg-shift", NULL);
+
/* If we have a location index, then try to use it */
if (want_index >= 0 && want_index < MAX_LEGACY_SERIAL_PORTS)
index = want_index;
@@ -104,6 +107,7 @@ static int __init add_legacy_port(struct device_node *np, int want_index,
legacy_serial_ports[index].uartclk = clock;
legacy_serial_ports[index].irq = irq;
legacy_serial_ports[index].flags = flags;
+ legacy_serial_ports[index].regshift = regshift ? (u8)*regshift : 0;
legacy_serial_infos[index].taddr = taddr;
legacy_serial_infos[index].np = of_node_get(np);
legacy_serial_infos[index].clock = clock;
diff --git a/drivers/serial/of_serial.c b/drivers/serial/of_serial.c
index a64d858..3f09c5a 100644
--- a/drivers/serial/of_serial.c
+++ b/drivers/serial/of_serial.c
@@ -30,7 +30,7 @@ static int __devinit of_platform_serial_setup(struct of_device *ofdev,
{
struct resource resource;
struct device_node *np = ofdev->node;
- const unsigned int *clk, *spd;
+ const unsigned int *clk, *spd, *regshift;
int ret;
memset(port, 0, sizeof *port);
@@ -40,7 +40,7 @@ static int __devinit of_platform_serial_setup(struct of_device *ofdev,
dev_warn(&ofdev->dev, "no clock-frequency property set\n");
return -ENODEV;
}
-
+ regshift = of_get_property(np, "reg-shift", NULL);
ret = of_address_to_resource(np, 0, &resource);
if (ret) {
dev_warn(&ofdev->dev, "invalid address\n");
@@ -57,6 +57,8 @@ static int __devinit of_platform_serial_setup(struct of_device *ofdev,
| UPF_FIXED_PORT;
port->dev = &ofdev->dev;
port->custom_divisor = *clk / (16 * (*spd));
+ if (regshift)
+ port->regshift = *regshift;
return 0;
}
^ permalink raw reply related
* [PATCH] fs_enet: Remove unused fields in the fs_mii_bb_platform_info structure.
From: Laurent Pinchart @ 2008-02-15 13:27 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 1606 bytes --]
The mdio_port, mdio_bit, mdc_port and mdc_bit fields in the
fs_mii_bb_platform_info structure are left-overs from the move to the Phy
Abstraction Layer subsystem. They can be safely removed.
Signed-off-by: Laurent Pinchart <laurentp@cse-semaphore.com>
---
arch/powerpc/sysdev/fsl_soc.c | 4 ----
include/linux/fs_enet_pd.h | 4 ----
2 files changed, 0 insertions(+), 8 deletions(-)
diff --git a/arch/powerpc/sysdev/fsl_soc.c b/arch/powerpc/sysdev/fsl_soc.c
index 3ace747..cefc8b4 100644
--- a/arch/powerpc/sysdev/fsl_soc.c
+++ b/arch/powerpc/sysdev/fsl_soc.c
@@ -804,10 +804,6 @@ static int __init fs_enet_of_init(void)
mdio_bb_prop[1];
fs_enet_mdio_bb_data.mdc_dat.bit =
mdio_bb_prop[2];
- fs_enet_mdio_bb_data.mdio_port =
- mdio_bb_prop[3];
- fs_enet_mdio_bb_data.mdc_port =
- mdio_bb_prop[4];
fs_enet_mdio_bb_data.delay =
mdio_bb_prop[5];
diff --git a/include/linux/fs_enet_pd.h b/include/linux/fs_enet_pd.h
index 9bc045b..decc4b5 100644
--- a/include/linux/fs_enet_pd.h
+++ b/include/linux/fs_enet_pd.h
@@ -103,10 +103,6 @@ struct fs_mii_bb_platform_info {
struct fs_mii_bit mdio_dir;
struct fs_mii_bit mdio_dat;
struct fs_mii_bit mdc_dat;
- int mdio_port; /* port & bit for MDIO */
- int mdio_bit;
- int mdc_port; /* port & bit for MDC */
- int mdc_bit;
int delay; /* delay in us */
int irq[32]; /* irqs per phy's */
};
--
1.5.0
--
Laurent Pinchart
CSE Semaphore Belgium
Chaussée de Bruxelles, 732A
B-1410 Waterloo
Belgium
T +32 (2) 387 42 59
F +32 (2) 387 42 75
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply related
* Re: [PATCH 6/9] fs_enet: Be an of_platform device when CONFIG_PPC_CPM_NEW_BINDING is set.
From: Laurent Pinchart @ 2008-02-15 12:50 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Scott Wood, netdev, jgarzik
In-Reply-To: <20070920220121.GF28784@loki.buserror.net>
[-- Attachment #1: Type: text/plain, Size: 1979 bytes --]
Hi Scott,
I apologize for bringing this after so much time. Hope the "better late than
never" motto applies.
On Friday 21 September 2007 00:01, Scott Wood wrote:
> The existing OF glue code was crufty and broken. Rather than fix it, it
> will be removed, and the ethernet driver now talks to the device tree
> directly.
>
> The old, non-CONFIG_PPC_CPM_NEW_BINDING code can go away once CPM
> platforms are dropped from arch/ppc (which will hopefully be soon), and
> existing arch/powerpc boards that I wasn't able to test on for this
> patchset get converted (which should be even sooner).
>
> Signed-off-by: Scott Wood <scottwood@freescale.com>
[snip]
> diff --git a/drivers/net/fs_enet/fs_enet.h b/drivers/net/fs_enet/fs_enet.h
> index f8c7ee8..14ebba8 100644
> --- a/drivers/net/fs_enet/fs_enet.h
> +++ b/drivers/net/fs_enet/fs_enet.h
> @@ -24,19 +24,6 @@ struct fec_info {
> #include <asm/cpm2.h>
> #endif
>
> -/* This is used to operate with pins.
> - Note that the actual port size may
> - be different; cpm(s) handle it OK */
> -struct bb_info {
> - u8 mdio_dat_msk;
> - u8 mdio_dir_msk;
> - u8 *mdio_dir;
> - u8 *mdio_dat;
> - u8 mdc_msk;
> - u8 *mdc_dat;
> - int delay;
> -};
> -
[snip]
> diff --git a/drivers/net/fs_enet/mii-bitbang.c
> b/drivers/net/fs_enet/mii-bitbang.c index 8f766a5..2b9c44c 100644
> --- a/drivers/net/fs_enet/mii-bitbang.c
> +++ b/drivers/net/fs_enet/mii-bitbang.c
[snip]
> +struct bb_info {
> + __be32 __iomem *dir;
> + __be32 __iomem *dat;
> + u32 mdio_msk;
> + u32 mdc_msk;
> + int delay;
> +};
We're loosing the possibility of having MDC and MDIO on different ports. This
is quite easy to fix for the non-CONFIG_PPC_CPM_NEW_BINDING case but I'm not
familiar with OF bindings (yet) to fix the CONFIG_PPC_CPM_NEW_BINDING case.
--
Laurent Pinchart
CSE Semaphore Belgium
Chaussée de Bruxelles, 732A
B-1410 Waterloo
Belgium
T +32 (2) 387 42 59
F +32 (2) 387 42 75
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH 04/11] [RFC][GPIOLIB] add gpio_set_dedicated() routine
From: Anton Vorontsov @ 2008-02-15 11:40 UTC (permalink / raw)
To: David Brownell; +Cc: linuxppc-dev
In-Reply-To: <200802142036.40770.david-b@pacbell.net>
On Thu, Feb 14, 2008 at 08:36:40PM -0800, David Brownell wrote:
[...]
> > The point was: GPIOs could be "input only" but you still have
> > "output" callback, and that doesn't troubles anybody. Not sure
> > why set_dedicated() such a big issue then, it could fail too! :-)
>
> See above: you're equating pin and gpio ... and while GPIOs
> have (by definition) standardized boolean input and output
> functionality, the rest of what can be done with a pin isn't.
There is nothing much left to do with a "pin", IMO. Pin can be GPIO
or abstract "dedicated function". Am I missing anything else here?
> > We're talking about General Purpose IOs, right? They're general
> > enough to support not only input/output stuff. And we want some
> > API for these General Purpose IOs. GPIO LIB is the best candidate
> > and we can implement such API at almost no cost, few lines of code.
>
> GPIOs are not intended to be a kitchen sink though; and that's
> the sense in which you seem to mean "best candidate": it's a
> clean lightweight interface, not gummed up with all kinds of
> unrelated stuff.
Just one more callback won't bloat lightweight interface... Later
I'll ask to add another one, and someone will ask for another. Yes, I
see the pattern. Surely, if you want to keep it clean and lightweight,
you should resist to additions -- I fully understand that. :-)
> Take your ideas and use them to create a pin configuration
> interface. On some platforms, configurable pins will map
> onto GPIOs, one-to-one. On others, there will be configurable
> pins that aren't GPIOs ... GPIOs that can be mapped to any of
> several pins ... pins that can be used with several GPIOs ...
> pins that can only be used with GPIOs ... and so on.
Sure, that's doable. But IMO this idea is about overcomplicating
the trivial task. Let's call it pinlib, with:
1. pin_request
2. pin_configure(pin, integer-representing-configuration)
3. pin_free
Hm... 2 auxiliary functions with the full-fledged subsystem just to
configure some pins? Plus count here that drivers would have to deal
with the two separate subsystems. Both GPIO/Pin-providers and
drivers that would use these GPIOs/Pins.
> > > The way it's usually done: platform-specific code to handle those
> > > platform-specific pin configuration issues.
> >
> > There is a problem. Driver could be cross-platform. For example,
> > we have platforms with "CPM1", "CPM2" and "QE" on-chip gpio
> > controllers.
>
> So "platform" isn't exactly the right word. "Hardware-specific"
> is more to the point. You know you're using <Brand-X-SOC-27> and
> that means you must reconfigure <this-way> because <reason>; or
> likewise, <Vendor-Y-ASIC-2> must be reconfigured <that-way> etc.
<this-way> or <that-way> is passed through platform data,
platform code knowns "hardware-specific" details.
> > And despite special _set_dedicated() function, this driver
> > actually does _use_ pins as GPIOs. And as dedicated functions.
> > And as GPIOs. The same pins, but at the different times.
>
> But you're assuming that GPIO identifiers can be used as pin/ball
> identifiers ... and as I pointed out, that's chip-specific.
Heh. I did re-read Documentation/gpio.txt once again, and still don't
get it, where are the differences between GPIOs and Pins? Yes, some
pins can't be GPIOs, but any GPIO must have associated Pin (internal
or external doesn't matter, it's "logical Pin").
For pins that can not be "GPIOs", we can just return errors from
output/input callbacks. Is it violation of the current GPIO API
conventions? Yes, but this is extension that will not break anything,
neither we contradict the "GPIO" term here, btw.
> > {
> > qe_chip = container_of(gpio_to_chip(...), struct qe_chip, chip);
> > ...
>
> You know, you can write all this yourself, without needing any
> support from the GPIO framework whatsoever. The QE stuff that
> registered a gpio_chip interface to its hardware probably keeps
> some records itself, sufficient for such (infrequent) mappings.
Yes, surely. And as I've said already, I do know how to workaround
that, without GPIOLIB support. The thing is that I don't like the
way I'm going to do it.
[...]
> > > Of course, the "function" codes are extremely chip-specific ... and
> > > some platforms would want to include things like pullups, pulldowns,
> > > and so forth as part of pin configuration.
> > >
> > > If you want to pursue this problem, don't couple it to GPIOs.
> >
> > Um... couple it to what then?..
>
> An abstraction of "pin", where pins don't correspond to GPIOs in a
> one-to-one manner.
Keeping in mind that GPIOLIB was brewing a year (?), I think another
GPIOLIB-alike subsystem not worth powder and shot, pins and GPIOs
will be obsolete at that time. :-)
Thanks,
--
Anton Vorontsov
email: cbou@mail.ru
backup email: ya-cbou@yandex.ru
irc://irc.freenode.net/bd2
^ permalink raw reply
* [PATCH] powerpc: kill sparse warnings in kprobes
From: Ananth N Mavinakayanahalli @ 2008-02-15 10:59 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Paul Mackerras, harvey.harrison
From: Ananth N Mavinakayanahalli <ananth@in.ibm.com>
Fix sparse warnings in powerpc kprobes:
CHECK arch/powerpc/kernel/kprobes.c
arch/powerpc/kernel/kprobes.c:277:6: warning: symbol 'kretprobe_trampoline_holder' was not declared. Should it be static?
arch/powerpc/kernel/kprobes.c:287:15: warning: symbol 'trampoline_probe_handler' was not declared. Should it be static?
arch/powerpc/kernel/kprobes.c:525:16: warning: symbol 'jprobe_return_end' was not declared. Should it be static?
Fix along the same lines as http://lkml.org/lkml/2008/2/13/642
Signed-off-by: Ananth N Mavinakayanahalli <ananth@in.ibm.com>
---
arch/powerpc/kernel/kprobes.c | 9 +++++----
1 file changed, 5 insertions(+), 4 deletions(-)
Index: linux-2.6.25-rc1/arch/powerpc/kernel/kprobes.c
===================================================================
--- linux-2.6.25-rc1.orig/arch/powerpc/kernel/kprobes.c
+++ linux-2.6.25-rc1/arch/powerpc/kernel/kprobes.c
@@ -274,7 +274,7 @@ no_kprobe:
* - When the probed function returns, this probe
* causes the handlers to fire
*/
-void kretprobe_trampoline_holder(void)
+static void __used kretprobe_trampoline_holder(void)
{
asm volatile(".global kretprobe_trampoline\n"
"kretprobe_trampoline:\n"
@@ -284,7 +284,8 @@ void kretprobe_trampoline_holder(void)
/*
* Called when the probe at kretprobe trampoline is hit
*/
-int __kprobes trampoline_probe_handler(struct kprobe *p, struct pt_regs *regs)
+static int __kprobes trampoline_probe_handler(struct kprobe *p,
+ struct pt_regs *regs)
{
struct kretprobe_instance *ri = NULL;
struct hlist_head *head, empty_rp;
@@ -517,12 +518,12 @@ int __kprobes setjmp_pre_handler(struct
return 1;
}
-void __kprobes jprobe_return(void)
+void __used __kprobes jprobe_return(void)
{
asm volatile("trap" ::: "memory");
}
-void __kprobes jprobe_return_end(void)
+static void __used __kprobes jprobe_return_end(void)
{
};
^ permalink raw reply
* Linux PPC driver for compact flash
From: Zhong Kui @ 2008-02-15 10:33 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 411 bytes --]
Hi All,
I would like to know where can we get linux IDE driver that uses the UPM
(User Programmable Machine) of the PowerPC (I use the MPC8540) to control a
Compact Flash?
The compact Flash can be probed on true IDE mode on u-boot.
IDE: Bus 0: OK
Device 0:
Model: Firm: Ser#:
Type: Removable Hard Disk
Capacity: 480.1 MB = 0.4 GB (983280 x 512)
Best Regards,
Kui
[-- Attachment #2: Type: text/html, Size: 3115 bytes --]
^ permalink raw reply
* Re: [PATCH] Fix ucc_geth MII master selection
From: Joakim Tjernlund @ 2008-02-15 10:09 UTC (permalink / raw)
To: 'linuxppc-dev Development'
In-Reply-To: <1203009081-10966-1-git-send-email-Joakim.Tjernlund@transmode.se>
On Thu, 2008-02-14 at 18:11 +0100, Joakim Tjernlund wrote:
> Remove bogus UCC regs range test and correct
> off by one error in call to ucc_set_qe_mux_mii_mng()
>
> Signed-off-by: Joakim Tjernlund <Joakim.Tjernlund@transmode.se>
> ---
>
> I am not 100% sure this is the correct fix, please ACK or NACK
>
> drivers/net/ucc_geth_mii.c | 26 +++++++++++---------------
> 1 files changed, 11 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/net/ucc_geth_mii.c b/drivers/net/ucc_geth_mii.c
> index 6c257b8..472d5a1 100644
> --- a/drivers/net/ucc_geth_mii.c
> +++ b/drivers/net/ucc_geth_mii.c
> @@ -200,21 +200,17 @@ static int uec_mdio_probe(struct of_device *ofdev, const struct of_device_id *ma
> if (err)
> goto bus_register_fail;
>
> - /* if our mdio regs fall within this UCC regs range */
> - if ((res.start >= tempres.start) &&
> - (res.end <= tempres.end)) {
> - /* set this UCC to be the MII master */
> - const u32 *id = of_get_property(tempnp, "device-id", NULL);
> - if (id == NULL)
> - goto bus_register_fail;
> -
> - ucc_set_qe_mux_mii_mng(*id - 1);
> -
> - /* assign the TBI an address which won't
> - * conflict with the PHYs */
> - out_be32(®s->utbipar, UTBIPAR_INIT_TBIPA);
> - break;
> - }
> + /* set this UCC to be the MII master */
> + const u32 *id = of_get_property(tempnp, "device-id", NULL);
> + if (id == NULL)
> + goto bus_register_fail;
> +
> + ucc_set_qe_mux_mii_mng(*id);
> +
> + /* assign the TBI an address which won't
> + * conflict with the PHYs */
> + out_be32(®s->utbipar, UTBIPAR_INIT_TBIPA);
> + break;
> }
>
> err = mdiobus_register(new_bus);
This patch is crap, turns out that ucc_set_qe_mux_mii_mng(2) always
works even if UCC3 isn't used at all. I can't figured out why not 1
or 3 works.
Jocke
^ permalink raw reply
* Re: [PATCH 3/8] pseries: phyp dump: use sysfs to release reserved mem
From: Manish Ahuja @ 2008-02-15 7:17 UTC (permalink / raw)
To: Tony Breeds; +Cc: mahuja, linuxppc-dev, linasvepstas, paulus
In-Reply-To: <20080215010528.GI6887@bakeyournoodle.com>
Tony Breeds wrote:
> On Tue, Feb 12, 2008 at 01:11:58AM -0600, Manish Ahuja wrote:
>
> <snip>
>
>> +static ssize_t
>> +show_release_region(struct kset * kset, char *buf)
>> +{
>> + return sprintf(buf, "ola\n");
>> +}
>> +
>> +static struct subsys_attribute rr = __ATTR(release_region, 0600,
>> + show_release_region,
>> + store_release_region);
>
> Any reason this sysfs attribute can't be write only? The show method
> doesn't seem needed.
yes, its used later in the code.
>
>> +static int __init phyp_dump_setup(void)
>> +{
>
> <snip>
>
>> + /* Is there dump data waiting for us? */
>> + rtas = of_find_node_by_path("/rtas");
>> + dump_header = of_get_property(rtas, "ibm,kernel-dump", &header_len);
>
> Hmm this isn't good. You need to check rtas != NULL.
yes, will fix this as well.
>
>> + if (dump_header == NULL) {
>> + release_all();
>> + return 0;
>> + }
>> +
>> + /* Should we create a dump_subsys, analogous to s390/ipl.c ? */
>> + rc = subsys_create_file(&kernel_subsys, &rr);
>> + if (rc) {
>> + printk (KERN_ERR "phyp-dump: unable to create sysfs file (%d)\n", rc);
>> + release_all();
>> + return 0;
>> + }
>>
>> return 0;
>> }
>> -
>> subsys_initcall(phyp_dump_setup);
>
> Hmm I think this really should be a:
> machine_subsys_initcall(pseries, phyp_dump_setup)
>
> Yours Tony
>
> linux.conf.au http://linux.conf.au/ || http://lca2008.linux.org.au/
> Jan 28 - Feb 02 2008 The Australian Linux Technical Conference!
>
^ permalink raw reply
* Re: [PATCH 2/8] pseries: phyp dump: reserve-release proof-of-concept
From: Manish Ahuja @ 2008-02-15 7:16 UTC (permalink / raw)
To: Olof Johansson; +Cc: linuxppc-dev
In-Reply-To: <20080214231200.GA15724@lixom.net>
Olof,
I will run it through checkpatch before resubmitting.
Thanks,
Manish
Olof Johansson wrote:
> On Thu, Feb 14, 2008 at 02:46:21PM +1100, Tony Breeds wrote:
>
>> Hi Manish,
>> Sorry for the minor nits but this should be:
>>
>> ---
>> * Linas Vepstas, Manish Ahuja 2008
>> * Copyright 2008 IBM Corp.
>> ---
>>
>> You can optionally use the '??' symbol after word 'Copyright' but you
>> shouldn't use '(c)' anymore.
>>
>> Also in at least one place you've misspelt "Copyright"
>
> If we're going to nitpick, then I'd like to point out that the whole
> series needs to be run through checkpatch and at least the whitespace
> issues should be taken care of.
>
> I'm still not convinced that this is a useful feature compared to
> hardening kdump, especially now that ehea can handle kexec/kdump (patch
> posted the other day). But in the end it's up to Paul if he wants to
> take it or not, not me.
>
>
> -Olof
^ permalink raw reply
* Re: [PATCH 1/2] fb: add support for foreign endianness
From: Andrew Morton @ 2008-02-15 6:49 UTC (permalink / raw)
To: Anton Vorontsov; +Cc: linuxppc-dev, linux-fbdev-devel, linux-kernel, adaplas
In-Reply-To: <20080205154432.GA8749@localhost.localdomain>
On Tue, 5 Feb 2008 18:44:32 +0300 Anton Vorontsov <avorontsov@ru.mvista.com> wrote:
> This patch adds support for the framebuffers with non-native
> endianness. This is done via FBINFO_FOREIGN_ENDIAN flag that will
> be used by the drivers. Depending on the host endianness this flag
> will be overwritten by FBINFO_BE_MATH internal flag, or cleared.
>
> Tested to work on MPC8360E-RDK (BE) + Fujitsu MINT framebuffer (LE).
That's a pretty large patch to fbdev core, and Tony appears to have gone
offline again and you didn't cc the fbdev mailing list.
I fixed the third problem. Could the other fbdev developers please review
and comment on this?
Thanks.
Actually... should CONFIG_FB_FOREIGN_ENDIAN exist, or should this feature
be permanently enabled?
I'd like to at least queue a patch in -mm so that CONFIG_FB_FOREIGN_ENDIAN
is forced-on, so the code gets some runtime testing. Will that break
anything?
From: Anton Vorontsov <avorontsov@ru.mvista.com>
Add support for the framebuffers with non-native endianness. This is done via
FBINFO_FOREIGN_ENDIAN flag that will be used by the drivers. Depending on the
host endianness this flag will be overwritten by FBINFO_BE_MATH internal flag,
or cleared.
Tested to work on MPC8360E-RDK (BE) + Fujitsu MINT framebuffer (LE).
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
Cc: "Antonino A. Daplas" <adaplas@pol.net>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mackerras <paulus@samba.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
drivers/video/Kconfig | 9 +++++
drivers/video/cfbcopyarea.c | 23 ++++++++-------
drivers/video/cfbfillrect.c | 48 +++++++++++++++++--------------
drivers/video/cfbimgblt.c | 52 +++++++++++++++++-----------------
drivers/video/fb_draw.h | 31 +++++++++++---------
drivers/video/fbmem.c | 8 +++++
drivers/video/syscopyarea.c | 20 ++++++-------
drivers/video/sysfillrect.c | 49 ++++++++++++++++----------------
drivers/video/sysimgblt.c | 47 ++++++++++++++----------------
include/linux/fb.h | 36 +++++++++++++++++------
10 files changed, 183 insertions(+), 140 deletions(-)
diff -puN drivers/video/Kconfig~fb-add-support-for-foreign-endianness drivers/video/Kconfig
--- a/drivers/video/Kconfig~fb-add-support-for-foreign-endianness
+++ a/drivers/video/Kconfig
@@ -139,6 +139,15 @@ config FB_SYS_IMAGEBLIT
blitting. This is used by drivers that don't provide their own
(accelerated) version and the framebuffer is in system RAM.
+config FB_FOREIGN_ENDIAN
+ bool "Enable support for foreign endianness"
+ depends on FB
+ ---help---
+ This option enables support for the framebuffers with non-native
+ endianness (e.g. Little-Endian framebuffer on a Big-Endian machine).
+ You probably don't have such hardware, so in most cases it's safe to
+ say "n" here.
+
config FB_SYS_FOPS
tristate
depends on FB
diff -puN drivers/video/cfbcopyarea.c~fb-add-support-for-foreign-endianness drivers/video/cfbcopyarea.c
--- a/drivers/video/cfbcopyarea.c~fb-add-support-for-foreign-endianness
+++ a/drivers/video/cfbcopyarea.c
@@ -44,15 +44,16 @@
*/
static void
-bitcpy(unsigned long __iomem *dst, int dst_idx, const unsigned long __iomem *src,
- int src_idx, int bits, unsigned n, u32 bswapmask)
+bitcpy(struct fb_info *p, unsigned long __iomem *dst, int dst_idx,
+ const unsigned long __iomem *src, int src_idx, int bits,
+ unsigned n, u32 bswapmask)
{
unsigned long first, last;
int const shift = dst_idx-src_idx;
int left, right;
- first = fb_shifted_pixels_mask_long(dst_idx, bswapmask);
- last = ~fb_shifted_pixels_mask_long((dst_idx+n) % bits, bswapmask);
+ first = fb_shifted_pixels_mask_long(p, dst_idx, bswapmask);
+ last = ~fb_shifted_pixels_mask_long(p, (dst_idx+n) % bits, bswapmask);
if (!shift) {
// Same alignment for source and dest
@@ -202,8 +203,9 @@ bitcpy(unsigned long __iomem *dst, int d
*/
static void
-bitcpy_rev(unsigned long __iomem *dst, int dst_idx, const unsigned long __iomem *src,
- int src_idx, int bits, unsigned n, u32 bswapmask)
+bitcpy_rev(struct fb_info *p, unsigned long __iomem *dst, int dst_idx,
+ const unsigned long __iomem *src, int src_idx, int bits,
+ unsigned n, u32 bswapmask)
{
unsigned long first, last;
int shift;
@@ -221,8 +223,9 @@ bitcpy_rev(unsigned long __iomem *dst, i
shift = dst_idx-src_idx;
- first = fb_shifted_pixels_mask_long(bits - 1 - dst_idx, bswapmask);
- last = ~fb_shifted_pixels_mask_long(bits - 1 - ((dst_idx-n) % bits), bswapmask);
+ first = fb_shifted_pixels_mask_long(p, bits - 1 - dst_idx, bswapmask);
+ last = ~fb_shifted_pixels_mask_long(p, bits - 1 - ((dst_idx-n) % bits),
+ bswapmask);
if (!shift) {
// Same alignment for source and dest
@@ -404,7 +407,7 @@ void cfb_copyarea(struct fb_info *p, con
dst_idx &= (bytes - 1);
src += src_idx >> (ffs(bits) - 1);
src_idx &= (bytes - 1);
- bitcpy_rev(dst, dst_idx, src, src_idx, bits,
+ bitcpy_rev(p, dst, dst_idx, src, src_idx, bits,
width*p->var.bits_per_pixel, bswapmask);
}
} else {
@@ -413,7 +416,7 @@ void cfb_copyarea(struct fb_info *p, con
dst_idx &= (bytes - 1);
src += src_idx >> (ffs(bits) - 1);
src_idx &= (bytes - 1);
- bitcpy(dst, dst_idx, src, src_idx, bits,
+ bitcpy(p, dst, dst_idx, src, src_idx, bits,
width*p->var.bits_per_pixel, bswapmask);
dst_idx += bits_per_line;
src_idx += bits_per_line;
diff -puN drivers/video/cfbfillrect.c~fb-add-support-for-foreign-endianness drivers/video/cfbfillrect.c
--- a/drivers/video/cfbfillrect.c~fb-add-support-for-foreign-endianness
+++ a/drivers/video/cfbfillrect.c
@@ -36,16 +36,16 @@
*/
static void
-bitfill_aligned(unsigned long __iomem *dst, int dst_idx, unsigned long pat,
- unsigned n, int bits, u32 bswapmask)
+bitfill_aligned(struct fb_info *p, unsigned long __iomem *dst, int dst_idx,
+ unsigned long pat, unsigned n, int bits, u32 bswapmask)
{
unsigned long first, last;
if (!n)
return;
- first = fb_shifted_pixels_mask_long(dst_idx, bswapmask);
- last = ~fb_shifted_pixels_mask_long((dst_idx+n) % bits, bswapmask);
+ first = fb_shifted_pixels_mask_long(p, dst_idx, bswapmask);
+ last = ~fb_shifted_pixels_mask_long(p, (dst_idx+n) % bits, bswapmask);
if (dst_idx+n <= bits) {
// Single word
@@ -93,16 +93,16 @@ bitfill_aligned(unsigned long __iomem *d
*/
static void
-bitfill_unaligned(unsigned long __iomem *dst, int dst_idx, unsigned long pat,
- int left, int right, unsigned n, int bits)
+bitfill_unaligned(struct fb_info *p, unsigned long __iomem *dst, int dst_idx,
+ unsigned long pat, int left, int right, unsigned n, int bits)
{
unsigned long first, last;
if (!n)
return;
- first = FB_SHIFT_HIGH(~0UL, dst_idx);
- last = ~(FB_SHIFT_HIGH(~0UL, (dst_idx+n) % bits));
+ first = FB_SHIFT_HIGH(p, ~0UL, dst_idx);
+ last = ~(FB_SHIFT_HIGH(p, ~0UL, (dst_idx+n) % bits));
if (dst_idx+n <= bits) {
// Single word
@@ -147,8 +147,9 @@ bitfill_unaligned(unsigned long __iomem
* Aligned pattern invert using 32/64-bit memory accesses
*/
static void
-bitfill_aligned_rev(unsigned long __iomem *dst, int dst_idx, unsigned long pat,
- unsigned n, int bits, u32 bswapmask)
+bitfill_aligned_rev(struct fb_info *p, unsigned long __iomem *dst,
+ int dst_idx, unsigned long pat, unsigned n, int bits,
+ u32 bswapmask)
{
unsigned long val = pat, dat;
unsigned long first, last;
@@ -156,8 +157,8 @@ bitfill_aligned_rev(unsigned long __iome
if (!n)
return;
- first = fb_shifted_pixels_mask_long(dst_idx, bswapmask);
- last = ~fb_shifted_pixels_mask_long((dst_idx+n) % bits, bswapmask);
+ first = fb_shifted_pixels_mask_long(p, dst_idx, bswapmask);
+ last = ~fb_shifted_pixels_mask_long(p, (dst_idx+n) % bits, bswapmask);
if (dst_idx+n <= bits) {
// Single word
@@ -217,16 +218,17 @@ bitfill_aligned_rev(unsigned long __iome
*/
static void
-bitfill_unaligned_rev(unsigned long __iomem *dst, int dst_idx, unsigned long pat,
- int left, int right, unsigned n, int bits)
+bitfill_unaligned_rev(struct fb_info *p, unsigned long __iomem *dst,
+ int dst_idx, unsigned long pat, int left, int right,
+ unsigned n, int bits)
{
unsigned long first, last, dat;
if (!n)
return;
- first = FB_SHIFT_HIGH(~0UL, dst_idx);
- last = ~(FB_SHIFT_HIGH(~0UL, (dst_idx+n) % bits));
+ first = FB_SHIFT_HIGH(p, ~0UL, dst_idx);
+ last = ~(FB_SHIFT_HIGH(p, ~0UL, (dst_idx+n) % bits));
if (dst_idx+n <= bits) {
// Single word
@@ -306,7 +308,8 @@ void cfb_fillrect(struct fb_info *p, con
p->fbops->fb_sync(p);
if (!left) {
u32 bswapmask = fb_compute_bswapmask(p);
- void (*fill_op32)(unsigned long __iomem *dst, int dst_idx,
+ void (*fill_op32)(struct fb_info *p,
+ unsigned long __iomem *dst, int dst_idx,
unsigned long pat, unsigned n, int bits,
u32 bswapmask) = NULL;
@@ -325,16 +328,17 @@ void cfb_fillrect(struct fb_info *p, con
while (height--) {
dst += dst_idx >> (ffs(bits) - 1);
dst_idx &= (bits - 1);
- fill_op32(dst, dst_idx, pat, width*bpp, bits, bswapmask);
+ fill_op32(p, dst, dst_idx, pat, width*bpp, bits,
+ bswapmask);
dst_idx += p->fix.line_length*8;
}
} else {
int right;
int r;
int rot = (left-dst_idx) % bpp;
- void (*fill_op)(unsigned long __iomem *dst, int dst_idx,
- unsigned long pat, int left, int right,
- unsigned n, int bits) = NULL;
+ void (*fill_op)(struct fb_info *p, unsigned long __iomem *dst,
+ int dst_idx, unsigned long pat, int left,
+ int right, unsigned n, int bits) = NULL;
/* rotate pattern to correct start position */
pat = pat << rot | pat >> (bpp-rot);
@@ -355,7 +359,7 @@ void cfb_fillrect(struct fb_info *p, con
while (height--) {
dst += dst_idx >> (ffs(bits) - 1);
dst_idx &= (bits - 1);
- fill_op(dst, dst_idx, pat, left, right,
+ fill_op(p, dst, dst_idx, pat, left, right,
width*bpp, bits);
r = (p->fix.line_length*8) % bpp;
pat = pat << (bpp-r) | pat >> r;
diff -puN drivers/video/cfbimgblt.c~fb-add-support-for-foreign-endianness drivers/video/cfbimgblt.c
--- a/drivers/video/cfbimgblt.c~fb-add-support-for-foreign-endianness
+++ a/drivers/video/cfbimgblt.c
@@ -43,30 +43,26 @@
#define DPRINTK(fmt, args...)
#endif
-static const u32 cfb_tab8[] = {
-#if defined(__BIG_ENDIAN)
+static const u32 cfb_tab8_be[] = {
0x00000000,0x000000ff,0x0000ff00,0x0000ffff,
0x00ff0000,0x00ff00ff,0x00ffff00,0x00ffffff,
0xff000000,0xff0000ff,0xff00ff00,0xff00ffff,
0xffff0000,0xffff00ff,0xffffff00,0xffffffff
-#elif defined(__LITTLE_ENDIAN)
+};
+
+static const u32 cfb_tab8_le[] = {
0x00000000,0xff000000,0x00ff0000,0xffff0000,
0x0000ff00,0xff00ff00,0x00ffff00,0xffffff00,
0x000000ff,0xff0000ff,0x00ff00ff,0xffff00ff,
0x0000ffff,0xff00ffff,0x00ffffff,0xffffffff
-#else
-#error FIXME: No endianness??
-#endif
};
-static const u32 cfb_tab16[] = {
-#if defined(__BIG_ENDIAN)
+static const u32 cfb_tab16_be[] = {
0x00000000, 0x0000ffff, 0xffff0000, 0xffffffff
-#elif defined(__LITTLE_ENDIAN)
+};
+
+static const u32 cfb_tab16_le[] = {
0x00000000, 0xffff0000, 0x0000ffff, 0xffffffff
-#else
-#error FIXME: No endianness??
-#endif
};
static const u32 cfb_tab32[] = {
@@ -98,7 +94,8 @@ static inline void color_imageblit(const
val = 0;
if (start_index) {
- u32 start_mask = ~fb_shifted_pixels_mask_u32(start_index, bswapmask);
+ u32 start_mask = ~fb_shifted_pixels_mask_u32(p,
+ start_index, bswapmask);
val = FB_READL(dst) & start_mask;
shift = start_index;
}
@@ -108,20 +105,21 @@ static inline void color_imageblit(const
color = palette[*src];
else
color = *src;
- color <<= FB_LEFT_POS(bpp);
- val |= FB_SHIFT_HIGH(color, shift ^ bswapmask);
+ color <<= FB_LEFT_POS(p, bpp);
+ val |= FB_SHIFT_HIGH(p, color, shift ^ bswapmask);
if (shift >= null_bits) {
FB_WRITEL(val, dst++);
val = (shift == null_bits) ? 0 :
- FB_SHIFT_LOW(color, 32 - shift);
+ FB_SHIFT_LOW(p, color, 32 - shift);
}
shift += bpp;
shift &= (32 - 1);
src++;
}
if (shift) {
- u32 end_mask = fb_shifted_pixels_mask_u32(shift, bswapmask);
+ u32 end_mask = fb_shifted_pixels_mask_u32(p, shift,
+ bswapmask);
FB_WRITEL((FB_READL(dst) & end_mask) | val, dst);
}
@@ -152,8 +150,8 @@ static inline void slow_imageblit(const
u32 bswapmask = fb_compute_bswapmask(p);
dst2 = (u32 __iomem *) dst1;
- fgcolor <<= FB_LEFT_POS(bpp);
- bgcolor <<= FB_LEFT_POS(bpp);
+ fgcolor <<= FB_LEFT_POS(p, bpp);
+ bgcolor <<= FB_LEFT_POS(p, bpp);
for (i = image->height; i--; ) {
shift = val = 0;
@@ -164,7 +162,8 @@ static inline void slow_imageblit(const
/* write leading bits */
if (start_index) {
- u32 start_mask = ~fb_shifted_pixels_mask_u32(start_index, bswapmask);
+ u32 start_mask = ~fb_shifted_pixels_mask_u32(p,
+ start_index, bswapmask);
val = FB_READL(dst) & start_mask;
shift = start_index;
}
@@ -172,13 +171,13 @@ static inline void slow_imageblit(const
while (j--) {
l--;
color = (*s & (1 << l)) ? fgcolor : bgcolor;
- val |= FB_SHIFT_HIGH(color, shift ^ bswapmask);
+ val |= FB_SHIFT_HIGH(p, color, shift ^ bswapmask);
/* Did the bitshift spill bits to the next long? */
if (shift >= null_bits) {
FB_WRITEL(val, dst++);
val = (shift == null_bits) ? 0 :
- FB_SHIFT_LOW(color,32 - shift);
+ FB_SHIFT_LOW(p, color, 32 - shift);
}
shift += bpp;
shift &= (32 - 1);
@@ -187,7 +186,8 @@ static inline void slow_imageblit(const
/* write trailing bits */
if (shift) {
- u32 end_mask = fb_shifted_pixels_mask_u32(shift, bswapmask);
+ u32 end_mask = fb_shifted_pixels_mask_u32(p, shift,
+ bswapmask);
FB_WRITEL((FB_READL(dst) & end_mask) | val, dst);
}
@@ -223,13 +223,13 @@ static inline void fast_imageblit(const
u32 __iomem *dst;
const u32 *tab = NULL;
int i, j, k;
-
+
switch (bpp) {
case 8:
- tab = cfb_tab8;
+ tab = fb_be_math(p) ? cfb_tab8_be : cfb_tab8_le;
break;
case 16:
- tab = cfb_tab16;
+ tab = fb_be_math(p) ? cfb_tab16_be : cfb_tab16_le;
break;
case 32:
default:
diff -puN drivers/video/fb_draw.h~fb-add-support-for-foreign-endianness drivers/video/fb_draw.h
--- a/drivers/video/fb_draw.h~fb-add-support-for-foreign-endianness
+++ a/drivers/video/fb_draw.h
@@ -94,41 +94,44 @@ static inline unsigned long fb_rev_pixel
return val;
}
-static inline u32 fb_shifted_pixels_mask_u32(u32 index, u32 bswapmask)
+static inline u32 fb_shifted_pixels_mask_u32(struct fb_info *p, u32 index,
+ u32 bswapmask)
{
u32 mask;
if (!bswapmask) {
- mask = FB_SHIFT_HIGH(~(u32)0, index);
+ mask = FB_SHIFT_HIGH(p, ~(u32)0, index);
} else {
- mask = 0xff << FB_LEFT_POS(8);
- mask = FB_SHIFT_LOW(mask, index & (bswapmask)) & mask;
- mask = FB_SHIFT_HIGH(mask, index & ~(bswapmask));
+ mask = 0xff << FB_LEFT_POS(p, 8);
+ mask = FB_SHIFT_LOW(p, mask, index & (bswapmask)) & mask;
+ mask = FB_SHIFT_HIGH(p, mask, index & ~(bswapmask));
#if defined(__i386__) || defined(__x86_64__)
/* Shift argument is limited to 0 - 31 on x86 based CPU's */
if(index + bswapmask < 32)
#endif
- mask |= FB_SHIFT_HIGH(~(u32)0,
+ mask |= FB_SHIFT_HIGH(p, ~(u32)0,
(index + bswapmask) & ~(bswapmask));
}
return mask;
}
-static inline unsigned long fb_shifted_pixels_mask_long(u32 index, u32 bswapmask)
+static inline unsigned long fb_shifted_pixels_mask_long(struct fb_info *p,
+ u32 index,
+ u32 bswapmask)
{
unsigned long mask;
if (!bswapmask) {
- mask = FB_SHIFT_HIGH(~0UL, index);
+ mask = FB_SHIFT_HIGH(p, ~0UL, index);
} else {
- mask = 0xff << FB_LEFT_POS(8);
- mask = FB_SHIFT_LOW(mask, index & (bswapmask)) & mask;
- mask = FB_SHIFT_HIGH(mask, index & ~(bswapmask));
+ mask = 0xff << FB_LEFT_POS(p, 8);
+ mask = FB_SHIFT_LOW(p, mask, index & (bswapmask)) & mask;
+ mask = FB_SHIFT_HIGH(p, mask, index & ~(bswapmask));
#if defined(__i386__) || defined(__x86_64__)
/* Shift argument is limited to 0 - 31 on x86 based CPU's */
if(index + bswapmask < BITS_PER_LONG)
#endif
- mask |= FB_SHIFT_HIGH(~0UL,
+ mask |= FB_SHIFT_HIGH(p, ~0UL,
(index + bswapmask) & ~(bswapmask));
}
return mask;
@@ -158,8 +161,8 @@ static inline unsigned long fb_rev_pixel
return val;
}
-#define fb_shifted_pixels_mask_u32(i, b) FB_SHIFT_HIGH(~(u32)0, (i))
-#define fb_shifted_pixels_mask_long(i, b) FB_SHIFT_HIGH(~0UL, (i))
+#define fb_shifted_pixels_mask_u32(p, i, b) FB_SHIFT_HIGH((p), ~(u32)0, (i))
+#define fb_shifted_pixels_mask_long(p, i, b) FB_SHIFT_HIGH((p), ~0UL, (i))
#define fb_compute_bswapmask(...) 0
#endif /* CONFIG_FB_CFB_REV_PIXELS_IN_BYTE */
diff -puN drivers/video/fbmem.c~fb-add-support-for-foreign-endianness drivers/video/fbmem.c
--- a/drivers/video/fbmem.c~fb-add-support-for-foreign-endianness
+++ a/drivers/video/fbmem.c
@@ -1368,6 +1368,7 @@ register_framebuffer(struct fb_info *fb_
int i;
struct fb_event event;
struct fb_videomode mode;
+ const bool foreign_endian = fb_info->flags & FBINFO_FOREIGN_ENDIAN;
if (num_registered_fb == FB_MAX)
return -ENXIO;
@@ -1404,6 +1405,13 @@ register_framebuffer(struct fb_info *fb_
if (!fb_info->pixmap.blit_y)
fb_info->pixmap.blit_y = ~(u32)0;
+ fb_info->flags &= ~FBINFO_FOREIGN_ENDIAN;
+#ifdef __BIG_ENDIAN
+ fb_info->flags |= foreign_endian ? 0 : FBINFO_BE_MATH;
+#else
+ fb_info->flags |= foreign_endian ? FBINFO_BE_MATH : 0;
+#endif
+
if (!fb_info->modelist.prev || !fb_info->modelist.next)
INIT_LIST_HEAD(&fb_info->modelist);
diff -puN drivers/video/syscopyarea.c~fb-add-support-for-foreign-endianness drivers/video/syscopyarea.c
--- a/drivers/video/syscopyarea.c~fb-add-support-for-foreign-endianness
+++ a/drivers/video/syscopyarea.c
@@ -26,15 +26,15 @@
*/
static void
-bitcpy(unsigned long *dst, int dst_idx, const unsigned long *src,
- int src_idx, int bits, unsigned n)
+bitcpy(struct fb_info *p, unsigned long *dst, int dst_idx,
+ const unsigned long *src, int src_idx, int bits, unsigned n)
{
unsigned long first, last;
int const shift = dst_idx-src_idx;
int left, right;
- first = FB_SHIFT_HIGH(~0UL, dst_idx);
- last = ~(FB_SHIFT_HIGH(~0UL, (dst_idx+n) % bits));
+ first = FB_SHIFT_HIGH(p, ~0UL, dst_idx);
+ last = ~(FB_SHIFT_HIGH(p, ~0UL, (dst_idx+n) % bits));
if (!shift) {
/* Same alignment for source and dest */
@@ -167,8 +167,8 @@ bitcpy(unsigned long *dst, int dst_idx,
*/
static void
-bitcpy_rev(unsigned long *dst, int dst_idx, const unsigned long *src,
- int src_idx, int bits, unsigned n)
+bitcpy_rev(struct fb_info *p, unsigned long *dst, int dst_idx,
+ const unsigned long *src, int src_idx, int bits, unsigned n)
{
unsigned long first, last;
int shift;
@@ -186,8 +186,8 @@ bitcpy_rev(unsigned long *dst, int dst_i
shift = dst_idx-src_idx;
- first = FB_SHIFT_LOW(~0UL, bits - 1 - dst_idx);
- last = ~(FB_SHIFT_LOW(~0UL, bits - 1 - ((dst_idx-n) % bits)));
+ first = FB_SHIFT_LOW(p, ~0UL, bits - 1 - dst_idx);
+ last = ~(FB_SHIFT_LOW(p, ~0UL, bits - 1 - ((dst_idx-n) % bits)));
if (!shift) {
/* Same alignment for source and dest */
@@ -353,7 +353,7 @@ void sys_copyarea(struct fb_info *p, con
dst_idx &= (bytes - 1);
src += src_idx >> (ffs(bits) - 1);
src_idx &= (bytes - 1);
- bitcpy_rev(dst, dst_idx, src, src_idx, bits,
+ bitcpy_rev(p, dst, dst_idx, src, src_idx, bits,
width*p->var.bits_per_pixel);
}
} else {
@@ -362,7 +362,7 @@ void sys_copyarea(struct fb_info *p, con
dst_idx &= (bytes - 1);
src += src_idx >> (ffs(bits) - 1);
src_idx &= (bytes - 1);
- bitcpy(dst, dst_idx, src, src_idx, bits,
+ bitcpy(p, dst, dst_idx, src, src_idx, bits,
width*p->var.bits_per_pixel);
dst_idx += bits_per_line;
src_idx += bits_per_line;
diff -puN drivers/video/sysfillrect.c~fb-add-support-for-foreign-endianness drivers/video/sysfillrect.c
--- a/drivers/video/sysfillrect.c~fb-add-support-for-foreign-endianness
+++ a/drivers/video/sysfillrect.c
@@ -22,16 +22,16 @@
*/
static void
-bitfill_aligned(unsigned long *dst, int dst_idx, unsigned long pat,
- unsigned n, int bits)
+bitfill_aligned(struct fb_info *p, unsigned long *dst, int dst_idx,
+ unsigned long pat, unsigned n, int bits)
{
unsigned long first, last;
if (!n)
return;
- first = FB_SHIFT_HIGH(~0UL, dst_idx);
- last = ~(FB_SHIFT_HIGH(~0UL, (dst_idx+n) % bits));
+ first = FB_SHIFT_HIGH(p, ~0UL, dst_idx);
+ last = ~(FB_SHIFT_HIGH(p, ~0UL, (dst_idx+n) % bits));
if (dst_idx+n <= bits) {
/* Single word */
@@ -78,16 +78,16 @@ bitfill_aligned(unsigned long *dst, int
*/
static void
-bitfill_unaligned(unsigned long *dst, int dst_idx, unsigned long pat,
- int left, int right, unsigned n, int bits)
+bitfill_unaligned(struct fb_info *p, unsigned long *dst, int dst_idx,
+ unsigned long pat, int left, int right, unsigned n, int bits)
{
unsigned long first, last;
if (!n)
return;
- first = FB_SHIFT_HIGH(~0UL, dst_idx);
- last = ~(FB_SHIFT_HIGH(~0UL, (dst_idx+n) % bits));
+ first = FB_SHIFT_HIGH(p, ~0UL, dst_idx);
+ last = ~(FB_SHIFT_HIGH(p, ~0UL, (dst_idx+n) % bits));
if (dst_idx+n <= bits) {
/* Single word */
@@ -132,8 +132,8 @@ bitfill_unaligned(unsigned long *dst, in
* Aligned pattern invert using 32/64-bit memory accesses
*/
static void
-bitfill_aligned_rev(unsigned long *dst, int dst_idx, unsigned long pat,
- unsigned n, int bits)
+bitfill_aligned_rev(struct fb_info *p, unsigned long *dst, int dst_idx,
+ unsigned long pat, unsigned n, int bits)
{
unsigned long val = pat;
unsigned long first, last;
@@ -141,8 +141,8 @@ bitfill_aligned_rev(unsigned long *dst,
if (!n)
return;
- first = FB_SHIFT_HIGH(~0UL, dst_idx);
- last = ~(FB_SHIFT_HIGH(~0UL, (dst_idx+n) % bits));
+ first = FB_SHIFT_HIGH(p, ~0UL, dst_idx);
+ last = ~(FB_SHIFT_HIGH(p, ~0UL, (dst_idx+n) % bits));
if (dst_idx+n <= bits) {
/* Single word */
@@ -188,16 +188,17 @@ bitfill_aligned_rev(unsigned long *dst,
*/
static void
-bitfill_unaligned_rev(unsigned long *dst, int dst_idx, unsigned long pat,
- int left, int right, unsigned n, int bits)
+bitfill_unaligned_rev(struct fb_info *p, unsigned long *dst, int dst_idx,
+ unsigned long pat, int left, int right, unsigned n,
+ int bits)
{
unsigned long first, last;
if (!n)
return;
- first = FB_SHIFT_HIGH(~0UL, dst_idx);
- last = ~(FB_SHIFT_HIGH(~0UL, (dst_idx+n) % bits));
+ first = FB_SHIFT_HIGH(p, ~0UL, dst_idx);
+ last = ~(FB_SHIFT_HIGH(p, ~0UL, (dst_idx+n) % bits));
if (dst_idx+n <= bits) {
/* Single word */
@@ -267,9 +268,9 @@ void sys_fillrect(struct fb_info *p, con
if (p->fbops->fb_sync)
p->fbops->fb_sync(p);
if (!left) {
- void (*fill_op32)(unsigned long *dst, int dst_idx,
- unsigned long pat, unsigned n, int bits) =
- NULL;
+ void (*fill_op32)(struct fb_info *p, unsigned long *dst,
+ int dst_idx, unsigned long pat, unsigned n,
+ int bits) = NULL;
switch (rect->rop) {
case ROP_XOR:
@@ -287,16 +288,16 @@ void sys_fillrect(struct fb_info *p, con
while (height--) {
dst += dst_idx >> (ffs(bits) - 1);
dst_idx &= (bits - 1);
- fill_op32(dst, dst_idx, pat, width*bpp, bits);
+ fill_op32(p, dst, dst_idx, pat, width*bpp, bits);
dst_idx += p->fix.line_length*8;
}
} else {
int right;
int r;
int rot = (left-dst_idx) % bpp;
- void (*fill_op)(unsigned long *dst, int dst_idx,
- unsigned long pat, int left, int right,
- unsigned n, int bits) = NULL;
+ void (*fill_op)(struct fb_info *p, unsigned long *dst,
+ int dst_idx, unsigned long pat, int left,
+ int right, unsigned n, int bits) = NULL;
/* rotate pattern to correct start position */
pat = pat << rot | pat >> (bpp-rot);
@@ -318,7 +319,7 @@ void sys_fillrect(struct fb_info *p, con
while (height--) {
dst += dst_idx >> (ffs(bits) - 1);
dst_idx &= (bits - 1);
- fill_op(dst, dst_idx, pat, left, right,
+ fill_op(p, dst, dst_idx, pat, left, right,
width*bpp, bits);
r = (p->fix.line_length*8) % bpp;
pat = pat << (bpp-r) | pat >> r;
diff -puN drivers/video/sysimgblt.c~fb-add-support-for-foreign-endianness drivers/video/sysimgblt.c
--- a/drivers/video/sysimgblt.c~fb-add-support-for-foreign-endianness
+++ a/drivers/video/sysimgblt.c
@@ -23,30 +23,26 @@
#define DPRINTK(fmt, args...)
#endif
-static const u32 cfb_tab8[] = {
-#if defined(__BIG_ENDIAN)
+static const u32 cfb_tab8_be[] = {
0x00000000,0x000000ff,0x0000ff00,0x0000ffff,
0x00ff0000,0x00ff00ff,0x00ffff00,0x00ffffff,
0xff000000,0xff0000ff,0xff00ff00,0xff00ffff,
0xffff0000,0xffff00ff,0xffffff00,0xffffffff
-#elif defined(__LITTLE_ENDIAN)
+};
+
+static const u32 cfb_tab8_le[] = {
0x00000000,0xff000000,0x00ff0000,0xffff0000,
0x0000ff00,0xff00ff00,0x00ffff00,0xffffff00,
0x000000ff,0xff0000ff,0x00ff00ff,0xffff00ff,
0x0000ffff,0xff00ffff,0x00ffffff,0xffffffff
-#else
-#error FIXME: No endianness??
-#endif
};
-static const u32 cfb_tab16[] = {
-#if defined(__BIG_ENDIAN)
+static const u32 cfb_tab16_be[] = {
0x00000000, 0x0000ffff, 0xffff0000, 0xffffffff
-#elif defined(__LITTLE_ENDIAN)
+};
+
+static const u32 cfb_tab16_le[] = {
0x00000000, 0xffff0000, 0x0000ffff, 0xffffffff
-#else
-#error FIXME: No endianness??
-#endif
};
static const u32 cfb_tab32[] = {
@@ -72,7 +68,7 @@ static void color_imageblit(const struct
val = 0;
if (start_index) {
- u32 start_mask = ~(FB_SHIFT_HIGH(~(u32)0,
+ u32 start_mask = ~(FB_SHIFT_HIGH(p, ~(u32)0,
start_index));
val = *dst & start_mask;
shift = start_index;
@@ -83,20 +79,20 @@ static void color_imageblit(const struct
color = palette[*src];
else
color = *src;
- color <<= FB_LEFT_POS(bpp);
- val |= FB_SHIFT_HIGH(color, shift);
+ color <<= FB_LEFT_POS(p, bpp);
+ val |= FB_SHIFT_HIGH(p, color, shift);
if (shift >= null_bits) {
*dst++ = val;
val = (shift == null_bits) ? 0 :
- FB_SHIFT_LOW(color, 32 - shift);
+ FB_SHIFT_LOW(p, color, 32 - shift);
}
shift += bpp;
shift &= (32 - 1);
src++;
}
if (shift) {
- u32 end_mask = FB_SHIFT_HIGH(~(u32)0, shift);
+ u32 end_mask = FB_SHIFT_HIGH(p, ~(u32)0, shift);
*dst &= end_mask;
*dst |= val;
@@ -125,8 +121,8 @@ static void slow_imageblit(const struct
u32 i, j, l;
dst2 = dst1;
- fgcolor <<= FB_LEFT_POS(bpp);
- bgcolor <<= FB_LEFT_POS(bpp);
+ fgcolor <<= FB_LEFT_POS(p, bpp);
+ bgcolor <<= FB_LEFT_POS(p, bpp);
for (i = image->height; i--; ) {
shift = val = 0;
@@ -137,7 +133,8 @@ static void slow_imageblit(const struct
/* write leading bits */
if (start_index) {
- u32 start_mask = ~(FB_SHIFT_HIGH(~(u32)0,start_index));
+ u32 start_mask = ~(FB_SHIFT_HIGH(p, ~(u32)0,
+ start_index));
val = *dst & start_mask;
shift = start_index;
}
@@ -145,13 +142,13 @@ static void slow_imageblit(const struct
while (j--) {
l--;
color = (*s & (1 << l)) ? fgcolor : bgcolor;
- val |= FB_SHIFT_HIGH(color, shift);
+ val |= FB_SHIFT_HIGH(p, color, shift);
/* Did the bitshift spill bits to the next long? */
if (shift >= null_bits) {
*dst++ = val;
val = (shift == null_bits) ? 0 :
- FB_SHIFT_LOW(color,32 - shift);
+ FB_SHIFT_LOW(p, color, 32 - shift);
}
shift += bpp;
shift &= (32 - 1);
@@ -160,7 +157,7 @@ static void slow_imageblit(const struct
/* write trailing bits */
if (shift) {
- u32 end_mask = FB_SHIFT_HIGH(~(u32)0, shift);
+ u32 end_mask = FB_SHIFT_HIGH(p, ~(u32)0, shift);
*dst &= end_mask;
*dst |= val;
@@ -199,10 +196,10 @@ static void fast_imageblit(const struct
switch (bpp) {
case 8:
- tab = cfb_tab8;
+ tab = fb_be_math(p) ? cfb_tab8_be : cfb_tab8_le;
break;
case 16:
- tab = cfb_tab16;
+ tab = fb_be_math(p) ? cfb_tab16_be : cfb_tab16_le;
break;
case 32:
default:
diff -puN include/linux/fb.h~fb-add-support-for-foreign-endianness include/linux/fb.h
--- a/include/linux/fb.h~fb-add-support-for-foreign-endianness
+++ a/include/linux/fb.h
@@ -791,6 +791,17 @@ struct fb_tile_ops {
*/
#define FBINFO_MISC_ALWAYS_SETPAR 0x40000
+/*
+ * Host and GPU endianness differ.
+ */
+#define FBINFO_FOREIGN_ENDIAN 0x100000
+/*
+ * Big endian math. This is the same flags as above, but with different
+ * meaning, it is set by the fb subsystem depending FOREIGN_ENDIAN flag
+ * and host endianness. Drivers should not use this flag.
+ */
+#define FBINFO_BE_MATH 0x100000
+
struct fb_info {
int node;
int flags;
@@ -899,15 +910,11 @@ struct fb_info {
#endif
-#if defined (__BIG_ENDIAN)
-#define FB_LEFT_POS(bpp) (32 - bpp)
-#define FB_SHIFT_HIGH(val, bits) ((val) >> (bits))
-#define FB_SHIFT_LOW(val, bits) ((val) << (bits))
-#else
-#define FB_LEFT_POS(bpp) (0)
-#define FB_SHIFT_HIGH(val, bits) ((val) << (bits))
-#define FB_SHIFT_LOW(val, bits) ((val) >> (bits))
-#endif
+#define FB_LEFT_POS(p, bpp) (fb_be_math(p) ? (32 - (bpp)) : 0)
+#define FB_SHIFT_HIGH(p, val, bits) (fb_be_math(p) ? (val) >> (bits) : \
+ (val) << (bits))
+#define FB_SHIFT_LOW(p, val, bits) (fb_be_math(p) ? (val) << (bits) : \
+ (val) >> (bits))
/*
* `Generic' versions of the frame buffer device operations
@@ -970,6 +977,17 @@ extern void fb_deferred_io_cleanup(struc
extern int fb_deferred_io_fsync(struct file *file, struct dentry *dentry,
int datasync);
+static inline bool fb_be_math(struct fb_info *info)
+{
+#if defined(CONFIG_FB_FOREIGN_ENDIAN)
+ return info->flags & FBINFO_BE_MATH;
+#elif defined(__BIG_ENDIAN)
+ return true;
+#else
+ return false;
+#endif
+}
+
/* drivers/video/fbsysfs.c */
extern struct fb_info *framebuffer_alloc(size_t size, struct device *dev);
extern void framebuffer_release(struct fb_info *info);
_
^ permalink raw reply
* Re: [PATCH 04/11] [RFC][GPIOLIB] add gpio_set_dedicated() routine
From: David Brownell @ 2008-02-15 4:36 UTC (permalink / raw)
To: cbouatmailru; +Cc: linuxppc-dev
In-Reply-To: <20080203233220.GA20105@zarina>
On Sunday 03 February 2008, Anton Vorontsov wrote:
> On Sun, Feb 03, 2008 at 01:22:08PM -0800, David Brownell wrote:
> [...]
>
> > So when you assume that a GPIO number can uniquely specify a pin for
> > use in function multiplexing ... you're stressing a "nonportable"
> > aspect of this issue.
> >
> > Ditto when you assume that the multiplexing is on a per-pin basis,
> > rather than affecting a defined group of pins. (More common, and
> > less annoying, than the OMAP1 issue.)
> >
> > (And that doesn't even touch issues like configurable drive strength,
> > pullups, pulldowns, and so on.)
>
> This is all true, of course.
And a related truism: with at best rare exceptions, those things
get set up once at board setup and don't change later. So the
audience for reconfiguring pins is quite limited ... basically
it'd all be for code which is already hardware-specific.
That's much less true of GPIOs. It really *is* practical to have
generic GPIO based drivers for LEDs, keypad buttons, bitbanged
I2C, 1-wire, SPI ... etc.
> > > Imagine some
> > > GPIO controller that can't do inputs, or outputs. First one will be
> > > still suitable for gpio_leds, second one will be suitable for gpio_keys.
> >
> > The interface easily handles input-only and output-only GPIOs.
> > Make the relevant gpio_direction_*() methods fail those requests.
>
> The point was: GPIOs could be "input only" but you still have
> "output" callback, and that doesn't troubles anybody. Not sure
> why set_dedicated() such a big issue then, it could fail too! :-)
See above: you're equating pin and gpio ... and while GPIOs
have (by definition) standardized boolean input and output
functionality, the rest of what can be done with a pin isn't.
> We're talking about General Purpose IOs, right? They're general
> enough to support not only input/output stuff. And we want some
> API for these General Purpose IOs. GPIO LIB is the best candidate
> and we can implement such API at almost no cost, few lines of code.
GPIOs are not intended to be a kitchen sink though; and that's
the sense in which you seem to mean "best candidate": it's a
clean lightweight interface, not gummed up with all kinds of
unrelated stuff.
Take your ideas and use them to create a pin configuration
interface. On some platforms, configurable pins will map
onto GPIOs, one-to-one. On others, there will be configurable
pins that aren't GPIOs ... GPIOs that can be mapped to any of
several pins ... pins that can be used with several GPIOs ...
pins that can only be used with GPIOs ... and so on.
> He-he. Actually, I have a patch that adds "to_irq" callback
> to GPIO LIB. :-) But I just didn't find time yet to cleanup
> the "user" of that addition (ARM-based "samcop" companion chip).
>
> Briefly: gpio<->irq mapping there isn't "flat". It is messed
> all around. GPIO 1 is IRQ 12, GPIO 2 if IRQ 45 and so on... no
> common pattern. So, to support gpio_to_irq() we have to either:
>
> 1. change the mappings of the IRQs, to match GPIOs.
> or
> 2. implement to_irq() callback (way easier).
That seems like maybe a reasonable thing to add to gpiolib.
It's fully within the current scope of the GPIO interface.
Show it when you've got a cleaned up version...
And although the original notion was that those mappings
cost on the order of an addition, I think that's not a big
deal ... except maybe sometimes for irq_to_gpio().
> > > So, down below is the proposal patch: gpio_set_dedicated() routine.
> > >
> > > There are other options, tough. But I don't like them:
> > >
> > > ...
> > >
> > > - Another option?
> >
> > The way it's usually done: platform-specific code to handle those
> > platform-specific pin configuration issues.
>
> There is a problem. Driver could be cross-platform. For example,
> we have platforms with "CPM1", "CPM2" and "QE" on-chip gpio
> controllers.
So "platform" isn't exactly the right word. "Hardware-specific"
is more to the point. You know you're using <Brand-X-SOC-27> and
that means you must reconfigure <this-way> because <reason>; or
likewise, <Vendor-Y-ASIC-2> must be reconfigured <that-way> etc.
> And despite special _set_dedicated() function, this driver
> actually does _use_ pins as GPIOs. And as dedicated functions.
> And as GPIOs. The same pins, but at the different times.
But you're assuming that GPIO identifiers can be used as pin/ball
identifiers ... and as I pointed out, that's chip-specific.
> Will you agree to export "chips" so we can write
> GPIO LIB "platform extensions", like
>
> qe_set_dedicated(unsigned int value_that_we_got_from_gpio_request)
gpio_request() returns zero-or-negative-errno. Never unsigned int. ;)
> {
> qe_chip = container_of(gpio_to_chip(...), struct qe_chip, chip);
> ...
You know, you can write all this yourself, without needing any
support from the GPIO framework whatsoever. The QE stuff that
registered a gpio_chip interface to its hardware probably keeps
some records itself, sufficient for such (infrequent) mappings.
> > > +int gpio_set_dedicated(unsigned gpio, int func)
> >
> > It's not required that a pin/ball identifier have a one-to-one mapping
> > to "gpio" numbers, or that all pins/balls have "gpio" as one of the
> > possible functions. So if there were a cross-platform call like this,
> > I'd want to see such it reference not a "gpio" but a "pin".
> >
> > And for that matter, "dedicated" is inaccurate.
>
> ... deletia ...
>
> > Of course, the "function" codes are extremely chip-specific ... and
> > some platforms would want to include things like pullups, pulldowns,
> > and so forth as part of pin configuration.
> >
> > If you want to pursue this problem, don't couple it to GPIOs.
>
> Um... couple it to what then?..
An abstraction of "pin", where pins don't correspond to GPIOs in a
one-to-one manner.
- dave
^ permalink raw reply
* a question on an error of building 2.6.24.2
From: Jingyu Liu @ 2008-02-15 4:19 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 874 bytes --]
Hi there,
I am using a cross-compiler gcc 4.1.2 and glibc 2.3.6 to build 2.6.24.2 for
a adder875 board. At the end of building, the ld gives the following error
messages:
LD init/built-in.o
LD vmlinux
`.exit.data' referenced in section `.exit.text' of drivers/built-in.o:
defined in discarded section `.exit.data' of drivers/built-in.o
`.exit.data' referenced in section `.exit.text' of drivers/built-in.o:
defined in discarded section `.exit.data' of drivers/built-in.o
`.exit.data' referenced in section `.exit.text' of drivers/built-in.o:
defined in discarded section `.exit.data' of drivers/built-in.o
`.exit.data' referenced in section `.exit.text' of drivers/built-in.o:
defined in discarded section `.exit.data' of drivers/built-in.o
make: *** [vmlinux] Error 1
.config file is also attached.
Is it gcc problem, or something else?
Thanks.
Jingyu
[-- Attachment #2: Type: text/html, Size: 1129 bytes --]
^ permalink raw reply
* dtc: Fold comment handling test into testsuite
From: David Gibson @ 2008-02-15 4:14 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev
For ages dtc has included a sample dts, comment-test.dts, for checking
various lexical corner cases in comment processing. In fact, it
predates the automated testsuite, and has never been integrated into
it. This patch addresses this oversight, folding the comment handling
test in with the rest of the testsuite.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Index: dtc/comment-test.dts
===================================================================
--- dtc.orig/comment-test.dts 2008-02-15 15:01:06.000000000 +1100
+++ /dev/null 1970-01-01 00:00:00.000000000 +0000
@@ -1,38 +0,0 @@
-/* regexps for lexing comments are.. tricky. Check if we've actually
- * got it right */
-
-/ {
- // line comment
- prop1;
- /* comment */
- prop2;
- /* multiline
-
- notaprop1;
-
- comment */
- prop3;
- /**/
- prop4;
- /***/
- prop5;
- /****/
- prop6;
- /* another
- * multiline
- * comment */
- prop7;
- /* yet
- * another
- * multline
- * comment
- */
- prop8;
- /** try this */
- prop9;
- /* and this **/
- prop10;
- child /* finally */ {
- };
-};
-/* final comment */
Index: dtc/tests/comments.dts
===================================================================
--- /dev/null 1970-01-01 00:00:00.000000000 +0000
+++ dtc/tests/comments.dts 2008-02-15 15:05:50.000000000 +1100
@@ -0,0 +1,39 @@
+/* regexps for lexing comments are.. tricky. Check if we've actually
+ * got it right */
+/dts-v1/;
+
+/ {
+ // line comment
+ prop1;
+ /* comment */
+ prop2;
+ /* multiline
+
+ notaprop1;
+
+ comment */
+ prop3;
+ /**/
+ prop4;
+ /***/
+ prop5;
+ /****/
+ prop6;
+ /* another
+ * multiline
+ * comment */
+ prop7;
+ /* yet
+ * another
+ * multline
+ * comment
+ */
+ prop8;
+ /** try this */
+ prop9;
+ /* and this **/
+ prop10;
+ child /* finally */ {
+ };
+};
+/* final comment */
Index: dtc/tests/run_tests.sh
===================================================================
--- dtc.orig/tests/run_tests.sh 2008-02-15 15:01:20.000000000 +1100
+++ dtc/tests/run_tests.sh 2008-02-15 15:08:09.000000000 +1100
@@ -155,6 +155,10 @@ dtc_tests () {
run_test dtc.sh -I dts -O dtb -o dtc_path-references.test.dtb path-references.dts
run_test path-references dtc_path-references.test.dtb
+ run_test dtc.sh -I dts -O dtb -o dtc_comments.test.dtb comments.dts
+ run_test dtc.sh -I dts -O dtb -o dtc_comments-cmp.test.dtb comments-cmp.dts
+ run_test dtbs_equal_ordered dtc_comments.test.dtb dtc_comments-cmp.test.dtb
+
# Check -Odts mode preserve all dtb information
for tree in test_tree1.dtb dtc_tree1.test.dtb dtc_escapes.test.dtb ; do
run_test dtc.sh -I dtb -O dts -o odts_$tree.test.dts $tree
Index: dtc/tests/comments-cmp.dts
===================================================================
--- /dev/null 1970-01-01 00:00:00.000000000 +0000
+++ dtc/tests/comments-cmp.dts 2008-02-15 15:07:04.000000000 +1100
@@ -0,0 +1,16 @@
+/dts-v1/;
+
+/ {
+ prop1;
+ prop2;
+ prop3;
+ prop4;
+ prop5;
+ prop6;
+ prop7;
+ prop8;
+ prop9;
+ prop10;
+ child {
+ };
+};
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: [PATCH 3/8] pseries: phyp dump: use sysfs to release reserved mem
From: Tony Breeds @ 2008-02-15 1:05 UTC (permalink / raw)
To: Manish Ahuja; +Cc: mahuja, linuxppc-dev, linasvepstas, paulus
In-Reply-To: <47B146BE.5010807@austin.ibm.com>
On Tue, Feb 12, 2008 at 01:11:58AM -0600, Manish Ahuja wrote:
<snip>
> +static ssize_t
> +show_release_region(struct kset * kset, char *buf)
> +{
> + return sprintf(buf, "ola\n");
> +}
> +
> +static struct subsys_attribute rr = __ATTR(release_region, 0600,
> + show_release_region,
> + store_release_region);
Any reason this sysfs attribute can't be write only? The show method
doesn't seem needed.
> +static int __init phyp_dump_setup(void)
> +{
<snip>
> + /* Is there dump data waiting for us? */
> + rtas = of_find_node_by_path("/rtas");
> + dump_header = of_get_property(rtas, "ibm,kernel-dump", &header_len);
Hmm this isn't good. You need to check rtas != NULL.
> + if (dump_header == NULL) {
> + release_all();
> + return 0;
> + }
> +
> + /* Should we create a dump_subsys, analogous to s390/ipl.c ? */
> + rc = subsys_create_file(&kernel_subsys, &rr);
> + if (rc) {
> + printk (KERN_ERR "phyp-dump: unable to create sysfs file (%d)\n", rc);
> + release_all();
> + return 0;
> + }
>
> return 0;
> }
> -
> subsys_initcall(phyp_dump_setup);
Hmm I think this really should be a:
machine_subsys_initcall(pseries, phyp_dump_setup)
Yours Tony
linux.conf.au http://linux.conf.au/ || http://lca2008.linux.org.au/
Jan 28 - Feb 02 2008 The Australian Linux Technical Conference!
^ permalink raw reply
* Re: [PATCH 0/4]: Respun LMB patches.
From: Stephen Rothwell @ 2008-02-15 0:58 UTC (permalink / raw)
To: David Miller; +Cc: Olof Johansson, sparclinux, linux-kernel, linuxppc-dev
In-Reply-To: <20080214232152.GB15724@lixom.net>
[-- Attachment #1: Type: text/plain, Size: 899 bytes --]
On Thu, 14 Feb 2008 17:21:52 -0600 Olof Johansson <olof@lixom.net> wrote:
>
> On Thu, Feb 14, 2008 at 02:58:22PM -0600, Becky Bruce wrote:
>
> > Thanks for picking up the patches from Kumar and myself and fitting
> > them into your series - this is much appreciated. FYI, I applied the
> > entire patch series to my local tree and test-booted both mpc8641 and
> > mpc8568mds and both build and boot cleanly. I also built pasemi and
> > ebony, those build cleanly as well.
>
> pasemi_defconfig boots happily on my boards here. I've kicked off my
> "build all powerpc defconfigs" script while I leave the house for a
> couple of hours, but as others have said, no problems are expected...
It builds and boots on legacy iSeries (and seems to be working ok) as well.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* RE: [PATCH] [POWERPC] Enable correct operation of serial ports withnonzero regshift.
From: Stephen Neuendorffer @ 2008-02-14 23:33 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linuxppc-dev, Pavel Kiryukhin
In-Reply-To: <20080215102706.1b7c30c1.sfr@canb.auug.org.au>
gcc knows better. :)
> -----Original Message-----
> From: Stephen Rothwell [mailto:sfr@canb.auug.org.au]
> Sent: Thursday, February 14, 2008 3:27 PM
> To: Stephen Neuendorffer
> Cc: Pavel Kiryukhin; linuxppc-dev@ozlabs.org
> Subject: Re: [PATCH] [POWERPC] Enable correct operation of serial
ports withnonzero regshift.
>=20
> On Thu, 14 Feb 2008 10:55:31 -0800 "Stephen Neuendorffer"
<stephen.neuendorffer@xilinx.com> wrote:
> >
> > > --- a/arch/powerpc/kernel/legacy_serial.c
> > > +++ b/arch/powerpc/kernel/legacy_serial.c
> > > + /* get regshift if present*/
> > > + regshift =3D get_property(np, "reg-shift", NULL);
> >
> > of_get_property, presumably?
>=20
> Damn, how did I miss that? :-)
>=20
> --
> Cheers,
> Stephen Rothwell sfr@canb.auug.org.au
> http://www.canb.auug.org.au/~sfr/
^ permalink raw reply
* Re: [PATCH] [POWERPC] Enable correct operation of serial ports withnonzero regshift.
From: Stephen Rothwell @ 2008-02-14 23:27 UTC (permalink / raw)
To: Stephen Neuendorffer; +Cc: linuxppc-dev, Pavel Kiryukhin
In-Reply-To: <20080214185534.81F625F808D@mail186-dub.bigfish.com>
[-- Attachment #1: Type: text/plain, Size: 468 bytes --]
On Thu, 14 Feb 2008 10:55:31 -0800 "Stephen Neuendorffer" <stephen.neuendorffer@xilinx.com> wrote:
>
> > --- a/arch/powerpc/kernel/legacy_serial.c
> > +++ b/arch/powerpc/kernel/legacy_serial.c
> > + /* get regshift if present*/
> > + regshift = get_property(np, "reg-shift", NULL);
>
> of_get_property, presumably?
Damn, how did I miss that? :-)
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH 0/4]: Respun LMB patches.
From: Olof Johansson @ 2008-02-14 23:21 UTC (permalink / raw)
To: Becky Bruce; +Cc: sparclinux, linuxppc-dev, David Miller, linux-kernel
In-Reply-To: <38133B3C-75A2-4465-9484-7BF8E7E85D1D@freescale.com>
On Thu, Feb 14, 2008 at 02:58:22PM -0600, Becky Bruce wrote:
> Thanks for picking up the patches from Kumar and myself and fitting
> them into your series - this is much appreciated. FYI, I applied the
> entire patch series to my local tree and test-booted both mpc8641 and
> mpc8568mds and both build and boot cleanly. I also built pasemi and
> ebony, those build cleanly as well.
pasemi_defconfig boots happily on my boards here. I've kicked off my
"build all powerpc defconfigs" script while I leave the house for a
couple of hours, but as others have said, no problems are expected...
-Olof
^ permalink raw reply
* Re: [PATCH 2/8] pseries: phyp dump: reserve-release proof-of-concept
From: Olof Johansson @ 2008-02-14 23:12 UTC (permalink / raw)
To: Tony Breeds; +Cc: linuxppc-dev
In-Reply-To: <20080214034621.GA6887@bakeyournoodle.com>
On Thu, Feb 14, 2008 at 02:46:21PM +1100, Tony Breeds wrote:
> Hi Manish,
> Sorry for the minor nits but this should be:
>
> ---
> * Linas Vepstas, Manish Ahuja 2008
> * Copyright 2008 IBM Corp.
> ---
>
> You can optionally use the '??' symbol after word 'Copyright' but you
> shouldn't use '(c)' anymore.
>
> Also in at least one place you've misspelt "Copyright"
If we're going to nitpick, then I'd like to point out that the whole
series needs to be run through checkpatch and at least the whitespace
issues should be taken care of.
I'm still not convinced that this is a useful feature compared to
hardening kdump, especially now that ehea can handle kexec/kdump (patch
posted the other day). But in the end it's up to Paul if he wants to
take it or not, not me.
-Olof
^ permalink raw reply
* Re: /proc/bus/pci and domains
From: Martin Mares @ 2008-02-14 22:21 UTC (permalink / raw)
To: David Miller; +Cc: greg, linux-pci, paulus, anton, linuxppc-dev
In-Reply-To: <20080214.141711.222843930.davem@davemloft.net>
> X now uses sysfs when available, therefore I think it's
> best not to try and muck with this deprecated interface
> if possible.
However, the interface is fatally broken on machines with domains
and the breakage is visible (e.g., run lspci when /sys is not mounted).
I originally intended to just disable the proc backend on the affected
architectures, but it turned out than even x86 can be affected.
Have a nice fortnight
--
Martin `MJ' Mares <mj@ucw.cz> http://mj.ucw.cz/
Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth
"God doesn't play dice." -- Albert Einstein
^ permalink raw reply
* Re: /proc/bus/pci and domains
From: David Miller @ 2008-02-14 22:17 UTC (permalink / raw)
To: mj; +Cc: greg, linux-pci, paulus, anton, linuxppc-dev
In-Reply-To: <mj+md-20080214.214339.22251.nikam@ucw.cz>
From: Martin Mares <mj@ucw.cz>
Date: Thu, 14 Feb 2008 22:45:14 +0100
> But thanks for the tip, I will check X before I post the patch.
X now uses sysfs when available, therefore I think it's
best not to try and muck with this deprecated interface
if possible.
^ permalink raw reply
* Re: [PATCH 0/4]: Respun LMB patches.
From: David Miller @ 2008-02-14 22:15 UTC (permalink / raw)
To: jwboyer; +Cc: sparclinux, linux-kernel, linuxppc-dev
In-Reply-To: <20080214152448.49c69238@zod.rchland.ibm.com>
From: Josh Boyer <jwboyer@linux.vnet.ibm.com>
Date: Thu, 14 Feb 2008 15:24:48 -0600
> I plan on actually testing this on Ebony, Walnut, and Bamboo either
> later tonight or tomorrow. I don't expect many issues.
>
> Dave, those above boards would cover the build of PowerPC 4xx CPU cores.
Ok.
^ permalink raw reply
* Re: /proc/bus/pci and domains
From: Matthew Wilcox @ 2008-02-14 21:45 UTC (permalink / raw)
To: David Miller; +Cc: greg, mj, linuxppc-dev, paulus, anton, linux-pci
In-Reply-To: <20080214.134305.237408044.davem@davemloft.net>
On Thu, Feb 14, 2008 at 01:43:05PM -0800, David Miller wrote:
> From: Martin Mares <mj@ucw.cz>
> Date: Thu, 14 Feb 2008 10:40:22 +0100
>
> > Would it be acceptable for the PPC folks to modify the code to add
> > domain numbers to the device numbers in /proc/bus/pci/devices in the
> > same format as the bus directories already have?
>
> Be careful, things like the X server parse that file, and X's
> parser does not expect domain numbers there so you will break
> things :-(
It might be best if we only place domain 0 in that file.
--
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
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