* Re: ioremap and outb
From: Arnd Bergmann @ 2008-01-04 10:45 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <20080104102037.GA31627@mail.gnudd.com>
On Friday 04 January 2008, Alessandro Rubini wrote:
> > =A0 =A0 =A0 =A0 =A0addr=3Dioremap(base_addr,size); =A0 =A0 =A0 =A0 =A0/=
/ Remap to Mem mapped
>=20
> Yes.
In newer drivers that are specific to powerpc, it's often easier
to use the of_iomap() function to map a device, so you don't
have to calculate the base address manually from the device tree.
> > =A0 =A0 =A0 =A0 =A0out_8(addr) and in_8(addr);=20
>=20
> It should be right, although __raw_readb() and __raw_writeb() may
> suffice for you.
Actually not. While they may work, the __raw_* functions do not have
a specific meaning in device drivers. Depending on the I/O model, they
may or may not work on a given platform. The {in,out}_{8,{be,le}{16,32,64}}
functions however are defined to operate on local (not PCI) ioremapped
mmio devices, and are usually more efficient than the {read,write}{b,w,l,q}
variant you'd use on PCI devices.
Arnd <><
^ permalink raw reply
* Re: ioremap and outb
From: Alessandro Rubini @ 2008-01-04 10:20 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <14612559.post@talk.nabble.com>
Please don't change subject matter without changing subject line, and please
open a new thread when asking a new question.
> I am writing a driver in which device port is mapped to CPLD and 8 bit data
> bus is directly connected from processor to CPLD. Read write on CPLD memory
> mapped (buffer/register) is required to control the device. This is now IO
> mapped to processor.
This is typical. You'll find quite a lot of examples.
> addr=ioremap(base_addr,size); // Remap to Mem mapped
Yes.
> out_8(addr) and in_8(addr);
It should be right, although __raw_readb() and __raw_writeb() may
suffice for you. Please check the comments in <asm/io.h>.
It may also happen that you need to read/write 32 bits instead of 8,
but this depends on your specific hardware.
/alessandro
^ permalink raw reply
* Re: Drivers' probe function calling order
From: Misbah khan @ 2008-01-04 8:41 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <20080103215456.GA20691@mail.gnudd.com>
Hi Mr Rubini ...
I am writing a driver in which device port is mapped to CPLD and 8 bit data
bus is directly connected from processor to CPLD. Read write on CPLD memory
mapped (buffer/register) is required to control the device. This is now IO
mapped to processor.
I need to know whether i am right if i impliment like this :-
addr=ioremap(base_addr,size); // Remap to Mem mapped
address
out_8(addr) and in_8(addr);
Alessandro Rubini wrote:
>
>
>> how can I force the system to call
>> probe function of the spi driver first?
>
> You can declare their init functions at different initcall level. For
> example declaring the dataflash one as late_initcall(). Or declare
> the spi one as subsys_initcall() -- whatever makes more sense.
>
> There might be cleaner ways according to your setup, but this will
> surely work.
>
> /alessandro
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
>
--
View this message in context: http://www.nabble.com/Drivers%27-probe-function-calling-order-tp14601099p14612559.html
Sent from the linuxppc-embedded mailing list archive at Nabble.com.
^ permalink raw reply
* Re: Reading a config file in a driver ....
From: Misbah khan @ 2008-01-04 8:36 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <20080103163019.GA4223@lixom.net>
Could you please let me know How in the driver i could be able to read the
file present in sysfs ??? Using init script how should i creat and edit the
file ????
I never had done these hence your suggession could be a better way for me to
learn it .
---Misbah
Olof Johansson-2 wrote:
>
> On Wed, Jan 02, 2008 at 09:03:20PM -0800, Misbah khan wrote:
>>
>> Hi all ....
>>
>> I am writing a LCD driver in which the default configuration for LCD
>> would
>> be loded at the Init . This default configuration if keep in the driver
>> then
>> for a change in default configuration we need to compile the driver which
>> we
>> never want . Hence we want a .config file in /etc/lcd.config dir which
>> could
>> be changed and the next boot will take this configuration as the default
>> configuration.
>>
>> I need to know How to read from the config file in the driver form the
>> dir
>> /etc/lcd.config. The driver would be installed at boot up
>
> The driver/kernel shouldn't read the file directly, if anything you
> should have a userspace tool that reads it and adjusts the driver via
> sysfs or similar. That tool can be run from some of the init scripts,
> or from the ramdisk in case you want to do it early.
>
>
> -Olof
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
>
--
View this message in context: http://www.nabble.com/Reading-a-config-file-in-a-driver-....-tp14591717p14612555.html
Sent from the linuxppc-embedded mailing list archive at Nabble.com.
^ permalink raw reply
* Re: Reading a config file in a driver ....
From: Misbah khan @ 2008-01-04 8:32 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <477D2CE0.1050806@kenati.com>
i appriciate your concept and i need to know this :-
The config should be in a structure or a bit mask . The user will have to
change the value whenever he needs to change the default config. Where
should i put that struct or bit field defination ???? He should know it
preciesly before he change ????
Can you share with me your Implimentation so that i could get the exactly
how you had done ...
----Misbah < ><
Carlos Munoz-2 wrote:
>
> Olof Johansson wrote:
>> On Wed, Jan 02, 2008 at 09:03:20PM -0800, Misbah khan wrote:
>>
>>> Hi all ....
>>>
>>> I am writing a LCD driver in which the default configuration for LCD
>>> would
>>> be loded at the Init . This default configuration if keep in the driver
>>> then
>>> for a change in default configuration we need to compile the driver
>>> which we
>>> never want . Hence we want a .config file in /etc/lcd.config dir which
>>> could
>>> be changed and the next boot will take this configuration as the default
>>> configuration.
>>>
>>> I need to know How to read from the config file in the driver form the
>>> dir
>>> /etc/lcd.config. The driver would be installed at boot up
>>>
>>
>> The driver/kernel shouldn't read the file directly, if anything you
>> should have a userspace tool that reads it and adjusts the driver via
>> sysfs or similar. That tool can be run from some of the init scripts,
>> or from the ramdisk in case you want to do it early.
>>
> What I've done in the past is to use module_param() to define variables
> that get set when the module is loaded. Then all you need to do is edit
> the /etc/modules file and change the parameter value. However, this
> technique is only efficient if only a few parameters will ever change.
> If you need to change more than a few parameters, Olof's suggestion
> would be preferred.
>
> Carlos
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
>
--
View this message in context: http://www.nabble.com/Reading-a-config-file-in-a-driver-....-tp14591717p14612548.html
Sent from the linuxppc-embedded mailing list archive at Nabble.com.
^ permalink raw reply
* RE: [PATCH 2/3] (Resend part #1) Add the RapidIO support to powerpcarchitecture with memory mapping support.
From: Zhang Wei @ 2008-01-04 7:02 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linuxppc-dev, paulus, linux-kernel
In-Reply-To: <20071223093911.3fd4d1e5.sfr@canb.auug.org.au>
Hi, =20
Thanks!
Maybe I should make a clean and split them into small patches.
Cheers!
Wei.
> Hi,
>=20
> This is a very large patch. It may be easier to review if it could be
> split on some logical way, that is at all possible (I don't=20
> know either
> way). This is just a quick note about some more trivial things.
>=20
> On Fri, 21 Dec 2007 17:58:43 +0800 Zhang Wei=20
> <wei.zhang@FREESCALE.COM> wrote:
> >
> > +struct rio_priv {
> > + volatile void __iomem *regs_win;
> > + volatile struct rio_atmu_regs __iomem *atmu_regs;
> > + volatile struct rio_atmu_regs __iomem *maint_atmu_regs;
> > + volatile struct rio_atmu_regs __iomem *dbell_atmu_regs;
> > + volatile void __iomem *dbell_win;
> > + volatile void __iomem *maint_win;
> > + volatile struct rio_msg_regs __iomem *msg_regs;
>=20
> Paulus has said that any pointer marked __iomem does not need to be
> volatile ...
>=20
> > +static int of_cells_get(struct device_node *np, const char *str)
> > +{
> > + struct device_node *tmp =3D NULL;
> > + const int *var =3D NULL;
>=20
> These initializations are unnecessary.
>=20
> > + var =3D of_get_property(np, str, NULL);
> > + tmp =3D of_get_parent(np);
> > +
> > + while (!var && tmp) {
> > + var =3D (int *)of_get_property(tmp, str, NULL);
>=20
> While I applaud the number of casts remove by this patch,=20
> this one is an
> unnecessary addition.
>=20
> > + of_node_put(tmp);
> > + tmp =3D of_get_parent(np);
>=20
> You should do the above two line in the opposite order. Also do you
> really want to keep getting the parent of the same node over and over
> (i.e. you never change np)?
>=20
> > + }
>=20
> You probably want a final of_node_put(tmp).
>=20
>=20
> > + INFO("Phy type: ");
> > + switch (phy_type) {
> > + case RIO_PHY_SERIAL:
> > + printk("serial\n");
> > + break;
> > + case RIO_PHY_PARALLEL:
> > + printk("parallel");
>=20
> Missing \n
>=20
> > + port =3D kzalloc(sizeof(struct rio_mport), GFP_KERNEL);
> > + if (!port) {
> > + ERR("Can't alloc memory for 'port'\n");
> > + rc =3D -ENOMEM;
> > + goto err;
> > + }
> > port->id =3D 0;
> > port->index =3D 0;
>=20
> These two could go as you just allocated zeroed memory.
>=20
> --=20
> Cheers,
> Stephen Rothwell sfr@canb.auug.org.au
> http://www.canb.auug.org.au/~sfr/
>=20
^ permalink raw reply
* Re: [ofa-general] [PATCH] IB/ehca: Forward event client-reregister-required to registered clients
From: Roland Dreier @ 2008-01-04 5:06 UTC (permalink / raw)
To: Hoang-Nam Nguyen
Cc: fenkes, linux-kernel, linuxppc-dev, Christoph Raisch, general,
stefan.roscher
In-Reply-To: <200712201506.34253.hnguyen@linux.vnet.ibm.com>
thanks, applied.
^ permalink raw reply
* Re: [PATCH] ASoC drivers for the Freescale MPC8610 SoC
From: David Gibson @ 2008-01-04 5:01 UTC (permalink / raw)
To: Jon Smirl; +Cc: linuxppc-dev, alsa-devel, Timur Tabi
In-Reply-To: <9e4733910801030654i7409e383n6b7f844aa543f234@mail.gmail.com>
On Thu, Jan 03, 2008 at 09:54:45AM -0500, Jon Smirl wrote:
> On 1/2/08, David Gibson <david@gibson.dropbear.id.au> wrote:
[snip]
> > Instantiating the fabric driver off any node is wrong, precisely
> > because it is an abstraction. The fabric driver should be
> > instantiated by the platform code.
>
> Instantiating it from the platform code forces me to put it either the
> of_platform_bus or the platform_bus since there aren't any other buses
> around when the platform code runs. Platform bus doesn't implement
> dynamic module loading. So that means it has to go onto the
> of_platform_bus. That implies that is it a pseudo-device without a
> pseudo-device entry in the device tree which is fine with me. I'll
> need to poke around in the of_bus code and see if the driver will load
> without a device tree entry.
You're letting implementation warts influence basic design decisions.
This is not sensible. Step back and think for a moment, work out a
sane organization *then* think how you might need to fix or workaround
limitations of existing infrastructure.
> A simple fix to this would be to let me instantiate the driver off
> from the root node of the tree. That's the conceptually correct place
> for instantiating a driver that extends the platform code. Should I
> try adjusting the of probing code to pass the node in, or are there
> major objections?
The current probing system can't instantiate a device for the root
node in any sane way, since it takes a list of suitable busses.
The constructor based approach we're looking at implementing could do
it. It should, in any case, be constructing a platform_device - so
the platform bus code would still need to be extended to handle the
module loading. Creating it as an of_platform device bound to the
root node might be a workable interim solution though.
of_platform_device simply does not *ever* make sense conceptually: the
type of struct device wrapper in use depends on the bus the device is
attached to, not on how we figured out the device was there. OF can
potentially give information about any sort of device be it
simple-bus, i2c, PCI or whatever connected.
> Also, as others have pointed out, this driver is not an abstraction.
> It represents the mess of wires hooking the codec up to the jacks on
> the back panel and possibly GPIO pins that control the wiring. You
> need this because the pins on HD audio codecs are completely
> reconfigurable and the same chip can be wired in a thousand different
> ways. It lets you have a generic codec driver and the move the
> platform specific code out of the driver.
Well, "abstraction" is maybe not the right word. But the point is
that the fabric driver doesn't represent a neatly isolated device with
well defined bus connections. Instead it represents the tangle of
essentially every link between audio devices in the platform. About
the clearest possible example of a true "platform device" (as opposed
to a device on some bus that just doesn't have any bus-specific
logic).
--
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/3] Return a non-zero exit code if an error occurs during dts parsing.
From: David Gibson @ 2008-01-04 4:30 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, jdl
In-Reply-To: <20080103234333.GC8441@ld0162-tx32.am.freescale.net>
On Thu, Jan 03, 2008 at 05:43:33PM -0600, Scott Wood wrote:
> Previously, only failure to parse caused the reading of the tree to fail;
> semantic errors that called yyerror() but not YYERROR only emitted a message,
> without signalling make to stop the build.
This one, however, I don't like.
[snip]
> diff --git a/dtc.h b/dtc.h
> index 9b89689..cba9d28 100644
> --- a/dtc.h
> +++ b/dtc.h
> @@ -233,6 +233,7 @@ struct reserve_info *add_reserve_entry(struct reserve_info *list,
> struct boot_info {
> struct reserve_info *reservelist;
> struct node *dt; /* the device tree */
> + int error;
> };
This is unequivocally wrong. boot_info should have information about
the contents of the blob, not state information like the error.
If you're going to use an ugly global, then use it everywhere.
--
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 2/3] Look for include files in the directory of the including file.
From: David Gibson @ 2008-01-04 4:27 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, jdl
In-Reply-To: <20080103234331.GB8441@ld0162-tx32.am.freescale.net>
On Thu, Jan 03, 2008 at 05:43:31PM -0600, Scott Wood wrote:
> Looking in the diretory dtc is invoked from is not very useful behavior.
>
> As part of the code reorganization to implement this, I removed the
> uniquifying of name storage -- it seemed a rather dubious optimization
> given likely usage, and some aspects of it would have been mildly awkward
> to integrate with the new code.
>
> Signed-off-by: Scott Wood <scottwood@freescale.com>
Would have been kind of nice to see the two parts as separate
patches. But no big deal, again, I'd really like to see this in for
1.1.
Acked-by: David Gibson <david@gibson.dropbear.id.au>
A few comments nonetheless:
[snip]
> @@ -260,7 +259,19 @@ int push_input_file(const char *filename)
> return 0;
> }
>
> - f = dtc_open_file(filename);
> + if (srcpos_file) {
> + search.dir = srcpos_file->dir;
> + search.next = NULL;
> + search.prev = NULL;
> + searchptr = &search;
> + }
> +
> + newfile = dtc_open_file(filename, searchptr);
> + if (!newfile) {
> + yyerrorf("Couldn't open \"%s\": %s",
> + filename, strerror(errno));
> + exit(1);
Use die() here, that's what it's for.
> + }
>
> incl_file = malloc(sizeof(struct incl_file));
> if (!incl_file) {
And we should be using xmalloc() here (not your change, I realise).
[snip]
> -FILE *dtc_open_file(const char *fname)
> +static int dtc_open_one(struct dtc_file *file,
> + const char *search,
> + const char *fname)
> {
> - FILE *f;
> -
> - if (lookup_file_name(fname, 1) < 0)
> - die("Too many files opened\n");
> -
> - if (streq(fname, "-"))
> - f = stdin;
> - else
> - f = fopen(fname, "r");
> + char *fullname;
> +
> + if (search) {
> + fullname = malloc(strlen(search) + strlen(fname) + 2);
> + if (!fullname)
> + die("Out of memory\n");
xmalloc() again (your fault, this time).
> + strcpy(fullname, search);
> + strcat(fullname, "/");
> + strcat(fullname, fname);
> + } else {
> + fullname = strdup(fname);
> + }
>
> - if (! f)
> - die("Couldn't open \"%s\": %s\n", fname, strerror(errno));
> + file->file = fopen(fullname, "r");
> + if (!file->file) {
> + free(fullname);
> + return 0;
> + }
>
> - return f;
> + file->name = fullname;
> + return 1;
> }
>
>
> -
> -/*
> - * Locate and optionally add filename fname in the file_names[] array.
> - *
> - * If the filename is currently not in the array and the boolean
> - * add_it is non-zero, an attempt to add the filename will be made.
> - *
> - * Returns;
> - * Index [0..MAX_N_FILE_NAMES) where the filename is kept
> - * -1 if the name can not be recorded
> - */
> -
> -int lookup_file_name(const char *fname, int add_it)
> +struct dtc_file *dtc_open_file(const char *fname,
> + const struct search_path *search)
> {
> - int i;
> -
> - for (i = 0; i < n_file_names; i++) {
> - if (strcmp(file_names[i], fname) == 0)
> - return i;
> + static const struct search_path default_search = { NULL, NULL, NULL };
> +
> + struct dtc_file *file;
> + const char *slash;
> +
> + file = malloc(sizeof(struct dtc_file));
> + if (!file)
> + die("Out of memory\n");
xmalloc() again.
> + slash = strrchr(fname, '/');
> + if (slash) {
> + char *dir = malloc(slash - fname + 1);
> + if (!dir)
> + die("Out of memory\n");
And again.
> + memcpy(dir, fname, slash - fname);
> + dir[slash - fname] = 0;
> + file->dir = dir;
> + } else {
> + file->dir = NULL;
> }
>
> - if (add_it) {
> - if (n_file_names < MAX_N_FILE_NAMES) {
> - file_names[n_file_names] = strdup(fname);
> - return n_file_names++;
> - }
> + if (streq(fname, "-")) {
> + file->name = "stdin";
> + file->file = stdin;
> + return file;
> }
>
> - return -1;
> -}
> + if (!search)
> + search = &default_search;
>
> + while (search) {
> + if (dtc_open_one(file, search->dir, fname))
> + return file;
Don't we need a different case here somewhere for if someone specifies
an include file as an absolute path? Have I missed something?
[snip]
> +struct search_path {
> + const char *dir; /* NULL for current directory */
> + struct search_path *prev, *next;
> +};
I wouldn't suggest a doubly linked list here. Or at least not without
converting our many existing singly linked lists at the same time.
--
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 1/3] Add yyerrorf() for formatted error messages.
From: David Gibson @ 2008-01-04 4:07 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, jdl
In-Reply-To: <20080103234329.GA8441@ld0162-tx32.am.freescale.net>
On Thu, Jan 03, 2008 at 05:43:29PM -0600, Scott Wood wrote:
> Signed-off-by: Scott Wood <scottwood@freescale.com>
I don't really like adding any yy*() functions that aren't actually
part of the fixed lex/yacc interface. But, despite that, let's merge
this, and parth 2/3 because I think we should get in sane include
searching for 1.1. I'll look at polishing the message printing stuff
later.
Acked-by: David Gibson <david@ribson.dropbear.id.au>
--
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: Outstanding DTC patches?
From: David Gibson @ 2008-01-04 2:43 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <E1JAQqT-00056B-FP@jdl.com>
On Thu, Jan 03, 2008 at 08:14:53AM -0600, Jon Loeliger wrote:
> So, like, the other day David Gibson mumbled:
> >
> > I posted this one a while back, but I guess it dropped through the
> > cracks.
>
> Yep, sorry.
>
> > There's also the patch I sent you quite a long time ago that
> > adds a clarifying readme about the licensing situation - that might be
> > an idea for v1.1, too.
>
> I can not find this; neither locally nor on patchworks.
> Do you have a Subject: line, a URL, or could you
> please repost it?
Ah, I think I sent it by private mail, so it won't be in patchwork.
Here you are:
dtc/libfdt: Add README clarifying licensing
The fact the dtc are distributed together, but have different licenses
can be a bit confusing. Several people have enquired as to what the
deal is with the libfdt licensing, so this patch adds a README
clarifying the situation with a rationale.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Index: dtc/README.license
===================================================================
--- /dev/null 1970-01-01 00:00:00.000000000 +0000
+++ dtc/README.license 2007-11-02 11:43:19.000000000 +1100
@@ -0,0 +1,56 @@
+Licensing and contribution policy of dtc and libfdt
+===================================================
+
+This dtc package contains two pieces of software: dtc itself, and
+libfdt which comprises the files in the libfdt/ subdirectory. These
+two pieces of software, although closely related, are quite distinct.
+dtc does not incoporate or rely on libfdt for its operation, nor vice
+versa. It is important that these two pieces of software have
+different license conditions.
+
+As the copyright banners in each source file attest, dtc is licensed
+under the GNU GPL. The full text of the GPL can be found in the file
+entitled 'GPL' which should be included in this package. dtc code,
+therefore, may not be incorporated into works which do not have a GPL
+compatible license.
+
+libfdt, however, is GPL/BSD dual-licensed. That is, it may be used
+either under the terms of the GPL, or under the terms of the 2-clause
+BSD license (aka the ISC license). The full terms of that license are
+given in the copyright banners of each of the libfdt source files.
+This is, in practice, equivalent to being BSD licensed, since the
+terms of the BSD license are strictly more permissive than the GPL.
+
+I made the decision to license libfdt in this way because I want to
+encourage widespread and correct usage of flattened device trees,
+including by proprietary or otherwise GPL-incompatible firmware or
+tools. Allowing libfdt to be used under the terms of the BSD license
+makes that it easier for vendors or authors of such software to do so.
+
+This does mean that libfdt code could be "stolen" - say, included in a
+proprietary fimware and extended without contributing those extensions
+back to the libfdt mainline. While I hope that doesn't happen, I
+believe the goal of allowing libfdt to be widely used is more
+important than avoiding that. libfdt is quite small, and hardly
+rocket science; so the incentive for such impolite behaviour is small,
+and the inconvenience caused therby is not dire.
+
+Licenses such as the LGPL which would allow code to be used in non-GPL
+software, but also require contributions to be returned were
+considered. However, libfdt is designed to be used in firmwares and
+other environments with unusual technical constraints. It's difficult
+to anticipate all possible changes which might be needed to meld
+libfdt into such environments and so difficult to suitably word a
+license that puts the boundary between what is and isn't permitted in
+the intended place. Again, I judged encouraging widespread use of
+libfdt by keeping the license terms simple and familiar to be the more
+important goal.
+
+**IMPORTANT** It's intended that all of libfdt as released remain
+permissively licensed this way. Therefore only contributions which
+are released under these terms can be merged into the libfdt mainline.
+
+
+David Gibson <david@gibson.dropbear.id.au>
+(principal original author of dtc and libfdt)
+2 November 2007
--
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: File system problem
From: Jean-Samuel Chenard @ 2008-01-03 23:57 UTC (permalink / raw)
To: linuxppc-embedded, kernelppc
> Message: 9
> Date: Thu, 3 Jan 2008 18:00:14 +0100
> From: "mojtaba"
>
> Actually, I removed the console and null created by buildroot and create
> them manually using make node. This time the system freezes at this point=
.
> "Freeing unused kernel memory: 76k init"
Hi Mojtaba,
I just want to comment on your observation that the file size in /dev
was zero. This is normal as the device files are 'special' since they
are a mean of abstracting the interface to the kernel. I had to read
the online book listed below before I could understand the inner
workings of those special files. If you plan on interfacing your FPGA
with the Linux Kernel, I suggest you read it too, as it is a very
insightful book:
http://lwn.net/Kernel/LDD3/
At this point, your system is not frozen, but your init script and
configuration files are probably not all correctly set. You might
need to read some documentation about buildroot to see what its init
scripts are trying to do.
You might be missing a library or symlink (I got that problem in my
attempt to build the BusyBox root filesystem from scratch). One way
to go at the problem is to pass the init=3D/bin/ash or something like
that to your kernel at the boot prompt (you could even make some
trivial 'hello world' program and pass it to the kernel as the init
process). This way, you can dive right into a shell or your program
and avoid init and its configuration.
After some copying of required libraries in /lib (I'm using uClibc)
and the creation of the required symbolic links, I got my Busybox root
filesystem working on my ML-310 board.
Good luck!
Regards,
Jean-Samuel
--=20
Ph.D. candidate
Integrated Microsystems Laboratory
McGill University, Montr=E9al, QC, CANADA
Web Page: http://chaos.ece.mcgill.ca
^ permalink raw reply
* Re: [PATCH v2] ucc_uart: add support for Freescale QUICCEngine UART
From: Anton Vorontsov @ 2008-01-03 23:41 UTC (permalink / raw)
To: Timur Tabi; +Cc: Scott Wood, linuxppc-dev
In-Reply-To: <477D28D3.3000102@freescale.com>
On Thu, Jan 03, 2008 at 12:26:27PM -0600, Timur Tabi wrote:
> Scott Wood wrote:
>
> >>>> +static struct of_platform_driver ucc_uart_of_driver = {
> >>>> + .owner = THIS_MODULE,
> >>>> + .name = "ucc_uart",
> >>> Maybe better fsl,ucc_uart?
> >
> > fsl,qe-uart is defined by Documentation/powerpc/booting-without-of.txt.
>
> Wait, I'm confused. What does the of_platform_driver.name string have to do
> with the compatible field in the device tree? Like I said earlier, I'm just
Eh, initially I meant compatible stuff, not the driver name. I've quoted
wrong code snippet, thus the confusion.
You're using "ucc_uart" for compatible matching:
> +static struct of_device_id ucc_uart_match[] = {
> + {
> + .type = "serial",
> + .compatible = "ucc_uart",
here "fsl,qe-uart" will look better, no?
> + },
> + {},
> +};
> +MODULE_DEVICE_TABLE(of, ucc_uart_match);
Thanks,
--
Anton Vorontsov
email: cbou@mail.ru
backup email: ya-cbou@yandex.ru
irc://irc.freenode.net/bd2
^ permalink raw reply
* Re: [PATCH] ASoC drivers for the Freescale MPC8610 SoC
From: David Gibson @ 2008-01-03 23:51 UTC (permalink / raw)
To: Timur Tabi; +Cc: Liam Girdwood, alsa-devel, linuxppc-dev
In-Reply-To: <477D2150.4020506@freescale.com>
On Thu, Jan 03, 2008 at 11:54:24AM -0600, Timur Tabi wrote:
> Jon Smirl wrote:
> > On 1/2/08, Timur Tabi <timur@freescale.com> wrote:
> >> Jon Smirl wrote:
> >>> On 1/1/08, Jon Smirl <jonsmirl@gmail.com> wrote:
> >>>> On 12/19/07, Timur Tabi <timur@freescale.com> wrote:
[snip]
> > Don't we want to follow the device tree policy of putting the device
> > on the controlling bus and then link it to the data bus?
>
> Normally, that sounds like a good idea, but the cs4270 is an I2S
> device first, and an I2C device second. I need to be able to find
> that codec from the I2S node. My I2S driver would not know to scan
> all I2C devices to find the codec.
And what distinction are you drawing between "first" and "second"
here? For the device tree, the primary bus should the the one by
which it's addressable - i.e. where the control registers are, not
the data path.
Why would the I2S need to scan for codecs? Wouldn't it be up to the
codec driver to register with I2S?
--
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: [alsa-devel] [PATCH] ASoC drivers for the Freescale MPC8610 SoC
From: David Gibson @ 2008-01-03 23:47 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev, alsa-devel
In-Reply-To: <477D2673.5090203@freescale.com>
On Thu, Jan 03, 2008 at 12:16:19PM -0600, Timur Tabi wrote:
> Mark Brown wrote:
>
> > The machine support code (fabric driver in PowerPC terms, I think?)
> > tells the core how everything is connected together by registering
> > devices representing the links (eg, I2S) between the codecs, CPU and
> > other devices. The ASoC core is then responsible for ensuring that all
> > the required components are present before it registers with the ALSA
> > core.
>
> I'm no expert on this, but I think from the PowerPC point-of-view,
> the *ideal* situation would be if the ASoC fabric driver were
> generic, maybe even part of ASoC itself, and everything it needed
> could be obtained from the device tree.
Nice idea in principle, and may be the way to go ultimately, but very
tricky in practice. The whole reason the fabric driver concept exists
(from other archs) is that there are an awful lot of variants on how
to wire the sound components together. Devising a way of expressing
those connections in the device tree that's sufficient will be very
curly. Then we'd have to build the fabric driver that can parse and
process them all. And then, people will no doubt produce device trees
with errors in the connection information, so we'll still need
platform-specific workarounds.
If we want sound working any time soon, we'll want to stick with the
platform based fabric drivers for the time being.
--
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 1/3] Add yyerrorf() for formatted error messages.
From: Scott Wood @ 2008-01-03 23:45 UTC (permalink / raw)
To: jdl; +Cc: linuxppc-dev
In-Reply-To: <20080103234329.GA8441@ld0162-tx32.am.freescale.net>
Scott Wood wrote:
> Signed-off-by: Scott Wood <scottwood@freescale.com>
> ---
> dtc-parser.y | 16 +++++++++++++---
> srcpos.h | 1 +
> treesource.c | 1 -
> 3 files changed, 14 insertions(+), 4 deletions(-)
I forgot to tag them as such, but these are of course dtc patches and
not Linux patches.
-Scott
^ permalink raw reply
* [PATCH 2/3] Look for include files in the directory of the including file.
From: Scott Wood @ 2008-01-03 23:43 UTC (permalink / raw)
To: jdl; +Cc: linuxppc-dev
Looking in the diretory dtc is invoked from is not very useful behavior.
As part of the code reorganization to implement this, I removed the
uniquifying of name storage -- it seemed a rather dubious optimization
given likely usage, and some aspects of it would have been mildly awkward
to integrate with the new code.
Signed-off-by: Scott Wood <scottwood@freescale.com>
---
dtc-lexer.l | 64 +++++++++++++++++------------
dtc-parser.y | 2 +-
dtc.c | 14 ++++--
srcpos.c | 126 +++++++++++++++++++++++++++++++---------------------------
srcpos.h | 28 +++++++++----
5 files changed, 134 insertions(+), 100 deletions(-)
diff --git a/dtc-lexer.l b/dtc-lexer.l
index c811b22..bfb996e 100644
--- a/dtc-lexer.l
+++ b/dtc-lexer.l
@@ -74,7 +74,7 @@ static int dts_version; /* = 0 */
}
<*>\"([^\\"]|\\.)*\" {
- yylloc.filenum = srcpos_filenum;
+ yylloc.file = srcpos_file;
yylloc.first_line = yylineno;
DPRINT("String: %s\n", yytext);
yylval.data = data_copy_escape_string(yytext+1,
@@ -84,7 +84,7 @@ static int dts_version; /* = 0 */
}
<*>"/dts-v1/" {
- yylloc.filenum = srcpos_filenum;
+ yylloc.file = srcpos_file;
yylloc.first_line = yylineno;
DPRINT("Keyword: /dts-v1/\n");
dts_version = 1;
@@ -93,7 +93,7 @@ static int dts_version; /* = 0 */
}
<*>"/memreserve/" {
- yylloc.filenum = srcpos_filenum;
+ yylloc.file = srcpos_file;
yylloc.first_line = yylineno;
DPRINT("Keyword: /memreserve/\n");
BEGIN_DEFAULT();
@@ -101,7 +101,7 @@ static int dts_version; /* = 0 */
}
<*>{LABEL}: {
- yylloc.filenum = srcpos_filenum;
+ yylloc.file = srcpos_file;
yylloc.first_line = yylineno;
DPRINT("Label: %s\n", yytext);
yylval.labelref = strdup(yytext);
@@ -110,7 +110,7 @@ static int dts_version; /* = 0 */
}
<INITIAL>[bodh]# {
- yylloc.filenum = srcpos_filenum;
+ yylloc.file = srcpos_file;
yylloc.first_line = yylineno;
if (*yytext == 'b')
yylval.cbase = 2;
@@ -125,7 +125,7 @@ static int dts_version; /* = 0 */
}
<INITIAL>[0-9a-fA-F]+ {
- yylloc.filenum = srcpos_filenum;
+ yylloc.file = srcpos_file;
yylloc.first_line = yylineno;
yylval.literal = strdup(yytext);
DPRINT("Literal: '%s'\n", yylval.literal);
@@ -133,7 +133,7 @@ static int dts_version; /* = 0 */
}
<V1>[0-9]+|0[xX][0-9a-fA-F]+ {
- yylloc.filenum = srcpos_filenum;
+ yylloc.file = srcpos_file;
yylloc.first_line = yylineno;
yylval.literal = strdup(yytext);
DPRINT("Literal: '%s'\n", yylval.literal);
@@ -141,7 +141,7 @@ static int dts_version; /* = 0 */
}
\&{LABEL} { /* label reference */
- yylloc.filenum = srcpos_filenum;
+ yylloc.file = srcpos_file;
yylloc.first_line = yylineno;
DPRINT("Ref: %s\n", yytext+1);
yylval.labelref = strdup(yytext+1);
@@ -149,7 +149,7 @@ static int dts_version; /* = 0 */
}
"&{/"{PATHCHAR}+\} { /* new-style path reference */
- yylloc.filenum = srcpos_filenum;
+ yylloc.file = srcpos_file;
yylloc.first_line = yylineno;
yytext[yyleng-1] = '\0';
DPRINT("Ref: %s\n", yytext+2);
@@ -158,7 +158,7 @@ static int dts_version; /* = 0 */
}
<INITIAL>"&/"{PATHCHAR}+ { /* old-style path reference */
- yylloc.filenum = srcpos_filenum;
+ yylloc.file = srcpos_file;
yylloc.first_line = yylineno;
DPRINT("Ref: %s\n", yytext+1);
yylval.labelref = strdup(yytext+1);
@@ -166,7 +166,7 @@ static int dts_version; /* = 0 */
}
<BYTESTRING>[0-9a-fA-F]{2} {
- yylloc.filenum = srcpos_filenum;
+ yylloc.file = srcpos_file;
yylloc.first_line = yylineno;
yylval.byte = strtol(yytext, NULL, 16);
DPRINT("Byte: %02x\n", (int)yylval.byte);
@@ -174,7 +174,7 @@ static int dts_version; /* = 0 */
}
<BYTESTRING>"]" {
- yylloc.filenum = srcpos_filenum;
+ yylloc.file = srcpos_file;
yylloc.first_line = yylineno;
DPRINT("/BYTESTRING\n");
BEGIN_DEFAULT();
@@ -182,7 +182,7 @@ static int dts_version; /* = 0 */
}
<PROPNODENAME>{PROPNODECHAR}+ {
- yylloc.filenum = srcpos_filenum;
+ yylloc.file = srcpos_file;
yylloc.first_line = yylineno;
DPRINT("PropNodeName: %s\n", yytext);
yylval.propnodename = strdup(yytext);
@@ -190,11 +190,10 @@ static int dts_version; /* = 0 */
return DT_PROPNODENAME;
}
-
<*>[[:space:]]+ /* eat whitespace */
<*>"/*"([^*]|\*+[^*/])*\*+"/" {
- yylloc.filenum = srcpos_filenum;
+ yylloc.file = srcpos_file;
yylloc.first_line = yylineno;
DPRINT("Comment: %s\n", yytext);
/* eat comments */
@@ -203,7 +202,7 @@ static int dts_version; /* = 0 */
<*>"//".*\n /* eat line comments */
<*>. {
- yylloc.filenum = srcpos_filenum;
+ yylloc.file = srcpos_file;
yylloc.first_line = yylineno;
DPRINT("Char: %c (\\x%02x)\n", yytext[0],
(unsigned)yytext[0]);
@@ -227,8 +226,7 @@ static int dts_version; /* = 0 */
*/
struct incl_file {
- int filenum;
- FILE *file;
+ struct dtc_file *file;
YY_BUFFER_STATE yy_prev_buf;
int yy_prev_lineno;
struct incl_file *prev;
@@ -247,8 +245,9 @@ static int incl_depth = 0;
int push_input_file(const char *filename)
{
- FILE *f;
struct incl_file *incl_file;
+ struct dtc_file *newfile;
+ struct search_path search, *searchptr = NULL;
if (!filename) {
yyerror("No include file name given.");
@@ -260,7 +259,19 @@ int push_input_file(const char *filename)
return 0;
}
- f = dtc_open_file(filename);
+ if (srcpos_file) {
+ search.dir = srcpos_file->dir;
+ search.next = NULL;
+ search.prev = NULL;
+ searchptr = &search;
+ }
+
+ newfile = dtc_open_file(filename, searchptr);
+ if (!newfile) {
+ yyerrorf("Couldn't open \"%s\": %s",
+ filename, strerror(errno));
+ exit(1);
+ }
incl_file = malloc(sizeof(struct incl_file));
if (!incl_file) {
@@ -273,8 +284,7 @@ int push_input_file(const char *filename)
*/
incl_file->yy_prev_buf = YY_CURRENT_BUFFER;
incl_file->yy_prev_lineno = yylineno;
- incl_file->filenum = srcpos_filenum;
- incl_file->file = yyin;
+ incl_file->file = srcpos_file;
incl_file->prev = incl_file_stack;
incl_file_stack = incl_file;
@@ -282,9 +292,9 @@ int push_input_file(const char *filename)
/*
* Establish new context.
*/
- srcpos_filenum = lookup_file_name(filename, 0);
+ srcpos_file = newfile;
yylineno = 1;
- yyin = f;
+ yyin = newfile->file;
yy_switch_to_buffer(yy_create_buffer(yyin, YY_BUF_SIZE));
return 1;
@@ -298,7 +308,7 @@ int pop_input_file(void)
if (incl_file_stack == 0)
return 0;
- fclose(yyin);
+ dtc_close_file(srcpos_file);
/*
* Pop.
@@ -313,8 +323,8 @@ int pop_input_file(void)
yy_delete_buffer(YY_CURRENT_BUFFER);
yy_switch_to_buffer(incl_file->yy_prev_buf);
yylineno = incl_file->yy_prev_lineno;
- srcpos_filenum = incl_file->filenum;
- yyin = incl_file->file;
+ srcpos_file = incl_file->file;
+ yyin = incl_file->file ? incl_file->file->file : NULL;
/*
* Free old state.
diff --git a/dtc-parser.y b/dtc-parser.y
index ddb7f27..8ed58e8 100644
--- a/dtc-parser.y
+++ b/dtc-parser.y
@@ -309,7 +309,7 @@ label:
void yyerrorf(char const *s, ...)
{
- const char *fname = srcpos_filename_for_num(yylloc.filenum);
+ const char *fname = srcpos_file ? srcpos_file->name : "<no-file>";
va_list va;
va_start(va, s);
diff --git a/dtc.c b/dtc.c
index 6295b39..fb716f3 100644
--- a/dtc.c
+++ b/dtc.c
@@ -118,7 +118,7 @@ int main(int argc, char *argv[])
int force = 0, check = 0;
const char *arg;
int opt;
- FILE *inf = NULL;
+ struct dtc_file *inf = NULL;
FILE *outf = NULL;
int outversion = DEFAULT_FDT_VERSION;
int boot_cpuid_phys = 0xfeedbeef;
@@ -192,14 +192,18 @@ int main(int argc, char *argv[])
} else if (streq(inform, "fs")) {
bi = dt_from_fs(arg);
} else if(streq(inform, "dtb")) {
- inf = dtc_open_file(arg);
- bi = dt_from_blob(inf);
+ inf = dtc_open_file(arg, NULL);
+ if (!inf)
+ die("Couldn't open \"%s\": %s\n", arg,
+ strerror(errno));
+
+ bi = dt_from_blob(inf->file);
} else {
die("Unknown input format \"%s\"\n", inform);
}
- if (inf && (inf != stdin))
- fclose(inf);
+ if (inf && inf->file != stdin)
+ fclose(inf->file);
if (! bi || ! bi->dt)
die("Couldn't read input tree\n");
diff --git a/srcpos.c b/srcpos.c
index 352b0fe..7340c33 100644
--- a/srcpos.c
+++ b/srcpos.c
@@ -20,86 +20,94 @@
#include "dtc.h"
#include "srcpos.h"
-
-/*
- * Record the complete unique set of opened file names.
- * Primarily used to cache source position file names.
- */
-#define MAX_N_FILE_NAMES (100)
-
-const char *file_names[MAX_N_FILE_NAMES];
-static int n_file_names = 0;
-
/*
* Like yylineno, this is the current open file pos.
*/
-int srcpos_filenum = -1;
-
+struct dtc_file *srcpos_file;
-
-FILE *dtc_open_file(const char *fname)
+static int dtc_open_one(struct dtc_file *file,
+ const char *search,
+ const char *fname)
{
- FILE *f;
-
- if (lookup_file_name(fname, 1) < 0)
- die("Too many files opened\n");
-
- if (streq(fname, "-"))
- f = stdin;
- else
- f = fopen(fname, "r");
+ char *fullname;
+
+ if (search) {
+ fullname = malloc(strlen(search) + strlen(fname) + 2);
+ if (!fullname)
+ die("Out of memory\n");
+
+ strcpy(fullname, search);
+ strcat(fullname, "/");
+ strcat(fullname, fname);
+ } else {
+ fullname = strdup(fname);
+ }
- if (! f)
- die("Couldn't open \"%s\": %s\n", fname, strerror(errno));
+ file->file = fopen(fullname, "r");
+ if (!file->file) {
+ free(fullname);
+ return 0;
+ }
- return f;
+ file->name = fullname;
+ return 1;
}
-
-/*
- * Locate and optionally add filename fname in the file_names[] array.
- *
- * If the filename is currently not in the array and the boolean
- * add_it is non-zero, an attempt to add the filename will be made.
- *
- * Returns;
- * Index [0..MAX_N_FILE_NAMES) where the filename is kept
- * -1 if the name can not be recorded
- */
-
-int lookup_file_name(const char *fname, int add_it)
+struct dtc_file *dtc_open_file(const char *fname,
+ const struct search_path *search)
{
- int i;
-
- for (i = 0; i < n_file_names; i++) {
- if (strcmp(file_names[i], fname) == 0)
- return i;
+ static const struct search_path default_search = { NULL, NULL, NULL };
+
+ struct dtc_file *file;
+ const char *slash;
+
+ file = malloc(sizeof(struct dtc_file));
+ if (!file)
+ die("Out of memory\n");
+
+ slash = strrchr(fname, '/');
+ if (slash) {
+ char *dir = malloc(slash - fname + 1);
+ if (!dir)
+ die("Out of memory\n");
+
+ memcpy(dir, fname, slash - fname);
+ dir[slash - fname] = 0;
+ file->dir = dir;
+ } else {
+ file->dir = NULL;
}
- if (add_it) {
- if (n_file_names < MAX_N_FILE_NAMES) {
- file_names[n_file_names] = strdup(fname);
- return n_file_names++;
- }
+ if (streq(fname, "-")) {
+ file->name = "stdin";
+ file->file = stdin;
+ return file;
}
- return -1;
-}
+ if (!search)
+ search = &default_search;
+ while (search) {
+ if (dtc_open_one(file, search->dir, fname))
+ return file;
-const char *srcpos_filename_for_num(int filenum)
-{
- if (0 <= filenum && filenum < n_file_names) {
- return file_names[filenum];
+ if (errno != ENOENT)
+ goto out;
+
+ search = search->next;
}
- return 0;
+out:
+ free(file);
+ return NULL;
}
-
-const char *srcpos_get_filename(void)
+void dtc_close_file(struct dtc_file *file)
{
- return srcpos_filename_for_num(srcpos_filenum);
+ if (fclose(file->file))
+ die("Error closing \"%s\": %s\n", file->name, strerror(errno));
+
+ free(file);
}
diff --git a/srcpos.h b/srcpos.h
index e59c788..8108539 100644
--- a/srcpos.h
+++ b/srcpos.h
@@ -22,13 +22,21 @@
* array of all opened filenames.
*/
+#include <stdio.h>
+
+struct dtc_file {
+ const char *dir;
+ const char *name;
+ FILE *file;
+};
+
#if ! defined(YYLTYPE) && ! defined(YYLTYPE_IS_DECLARED)
typedef struct YYLTYPE {
int first_line;
int first_column;
int last_line;
int last_column;
- int filenum;
+ struct dtc_file *file;
} YYLTYPE;
#define YYLTYPE_IS_DECLARED 1
@@ -48,7 +56,7 @@ typedef struct YYLTYPE {
(Current).first_column = YYRHSLOC (Rhs, 1).first_column; \
(Current).last_line = YYRHSLOC (Rhs, N).last_line; \
(Current).last_column = YYRHSLOC (Rhs, N).last_column; \
- (Current).filenum = YYRHSLOC (Rhs, N).filenum; \
+ (Current).file = YYRHSLOC (Rhs, N).file; \
} \
else \
{ \
@@ -56,7 +64,7 @@ typedef struct YYLTYPE {
YYRHSLOC (Rhs, 0).last_line; \
(Current).first_column = (Current).last_column = \
YYRHSLOC (Rhs, 0).last_column; \
- (Current).filenum = YYRHSLOC (Rhs, 0).filenum; \
+ (Current).file = YYRHSLOC (Rhs, 0).file; \
} \
while (YYID (0))
@@ -65,12 +73,16 @@ typedef struct YYLTYPE {
extern void yyerror(char const *);
extern void yyerrorf(char const *, ...) __attribute__((format(printf, 1, 2)));
-extern int srcpos_filenum;
+extern struct dtc_file *srcpos_file;
extern int push_input_file(const char *filename);
extern int pop_input_file(void);
-extern FILE *dtc_open_file(const char *fname);
-extern int lookup_file_name(const char *fname, int add_it);
-extern const char *srcpos_filename_for_num(int filenum);
-const char *srcpos_get_filename(void);
+struct search_path {
+ const char *dir; /* NULL for current directory */
+ struct search_path *prev, *next;
+};
+
+extern struct dtc_file *dtc_open_file(const char *fname,
+ const struct search_path *search);
+extern void dtc_close_file(struct dtc_file *file);
--
1.5.3
^ permalink raw reply related
* [PATCH 3/3] Return a non-zero exit code if an error occurs during dts parsing.
From: Scott Wood @ 2008-01-03 23:43 UTC (permalink / raw)
To: jdl; +Cc: linuxppc-dev
Previously, only failure to parse caused the reading of the tree to fail;
semantic errors that called yyerror() but not YYERROR only emitted a message,
without signalling make to stop the build.
Signed-off-by: Scott Wood <scottwood@freescale.com>
---
dtc-parser.y | 2 ++
dtc.c | 2 +-
dtc.h | 1 +
livetree.c | 1 +
treesource.c | 3 +++
5 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/dtc-parser.y b/dtc-parser.y
index 8ed58e8..da7f6f5 100644
--- a/dtc-parser.y
+++ b/dtc-parser.y
@@ -28,6 +28,7 @@ int yylex(void);
unsigned long long eval_literal(const char *s, int base, int bits);
extern struct boot_info *the_boot_info;
+extern int treesource_error;
%}
@@ -320,6 +321,7 @@ void yyerrorf(char const *s, ...)
vfprintf(stderr, s, va);
fprintf(stderr, "\n");
+ treesource_error = 1;
va_end(va);
}
diff --git a/dtc.c b/dtc.c
index fb716f3..c1814c1 100644
--- a/dtc.c
+++ b/dtc.c
@@ -205,7 +205,7 @@ int main(int argc, char *argv[])
if (inf && inf->file != stdin)
fclose(inf->file);
- if (! bi || ! bi->dt)
+ if (! bi || ! bi->dt || bi->error)
die("Couldn't read input tree\n");
process_checks(force, bi);
diff --git a/dtc.h b/dtc.h
index 9b89689..cba9d28 100644
--- a/dtc.h
+++ b/dtc.h
@@ -233,6 +233,7 @@ struct reserve_info *add_reserve_entry(struct reserve_info *list,
struct boot_info {
struct reserve_info *reservelist;
struct node *dt; /* the device tree */
+ int error;
};
struct boot_info *build_boot_info(struct reserve_info *reservelist,
diff --git a/livetree.c b/livetree.c
index 6ba0846..7610e78 100644
--- a/livetree.c
+++ b/livetree.c
@@ -172,6 +172,7 @@ struct boot_info *build_boot_info(struct reserve_info *reservelist,
bi = xmalloc(sizeof(*bi));
bi->reservelist = reservelist;
bi->dt = tree;
+ bi->error = 0;
return bi;
}
diff --git a/treesource.c b/treesource.c
index e7d580f..980bda7 100644
--- a/treesource.c
+++ b/treesource.c
@@ -25,10 +25,12 @@ extern FILE *yyin;
extern int yyparse(void);
struct boot_info *the_boot_info;
+int treesource_error;
struct boot_info *dt_from_source(const char *fname)
{
the_boot_info = NULL;
+ treesource_error = 0;
push_input_file(fname);
@@ -37,6 +39,7 @@ struct boot_info *dt_from_source(const char *fname)
fill_fullpaths(the_boot_info->dt, "");
+ the_boot_info->error = treesource_error;
return the_boot_info;
}
--
1.5.3
^ permalink raw reply related
* [PATCH 1/3] Add yyerrorf() for formatted error messages.
From: Scott Wood @ 2008-01-03 23:43 UTC (permalink / raw)
To: jdl; +Cc: linuxppc-dev
Signed-off-by: Scott Wood <scottwood@freescale.com>
---
dtc-parser.y | 16 +++++++++++++---
srcpos.h | 1 +
treesource.c | 1 -
3 files changed, 14 insertions(+), 4 deletions(-)
diff --git a/dtc-parser.y b/dtc-parser.y
index 002ea7f..ddb7f27 100644
--- a/dtc-parser.y
+++ b/dtc-parser.y
@@ -307,15 +307,25 @@ label:
%%
-void yyerror (char const *s)
+void yyerrorf(char const *s, ...)
{
const char *fname = srcpos_filename_for_num(yylloc.filenum);
+ va_list va;
+ va_start(va, s);
if (strcmp(fname, "-") == 0)
fname = "stdin";
- fprintf(stderr, "%s:%d %s\n",
- fname, yylloc.first_line, s);
+ fprintf(stderr, "%s:%d ", fname, yylloc.first_line);
+ vfprintf(stderr, s, va);
+ fprintf(stderr, "\n");
+
+ va_end(va);
+}
+
+void yyerror (char const *s)
+{
+ yyerrorf("%s", s);
}
unsigned long long eval_literal(const char *s, int base, int bits)
diff --git a/srcpos.h b/srcpos.h
index ce7ab5b..e59c788 100644
--- a/srcpos.h
+++ b/srcpos.h
@@ -63,6 +63,7 @@ typedef struct YYLTYPE {
extern void yyerror(char const *);
+extern void yyerrorf(char const *, ...) __attribute__((format(printf, 1, 2)));
extern int srcpos_filenum;
diff --git a/treesource.c b/treesource.c
index a6a7767..e7d580f 100644
--- a/treesource.c
+++ b/treesource.c
@@ -23,7 +23,6 @@
extern FILE *yyin;
extern int yyparse(void);
-extern void yyerror(char const *);
struct boot_info *the_boot_info;
--
1.5.3
^ permalink raw reply related
* Re: [PATCHv3] powerpc: DBox2 Board Support
From: David Gibson @ 2008-01-03 23:35 UTC (permalink / raw)
To: Jochen Friedrich
Cc: Scott Wood, linuxppc-dev, linux-kernel,
linuxppc-embedded@ozlabs.org
In-Reply-To: <477CCB0F.8020504@scram.de>
On Thu, Jan 03, 2008 at 12:46:23PM +0100, Jochen Friedrich wrote:
> Hi David,
>
> >> +/ {
> >> + model = "unknown,dbox2"; // boot wrapper fills in correct manufacturer
> >
> > Probably better just to leave model out of the dts and let the
> > bootwrapper add it.
>
> Unfortunately, dtc requires a model:
>
> $ dtc arch/powerpc/boot/dts/dbox2.dts
> DTC: dts->dts on file "arch/powerpc/boot/dts/dbox2.dts"
> ERROR: Missing "model" property in /
Ah. That should be gone in newer dtc versions. I'm pretty sure I got
rid of all checks that enforced the presence of particular properties,
precisely because they give frequent spurious errors when things are
supposed to be filled in by the bootloader.
[snip]
> >> + label = "Flash without bootloader";
> >> + reg = <20000 7e0000>;
> >> + };
> >> + ovpartition@0 {
> >> + label = "Complete Flash";
> >> + reg = <0 800000>;
> >> + read-only;
> >> + };
> >> + };
> >> + };
>
> MTD handles this correctly. dbox2 uses "Flash without bootloader"
> for flashing image updates and "Complete Flash" for creating a
> backup of everything. OpenWRT also uses overlapping partitions BTW
> (and also for flashing updates).
Heh. Wow. Safely? i.e. if you access one partition then later an
overlapping partition, is mtd guaranteed to get the necessary
synchronization right?
--
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 v3] powerpc: add hugepagesz boot-time parameter
From: Arnd Bergmann @ 2008-01-03 23:34 UTC (permalink / raw)
To: linuxppc-dev; +Cc: mel, Jon Tollefson, csnook, Paul Mackerras, David Gibson
In-Reply-To: <477D68E6.2070108@linux.vnet.ibm.com>
On Thursday 03 January 2008, Jon Tollefson wrote:
> Paul, please include this in 2.6.25 if there are no objections.
No objections to this version from me, just questions.
> This patch adds the hugepagesz boot-time parameter for ppc64. =A0It lets
> one pick the size for huge pages. The choices available are 64K and 16M
> when the base page size is 4k. It defaults to 16M (previously the only
> only choice) if nothing or an invalid choice is specified.
We started discussing this in v1, but the discussion got sidetracked:
Is there a technical reason why you don't also allow 1M pages, which
may be useful in certain scenarios?
On the Cell/B.E. platforms (IBM/Mercury blades, Toshiba Celleb, PS3), the
second large page size is an option that can be set in a HID SPR
to either 64KB or 1MB. Unfortunately, we can't do these two simultaneously,
but the firmware can change the default and put it into the device tree,
or you could have the kernel override the firmware settings.
Going a lot further, do you have plans for a fully dynamic hugepage size,
e.g. using a mount option for hugetlbfs? I can see that as rather useful,
but at the same time it's probably much more complicated than the boot time
option.
Arnd <><
^ permalink raw reply
* Re: [DTC] small ftdump cleanup patch
From: David Gibson @ 2008-01-03 23:25 UTC (permalink / raw)
To: Paul Gortmaker; +Cc: linuxppc-dev, jdl
In-Reply-To: <20080103144056.GB28644@windriver.com>
On Thu, Jan 03, 2008 at 09:40:57AM -0500, Paul Gortmaker wrote:
> Here is a small patch to clean up the usage info and the error returns
> for ftdump -- not sure what the future holds for ftdump vs. simply using
> "dtc -I dtb -O dts someblob.dtb" ...
I expect ftdump to stay around for the forseeable future as a
hacking/debugging tool; the idea is that it will be able to tell you
at least something about a malformed or corrupted dtb, whereas dtc is
likely to choke before producing any output. Any non-debugging use is
likely a mistake, though.
--
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: [alsa-devel] [PATCH] ASoC drivers for the Freescale MPC8610 SoC
From: Mark Brown @ 2008-01-03 23:13 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, alsa-devel, Timur Tabi
In-Reply-To: <477D3507.5090906@freescale.com>
On Thu, Jan 03, 2008 at 01:18:31PM -0600, Scott Wood wrote:
> Grant Likely wrote:
> > Gah! Don't do that! Then you need to maintain both directions in the
> > dts file. Software is good at generating reverse mappings.
> Software is, however, lousy at correctly wading through
> poorly-structured data (which device trees are full of) to figure out
> how to locate the link it wants to follow backwards.
Thinking about that from an ASoC v2 perspective the approach that this
immediately suggests is to represent the links between the devices in
the device tree and then have those links reference the attached
devices.
^ permalink raw reply
* Re: [alsa-devel] [PATCH] ASoC drivers for the Freescale MPC8610 SoC
From: Mark Brown @ 2008-01-03 23:00 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev, alsa-devel
In-Reply-To: <477D280C.4000800@freescale.com>
On Thu, Jan 03, 2008 at 12:23:08PM -0600, Timur Tabi wrote:
> Mark Brown wrote:
> > To cover everything you'd need to be able to specify all the clocking
> > parameters, especially a PLL configuration, and also specify more than
> > one of each item. Even then you'd still have problems like...
> The ASoC V1 API for communicating clock data from the fabric driver to the
> codec driver only allows for three parameters.
Each individual call to set_sysclk() only takes three parameters but it
can be called repeatedly and some configurations are going to require
this. There's also the set_pll() call which will be required by some
things too (and again that can support multiple PLLs).
For example, something like this isn't unknown:
- Set PLL input to pin A.
- Configure PLL input/output frequencies.
- Set codec system clock source to be the PLL
and of course the ordering matters. You can also have other dividers
and clock sources within the codec which need configuring and other
components outside the codec which need configuring to supply the clocks
to the codec.
> > According to the documentation in your patch the bus frequency should
> > already be optional
> My code does not currently support that configuration, and I don't have any
> hardware that works that way, so I don't know what it would look like. I'm
> just trying to make the driver as flexible as possible, given ASoC V1 constraints.
Indeed. Providing the device tree stuff doesn't get set in stone I'm
not sure we need to nail this down perfectly for ASoC v1 when we're
running into trouble working around it.
^ 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