Re: [PATCH 1/2] of: Add support for linking device tree blobs into vmlinux
On 11/15/2010 09:17 PM, Grant Likely wrote: On Mon, Nov 15, 2010 at 10:06 PM, Dirk Brandewie wrote: On 11/15/2010 08:41 PM, Grant Likely wrote: On Mon, Nov 15, 2010 at 08:01:20PM -0800, dirk.brande...@gmail.com wrote: From: Dirk Brandewie This patch adds support for linking device tree blobs into vmlinux. The device tree blobs are placed in the init.data section. Signed-off-by: Dirk Brandewie --- include/asm-generic/vmlinux.lds.h | 19 +-- scripts/Makefile.lib | 17 + 2 files changed, 34 insertions(+), 2 deletions(-) diff --git a/include/asm-generic/vmlinux.lds.h b/include/asm-generic/vmlinux.lds.h index bd69d79..ea671e7 100644 --- a/include/asm-generic/vmlinux.lds.h +++ b/include/asm-generic/vmlinux.lds.h @@ -67,7 +67,14 @@ * Align to a 32 byte boundary equal to the * alignment gcc 4.5 uses for a struct */ -#define STRUCT_ALIGN() . = ALIGN(32) +#define STRUCT_ALIGNMENT 32 +#define STRUCT_ALIGN() . = ALIGN(STRUCT_ALIGNMENT) + +/* Device tree blobs linked into the kernel need to have proper + * structure alignment to be parsed by the flat device tree library + * used in early boot +*/ +#define DTB_ALIGNMENT STRUCT_ALIGNMENT /* The actual configuration determine if the init/exit sections * are handled as text/data or they can be discarded (which @@ -146,6 +153,13 @@ #define TRACE_SYSCALLS() #endif + +#define KERNEL_DTB() \ + . = ALIGN(DTB_ALIGNMENT); \ + VMLINUX_SYMBOL(__dtb_start) = .;\ + *(.dtb.init.rodata) \ + VMLINUX_SYMBOL(__dtb_end) = .; + /* .data section */ #define DATA_DATA \ *(.data)\ @@ -468,7 +482,8 @@ MCOUNT_REC()\ DEV_DISCARD(init.rodata)\ CPU_DISCARD(init.rodata)\ - MEM_DISCARD(init.rodata) + MEM_DISCARD(init.rodata)\ + KERNEL_DTB() #define INIT_TEXT \ *(.init.text) \ diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib index 4c72c11..a8a4774 100644 --- a/scripts/Makefile.lib +++ b/scripts/Makefile.lib @@ -200,6 +200,23 @@ quiet_cmd_gzip = GZIP$@ cmd_gzip = (cat $(filter-out FORCE,$^) | gzip -f -9>$@) || \ (rm -f $@ ; false) +# DTC +# --- +$(obj)/%.dtb.S: $(obj)/%.dtb FORCE + @echo '#include'>$@ + @echo '.section .dtb.init.rodata,"a"'>>$@ + @echo '.balign DTB_ALIGNMENT'>>$@ + @echo '.global __dtb_$(*F)_begin'>>$@ + @echo '__dtb_$(*F)_begin:'>>$@ + @echo '.incbin "$<" '>>$@ + @echo '__dtb_$(*F)_end:'>>$@ + @echo '.global __dtb_$(*F)_end'>>$@ + @echo '.balign DTB_ALIGNMENT'>>$@ + +DTC = $(objtree)/scripts/dtc/dtc + +quiet_cmd_dtc = DTC$@ + cmd_dtc = $(DTC) -O dtb -o $(obj)/$*.dtb -b 0 $(src)/$*.dts Missing the %.dtb: %.dts rule, but otherwise looks okay. You will need to make sure this doesn't break powerpc or microblaze when the dts->dtb rule is added. I have the rule $(obj)/%.dtb: $(src)/%.dts $(call if_changed,dtc) in the arch/x86/kernel/Makefile to prevent this sneaking into other other architectures. This rule looks correct. PowerPC and Microblaze need to be modified to use it. It should not be hard to do, give it a try. Worst case, your first attempt is wrong and the rest of us fix it up. :-) Hint: PowerPC currently puts the .dtb file in a different directory from the source .dts file. It doesn't need to do it that way. arch/powerpc/boot/Makefile will need to be modified. I will give it a shot. The only real difference except for the directory structures is powerpc and microblaze add padding to the dtb with the -p 1024 command line argument to dtc. Is the padding needed when the blob are linked into vmlinux proper? --Dirk ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/2] of: Add support for linking device tree blobs into vmlinux
On Mon, Nov 15, 2010 at 10:28 PM, Dirk Brandewie wrote: > On 11/15/2010 09:17 PM, Grant Likely wrote: >> >> On Mon, Nov 15, 2010 at 10:06 PM, Dirk Brandewie >> wrote: >>> >>> On 11/15/2010 08:41 PM, Grant Likely wrote: On Mon, Nov 15, 2010 at 08:01:20PM -0800, dirk.brande...@gmail.com wrote: > > From: Dirk Brandewie > > This patch adds support for linking device tree blobs into > vmlinux. The device tree blobs are placed in the init.data > section. > > Signed-off-by: Dirk Brandewie > --- > include/asm-generic/vmlinux.lds.h | 19 +-- > scripts/Makefile.lib | 17 + > 2 files changed, 34 insertions(+), 2 deletions(-) > > diff --git a/include/asm-generic/vmlinux.lds.h > b/include/asm-generic/vmlinux.lds.h > index bd69d79..ea671e7 100644 > --- a/include/asm-generic/vmlinux.lds.h > +++ b/include/asm-generic/vmlinux.lds.h > @@ -67,7 +67,14 @@ > * Align to a 32 byte boundary equal to the > * alignment gcc 4.5 uses for a struct > */ > -#define STRUCT_ALIGN() . = ALIGN(32) > +#define STRUCT_ALIGNMENT 32 > +#define STRUCT_ALIGN() . = ALIGN(STRUCT_ALIGNMENT) > + > +/* Device tree blobs linked into the kernel need to have proper > + * structure alignment to be parsed by the flat device tree library > + * used in early boot > +*/ > +#define DTB_ALIGNMENT STRUCT_ALIGNMENT > > /* The actual configuration determine if the init/exit sections > * are handled as text/data or they can be discarded (which > @@ -146,6 +153,13 @@ > #define TRACE_SYSCALLS() > #endif > > + > +#define KERNEL_DTB() > \ > + . = ALIGN(DTB_ALIGNMENT); > \ > + VMLINUX_SYMBOL(__dtb_start) = .; > \ > + *(.dtb.init.rodata) > \ > + VMLINUX_SYMBOL(__dtb_end) = .; > + > /* .data section */ > #define DATA_DATA > \ > *(.data) > \ > @@ -468,7 +482,8 @@ > MCOUNT_REC() > \ > DEV_DISCARD(init.rodata) > \ > CPU_DISCARD(init.rodata) > \ > - MEM_DISCARD(init.rodata) > + MEM_DISCARD(init.rodata) > \ > + KERNEL_DTB() > > #define INIT_TEXT > \ > *(.init.text) > \ > diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib > index 4c72c11..a8a4774 100644 > --- a/scripts/Makefile.lib > +++ b/scripts/Makefile.lib > @@ -200,6 +200,23 @@ quiet_cmd_gzip = GZIP $@ > cmd_gzip = (cat $(filter-out FORCE,$^) | gzip -f -9> $@) || \ > (rm -f $@ ; false) > > +# DTC > +# > > --- > +$(obj)/%.dtb.S: $(obj)/%.dtb FORCE > + @echo '#include'> $@ > + @echo '.section .dtb.init.rodata,"a"'>> $@ > + @echo '.balign DTB_ALIGNMENT'>> $@ > + @echo '.global __dtb_$(*F)_begin'>> $@ > + @echo '__dtb_$(*F)_begin:'>> $@ > + @echo '.incbin "$<" '>> $@ > + @echo '__dtb_$(*F)_end:'>> $@ > + @echo '.global __dtb_$(*F)_end'>> $@ > + @echo '.balign DTB_ALIGNMENT'>> $@ > + > +DTC = $(objtree)/scripts/dtc/dtc > + > +quiet_cmd_dtc = DTC $@ > + cmd_dtc = $(DTC) -O dtb -o $(obj)/$*.dtb -b 0 $(src)/$*.dts Missing the %.dtb: %.dts rule, but otherwise looks okay. You will need to make sure this doesn't break powerpc or microblaze when the dts->dtb rule is added. >>> I have the rule >>> $(obj)/%.dtb: $(src)/%.dts >>> $(call if_changed,dtc) >>> in the arch/x86/kernel/Makefile to prevent this sneaking into other other >>> architectures. >> >> This rule looks correct. PowerPC and Microblaze need to be modified >> to use it. It should not be hard to do, give it a try. Worst case, >> your first attempt is wrong and the rest of us fix it up. :-) >> >> Hint: PowerPC currently puts the .dtb file in a different directory >> from the source .dts file. It doesn't need to do it that way. >> arch/powerpc/boot/Makefile will need to be modified. >> > > I will give it a shot. The only real difference except for the directory > structures is powerpc and microblaze add padding to the dtb with the -p 1024 > command line argument to dtc. You could use a $(DTCFLAGS) variable to pass in arch specific flags. > Is the padding needed when the blob are > linked into vmlinux proper? Maybe, maybe not. Padding is required to be able to modify the .dtb data in-place, which is important when adapting data from other sources into the device tree structure. However, when it is linked into the kernel, the adding of additional data /possibly/ can be deferred until after the tree is either copied or unflattened. g. ___ Linuxppc-dev mailing list Lin
Re: [PATCH 1/2] of: Add support for linking device tree blobs into vmlinux
On Mon, Nov 15, 2010 at 10:06 PM, Dirk Brandewie wrote: > On 11/15/2010 08:41 PM, Grant Likely wrote: >> >> On Mon, Nov 15, 2010 at 08:01:20PM -0800, dirk.brande...@gmail.com wrote: >>> >>> From: Dirk Brandewie >>> >>> This patch adds support for linking device tree blobs into >>> vmlinux. The device tree blobs are placed in the init.data >>> section. >>> >>> Signed-off-by: Dirk Brandewie >>> --- >>> include/asm-generic/vmlinux.lds.h | 19 +-- >>> scripts/Makefile.lib | 17 + >>> 2 files changed, 34 insertions(+), 2 deletions(-) >>> >>> diff --git a/include/asm-generic/vmlinux.lds.h >>> b/include/asm-generic/vmlinux.lds.h >>> index bd69d79..ea671e7 100644 >>> --- a/include/asm-generic/vmlinux.lds.h >>> +++ b/include/asm-generic/vmlinux.lds.h >>> @@ -67,7 +67,14 @@ >>> * Align to a 32 byte boundary equal to the >>> * alignment gcc 4.5 uses for a struct >>> */ >>> -#define STRUCT_ALIGN() . = ALIGN(32) >>> +#define STRUCT_ALIGNMENT 32 >>> +#define STRUCT_ALIGN() . = ALIGN(STRUCT_ALIGNMENT) >>> + >>> +/* Device tree blobs linked into the kernel need to have proper >>> + * structure alignment to be parsed by the flat device tree library >>> + * used in early boot >>> +*/ >>> +#define DTB_ALIGNMENT STRUCT_ALIGNMENT >>> >>> /* The actual configuration determine if the init/exit sections >>> * are handled as text/data or they can be discarded (which >>> @@ -146,6 +153,13 @@ >>> #define TRACE_SYSCALLS() >>> #endif >>> >>> + >>> +#define KERNEL_DTB() \ >>> + . = ALIGN(DTB_ALIGNMENT); \ >>> + VMLINUX_SYMBOL(__dtb_start) = .; \ >>> + *(.dtb.init.rodata) \ >>> + VMLINUX_SYMBOL(__dtb_end) = .; >>> + >>> /* .data section */ >>> #define DATA_DATA \ >>> *(.data) \ >>> @@ -468,7 +482,8 @@ >>> MCOUNT_REC() \ >>> DEV_DISCARD(init.rodata) \ >>> CPU_DISCARD(init.rodata) \ >>> - MEM_DISCARD(init.rodata) >>> + MEM_DISCARD(init.rodata) \ >>> + KERNEL_DTB() >>> >>> #define INIT_TEXT \ >>> *(.init.text) \ >>> diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib >>> index 4c72c11..a8a4774 100644 >>> --- a/scripts/Makefile.lib >>> +++ b/scripts/Makefile.lib >>> @@ -200,6 +200,23 @@ quiet_cmd_gzip = GZIP $@ >>> cmd_gzip = (cat $(filter-out FORCE,$^) | gzip -f -9> $@) || \ >>> (rm -f $@ ; false) >>> >>> +# DTC >>> +# >>> --- >>> +$(obj)/%.dtb.S: $(obj)/%.dtb FORCE >>> + @echo '#include'> $@ >>> + @echo '.section .dtb.init.rodata,"a"'>> $@ >>> + @echo '.balign DTB_ALIGNMENT'>> $@ >>> + @echo '.global __dtb_$(*F)_begin'>> $@ >>> + @echo '__dtb_$(*F)_begin:'>> $@ >>> + @echo '.incbin "$<" '>> $@ >>> + @echo '__dtb_$(*F)_end:'>> $@ >>> + @echo '.global __dtb_$(*F)_end'>> $@ >>> + @echo '.balign DTB_ALIGNMENT'>> $@ >>> + >>> +DTC = $(objtree)/scripts/dtc/dtc >>> + >>> +quiet_cmd_dtc = DTC $@ >>> + cmd_dtc = $(DTC) -O dtb -o $(obj)/$*.dtb -b 0 $(src)/$*.dts >> >> Missing the %.dtb: %.dts rule, but otherwise looks okay. You will >> need to make sure this doesn't break powerpc or microblaze when the >> dts->dtb rule is added. >> > I have the rule > $(obj)/%.dtb: $(src)/%.dts > $(call if_changed,dtc) > in the arch/x86/kernel/Makefile to prevent this sneaking into other other > architectures. This rule looks correct. PowerPC and Microblaze need to be modified to use it. It should not be hard to do, give it a try. Worst case, your first attempt is wrong and the rest of us fix it up. :-) Hint: PowerPC currently puts the .dtb file in a different directory from the source .dts file. It doesn't need to do it that way. arch/powerpc/boot/Makefile will need to be modified. g. > > I need some more skilled in kbuild to help craft the more generic rule so we > can have the dts files anywhere in the arch/<*>/ directory structure and be > able to find the correct dts files. > > --Dirk > -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] Move ams driver to macintosh
On Tue, 2010-10-05 at 12:10 +0200, Jean Delvare wrote:
> The ams driver isn't a hardware monitoring driver, so it shouldn't
> live under driver/hwmon. drivers/macintosh seems much more
> appropriate, as the driver is only useful on PowerBooks and iBooks.
Going through backlog... Do you want me to carry this in powerpc or
you'll deal with it directly ?
> Signed-off-by: Jean Delvare
> Cc: Guenter Roeck
> Cc: Stelian Pop
> Cc: Michael Hanselmann
Acked-by: Benjamin Herrenschmidt
> Cc: Grant Likely
> ---
> MAINTAINERS |2
> drivers/hwmon/Kconfig | 26 ---
> drivers/hwmon/Makefile|1
> drivers/hwmon/ams/Makefile|8 -
> drivers/hwmon/ams/ams-core.c | 250 -
> drivers/hwmon/ams/ams-i2c.c | 277
> -
> drivers/hwmon/ams/ams-input.c | 157
> drivers/hwmon/ams/ams-pmu.c | 201 --
> drivers/hwmon/ams/ams.h | 70 -
> drivers/macintosh/Kconfig | 26 +++
> drivers/macintosh/Makefile|2
> drivers/macintosh/ams/Makefile|8 +
> drivers/macintosh/ams/ams-core.c | 250 +
> drivers/macintosh/ams/ams-i2c.c | 277
> +
> drivers/macintosh/ams/ams-input.c | 157
> drivers/macintosh/ams/ams-pmu.c | 201 ++
> drivers/macintosh/ams/ams.h | 70 +
> 17 files changed, 992 insertions(+), 991 deletions(-)
>
> --- linux-2.6.36-rc6.orig/drivers/hwmon/ams/Makefile 2010-08-02
> 00:11:14.0 +0200
> +++ /dev/null 1970-01-01 00:00:00.0 +
> @@ -1,8 +0,0 @@
> -#
> -# Makefile for Apple Motion Sensor driver
> -#
> -
> -ams-y:= ams-core.o ams-input.o
> -ams-$(CONFIG_SENSORS_AMS_PMU)+= ams-pmu.o
> -ams-$(CONFIG_SENSORS_AMS_I2C)+= ams-i2c.o
> -obj-$(CONFIG_SENSORS_AMS)+= ams.o
> --- linux-2.6.36-rc6.orig/drivers/hwmon/ams/ams-core.c2010-08-02
> 00:11:14.0 +0200
> +++ /dev/null 1970-01-01 00:00:00.0 +
> @@ -1,250 +0,0 @@
> -/*
> - * Apple Motion Sensor driver
> - *
> - * Copyright (C) 2005 Stelian Pop (stel...@popies.net)
> - * Copyright (C) 2006 Michael Hanselmann (linux-ker...@hansmi.ch)
> - *
> - * This program is free software; you can redistribute it and/or modify
> - * it under the terms of the GNU General Public License as published by
> - * the Free Software Foundation; either version 2 of the License, or
> - * (at your option) any later version.
> - *
> - * This program is distributed in the hope that it will be useful,
> - * but WITHOUT ANY WARRANTY; without even the implied warranty of
> - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> - * GNU General Public License for more details.
> - *
> - * You should have received a copy of the GNU General Public License
> - * along with this program; if not, write to the Free Software
> - * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301,
> USA.
> - */
> -
> -#include
> -#include
> -#include
> -#include
> -#include
> -#include
> -
> -#include "ams.h"
> -
> -/* There is only one motion sensor per machine */
> -struct ams ams_info;
> -
> -static unsigned int verbose;
> -module_param(verbose, bool, 0644);
> -MODULE_PARM_DESC(verbose, "Show free falls and shocks in kernel output");
> -
> -/* Call with ams_info.lock held! */
> -void ams_sensors(s8 *x, s8 *y, s8 *z)
> -{
> - u32 orient = ams_info.vflag? ams_info.orient1 : ams_info.orient2;
> -
> - if (orient & 0x80)
> - /* X and Y swapped */
> - ams_info.get_xyz(y, x, z);
> - else
> - ams_info.get_xyz(x, y, z);
> -
> - if (orient & 0x04)
> - *z = ~(*z);
> - if (orient & 0x02)
> - *y = ~(*y);
> - if (orient & 0x01)
> - *x = ~(*x);
> -}
> -
> -static ssize_t ams_show_current(struct device *dev,
> - struct device_attribute *attr, char *buf)
> -{
> - s8 x, y, z;
> -
> - mutex_lock(&ams_info.lock);
> - ams_sensors(&x, &y, &z);
> - mutex_unlock(&ams_info.lock);
> -
> - return snprintf(buf, PAGE_SIZE, "%d %d %d\n", x, y, z);
> -}
> -
> -static DEVICE_ATTR(current, S_IRUGO, ams_show_current, NULL);
> -
> -static void ams_handle_irq(void *data)
> -{
> - enum ams_irq irq = *((enum ams_irq *)data);
> -
> - spin_lock(&ams_info.irq_lock);
> -
> - ams_info.worker_irqs |= irq;
> - schedule_work(&ams_info.worker);
> -
> - spin_unlock(&ams_info.irq_lock);
> -}
> -
> -static enum ams_irq ams_freefall_irq_data = AMS_IRQ_FREEFALL;
> -static struct pmf_irq_client ams_freefall_client = {
> - .owner = THIS_MODULE,
> - .handler = ams_handle_irq,
> - .data = &ams_freefall_irq_data,
> -};
> -
> -static enum ams_irq ams_shock_irq_data = AMS_IRQ_SHOCK;
Re: Can't boot benh/powerpc.git kernel
In message <1289520464.4752.12.ca...@localhost> you wrote: > On Thu, 2010-11-11 at 09:06 +1100, Benjamin Herrenschmidt wrote: > > On Wed, 2010-11-10 at 11:54 -0800, Jim Keniston wrote: > > > I got Ben's linux/kernel/git/benh/powerpc.git source and built it > > > (.config file attached*). It hangs on boot. When I boot it with > > > loglevel=8, its last words are: > > > > First, please try with Linus upstream. The "master" branch in my git > > tree is quite stale, and my next and merge branch are too at the moment > > as I'm still travelling. All our current stuff was merged during the > > last merge window so there's nothing "new" for you to pickup in my tree > > at the moment :-) > > > > If the problem still occurs, I'll have a look next week. > > > > Cheers, > > Ben. > > I built from Linus's git tree, and that kernel doesn't boot, either. > (It doesn't hang, but rather panics during boot. I can provide a > console log if you like.) Yes please. Linus' tree with pseries_defconfig boots fine for me on my POWER5 box. > v2.6.36 and v2.6.37-rc1 boot fine for me. I'll post my nvram-related > patches against v2.6.37-rc1. So it's broken between 37-rc1 and whereever you grabbed Linus tree. That's a fairly small window. Can you bisect it? Mikey ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH][v3] fsl_rio: move machine_check handler into machine_check_e500 & machine_check_e500mc
> -Original Message-
> From: Bounine, Alexandre [mailto:alexandre.boun...@idt.com]
> Sent: Saturday, November 13, 2010 12:30 AM
> To: Xie Shaohui-B21989; linuxppc-dev@lists.ozlabs.org
> Cc: a...@linux-foundation.org; Li Yang-R58472; Gala Kumar-B11780; Zang
> Roy-R61911
> Subject: RE: [PATCH][v3] fsl_rio: move machine_check handler into
> machine_check_e500 & machine_check_e500mc
>
> > int machine_check_e500mc(struct pt_regs *regs) int
> > machine_check_e500(struct pt_regs *regs) {
> > unsigned long reason = get_mc_reason(regs);
> > + int ret = 0;
> > +
> > + if (reason & MCSR_BUS_RBERR) {
> > + ret = fsl_rio_mcheck_exception(regs);
> > + if (ret == 1)
> > + return ret;
> > + }
>
> Do we really need 'ret' variable here?
> There is no further use of it by the rest of the code.
> Maybe just return 1 here if fsl_rio_mcheck_exception() returns 1 ?
>
> >
Ok, I'll remove the ret, do you have any comment for the error handler
patch?
http://patchwork.ozlabs.org/patch/69962/
Thanks & Best Regards,
Shaohui
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 2/2] powerpc: pcm030/032: add pagesize to dts
On Mon, Nov 15, 2010 at 12:17:51PM -1000, Mitch Bradley wrote: > In general I think it's better to report parameter values directly, > instead of inferring them from manufacturer and part numbers. That > way you at least have a fighting chance of avoiding a kernel upgrade > when a part changes. I tend to agree. Although a fallback to deducing from the manufacturer / part id if the pagesize property is missing would be sensible. -- 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 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 2/2] powerpc: pcm030/032: add pagesize to dts
> > >I think you'd better drop the pagesize property altogether, and > > >instead make the compatible string more specific (if needed at > > >all. are there any 'catalyst,24c32' chips with pagesize != 32?) > > > > Microchip makes a 24c32 part that looks pretty similar to the > > catalyst part, but Microchip's has a 64-byte page size compared to > > Catalyst's 32. > > Well, when using microchip part, the compatible string would be > "microchip,24c32", correct? Then we have all the information > already, no need for the pagesize. Hmm, there are myriads of I2C eeproms out there, this table would be enourmous. Even worse, I seem to recall that I had once seen a manufacturer increasing the page-size from one charge to the next without changing the part-number, so I got this feeling "you can't map pagesize to manufacturer/type" which I still have. Sadly, this was long ago, so I can't proof it right now. Will try to dig up some datasheets when in the office tomorrow. In general, I2C EEPROMs are really a mess, the basic access method is the same, but except that everything else is possible :) Thus, this approach. Thus, this approach. Regards, Wolfram -- Pengutronix e.K. | Wolfram Sang| Industrial Linux Solutions | http://www.pengutronix.de/ | signature.asc Description: Digital signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 2/2] powerpc: pcm030/032: add pagesize to dts
In general I think it's better to report parameter values directly, instead of inferring them from manufacturer and part numbers. That way you at least have a fighting chance of avoiding a kernel upgrade when a part changes. Of course, that only works when the device tree is exported from the boot firmware instead of having to carry the device tree inside the kernel. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 2/2] powerpc: pcm030/032: add pagesize to dts
On Mon, Nov 15, 2010 at 2:24 PM, Anton Vorontsov wrote:
> On Mon, Nov 15, 2010 at 11:06:44AM -1000, Mitch Bradley wrote:
> [...]
>> >> eep...@52 {
>> >> compatible = "catalyst,24c32";
>> >> reg =<0x52>;
>> >>+ pagesize =<32>;
>> >
>> >I think you'd better drop the pagesize property altogether, and
>> >instead make the compatible string more specific (if needed at
>> >all. are there any 'catalyst,24c32' chips with pagesize != 32?)
>>
>> Microchip makes a 24c32 part that looks pretty similar to the
>> catalyst part, but Microchip's has a 64-byte page size compared to
>> Catalyst's 32.
>
> Well, when using microchip part, the compatible string would be
> "microchip,24c32", correct? Then we have all the information
> already, no need for the pagesize.
>
>> It would probably be feasible to have a generic I2C EEPROM driver
>> that could handle many different parts, parameterized by total size,
>> block size, and page size.
The current at24.c driver is already parameterized; but part of the
parameter data is statically linked into the board support code.
>
> I guess it can do this already via I2C ID table. The problem
> is that I2C core is only using part ID (no vendor ID matching).
This could potentially be changed for at24 devices since the i2c
subsystem already matches by name. It would mean adding the vendor
prefix to all instantiations of the device in the kernel, although it
would mess up the current heuristic used by of_modalias_node() (not a
show-stopper).
>
> So, the current driver may just implement quirks like this:
>
> if (of_device_is_compatible(np, "catalyst,24c32"))
> pagesize = 32;
>
> Or, if it's some generic pattern, something like
>
> if (of_device_is_compatible_vendor(np, "catalyst"))
> pagesize /= 2;
This would get ugly in a hurry. It would be better to make it data
driven by searching for a better match in an of_device_id table so
that the workarounds don't grow over time and eventually achieve
sentience.
g.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/2] misc: at24: parse OF-data, too
On Mon, Nov 15, 2010 at 10:25 AM, Wolfram Sang wrote:
> Information about the pagesize and read-only-status may also come from
> the devicetree. Parse this data, too, and act accordingly. While we are
> here, change the initialization printout a bit. write_max is useful to
> know to detect performance bottlenecks, the rest is superfluous.
>
> Signed-off-by: Wolfram Sang
> ---
>
> Grant: As mentioned at ELCE10, I could pretty much respin this old approach I
> tried roughly a year ago (just with archdata then). If the approach and docs
> are good, I am fine with the patches entering via one of your trees.
>
> Documentation/powerpc/dts-bindings/eeprom.txt | 28 ++
> drivers/misc/eeprom/at24.c | 33
> -
> 2 files changed, 53 insertions(+), 6 deletions(-)
> create mode 100644 Documentation/powerpc/dts-bindings/eeprom.txt
>
> diff --git a/Documentation/powerpc/dts-bindings/eeprom.txt
> b/Documentation/powerpc/dts-bindings/eeprom.txt
> new file mode 100644
> index 000..4342c10
> --- /dev/null
> +++ b/Documentation/powerpc/dts-bindings/eeprom.txt
> @@ -0,0 +1,28 @@
> +EEPROMs (I2C)
> +
> +Required properties:
> +
> + - compatible : should be ","
> + If there is no specific driver for , a generic
> + driver based on is selected. Possible types are:
> + 24c00, 24c01, 24c02, 24c04, 24c08, 24c16, 24c32, 24c64,
> + 24c128, 24c256, 24c512, 24c1024, spd
> +
> + - reg : the I2C address of the EEPROM
> +
> +Optional properties:
> +
> + - pagesize : the length of the pagesize for writing. Please consult the
> + manual of your device, that value varies a lot. A wrong value
> + may result in data loss! If not specified, a safety value of
> + '1' is used which will be very slow.
As Anton mentions, the compatible value should be specific enough that
a pagesize property isn't needed (assuming there aren't at24 devices
with differing page sizes), but that leaves the question of where to
put the page size data in the driver. I think the obvious answer is
to put it in the at24_ids table. This would also be a good thing for
the non-OF use-cases too. Unfortunately the driver_data field is
already in use and requires refactoring to turn driver_data into a
pointer to a structure, and so requires more work (sorry).
A refactored at24_ids table might look something like (there may be a
cleaner way to go about it though, I used the macro to solve the
problem of constructing an at24_platform_data structure for each entry
and storing a pointer to it in the unsigned long driver_data field):
#define AT24_DEVDATA(_len, _page_size, _flags) \
((unsigned long)((struct at24_platform_data[]) \
{{.byte_len = len, .page_size = _page_size, .flags =
_flags}}))
static const struct i2c_device_id at24_ids[] = {
/* needs 8 addresses as A0-A2 are ignored */
{ "24c00", AT24_DEVDATA(128 / 8, 16, AT24_FLAG_TAKE8ADDR) },
/* old variants can't be handled with this generic entry! */
{ "24c01", AT24_DEVDATA(1024 / 8, 16, 0) },
{ "24c02", AT24_DEVDATA(2048 / 8, 16, 0) },
...
};
This will also make the probe code simpler.
However, if I am wrong and similarly named at24 devices have different
page sizes, then encoding it in a property is the right thing to do.
Also, the read-only property is fine.
g.
> +
> + - read-only: this parameterless property disables writes to the eeprom
> +
> +Example:
> +
> +eep...@52 {
> + compatible = "atmel,24c32";
> + reg = <0x52>;
> + pagesize = <32>;
> +};
> diff --git a/drivers/misc/eeprom/at24.c b/drivers/misc/eeprom/at24.c
> index 559b0b3..aaf16cb 100644
> --- a/drivers/misc/eeprom/at24.c
> +++ b/drivers/misc/eeprom/at24.c
> @@ -20,6 +20,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
>
> @@ -457,6 +458,27 @@ static ssize_t at24_macc_write(struct memory_accessor
> *macc, const char *buf,
>
> /*-*/
>
> +#ifdef CONFIG_OF
> +static void at24_get_ofdata(struct i2c_client *client,
> + struct at24_platform_data *chip)
> +{
> + const u32 *val;
> + struct device_node *node = client->dev.of_node;
> +
> + if (node) {
> + if (of_get_property(node, "read-only", NULL))
> + chip->flags |= AT24_FLAG_READONLY;
> + val = of_get_property(node, "pagesize", NULL);
> + if (val)
> + chip->page_size = *val;
> + }
> +}
> +#else
> +static void at24_get_ofdata(struct i2c_client *client,
> + struct at24_platform_data *chip)
> +{ }
> +#endif /* CONFIG_OF */
> +
> static int at24_probe(struct i2c_client *client, const struct i2c_device_id
> *id)
> {
> struct at24_platform_data chip;
> @@ -485,6 +507,9 @@ static i
Re: [PATCH 2/2] powerpc: pcm030/032: add pagesize to dts
On Mon, Nov 15, 2010 at 11:06:44AM -1000, Mitch Bradley wrote:
[...]
> >>eep...@52 {
> >>compatible = "catalyst,24c32";
> >>reg =<0x52>;
> >>+ pagesize =<32>;
> >
> >I think you'd better drop the pagesize property altogether, and
> >instead make the compatible string more specific (if needed at
> >all. are there any 'catalyst,24c32' chips with pagesize != 32?)
>
> Microchip makes a 24c32 part that looks pretty similar to the
> catalyst part, but Microchip's has a 64-byte page size compared to
> Catalyst's 32.
Well, when using microchip part, the compatible string would be
"microchip,24c32", correct? Then we have all the information
already, no need for the pagesize.
> It would probably be feasible to have a generic I2C EEPROM driver
> that could handle many different parts, parameterized by total size,
> block size, and page size.
I guess it can do this already via I2C ID table. The problem
is that I2C core is only using part ID (no vendor ID matching).
So, the current driver may just implement quirks like this:
if (of_device_is_compatible(np, "catalyst,24c32"))
pagesize = 32;
Or, if it's some generic pattern, something like
if (of_device_is_compatible_vendor(np, "catalyst"))
pagesize /= 2;
Thanks,
--
Anton Vorontsov
email: cbouatmai...@gmail.com
irc://irc.freenode.net/bd2
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 2/2] powerpc: pcm030/032: add pagesize to dts
On 11/15/2010 7:32 AM, Anton Vorontsov wrote:
On Mon, Nov 15, 2010 at 06:25:16PM +0100, Wolfram Sang wrote:
Signed-off-by: Wolfram Sang
---
arch/powerpc/boot/dts/pcm030.dts |1 +
arch/powerpc/boot/dts/pcm032.dts |3 ++-
2 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/boot/dts/pcm030.dts b/arch/powerpc/boot/dts/pcm030.dts
index 8a4ec30..e7c36bc 100644
--- a/arch/powerpc/boot/dts/pcm030.dts
+++ b/arch/powerpc/boot/dts/pcm030.dts
@@ -259,6 +259,7 @@
eep...@52 {
compatible = "catalyst,24c32";
reg =<0x52>;
+ pagesize =<32>;
I think you'd better drop the pagesize property altogether, and
instead make the compatible string more specific (if needed at
all. are there any 'catalyst,24c32' chips with pagesize != 32?)
Microchip makes a 24c32 part that looks pretty similar to the catalyst
part, but Microchip's has a 64-byte page size compared to Catalyst's 32.
It would probably be feasible to have a generic I2C EEPROM driver that
could handle many different parts, parameterized by total size, block
size, and page size.
Thanks,
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v2] PPC4xx: Adding PCI(E) MSI support
From: Tirumala Marri
This patch adds MSI support for 440SPe, 460Ex, 460Sx and 405Ex.
Signed-off-by: Tirumala R Marri
---
v1:
* Get rid of bitmap functions.
* Remove irq mapping as each MSI is tied to UIC.
* Cleaning up of prints.
v2:
* Remove or add blank lines at appropriate places.
* Added BITMAP as it is easy to request and free the MSIs
* Removed UPPER_4BITS_OF36BIT & LOWER_32BITS_OF36BIT;
* Remove unused feature variable.
* Remove initialization of "virq".
* remove static int_no varaible and replace with bitmap.
* Eliminated reading count from DTS tree and added a macro.
* Remove printK.
* Remove else in setup_irqs.
* Free interrupts in teardown_msi_interrupts().
* Print contraints in check_device().
* Replace ioremap with of_iomap().
* Use msi_data in setup_pcieh_hw().
* Don't unmap in the setup_pcieh_hw().
* don't use WARN_ON.
* Remove ppc4xx_msi_ids[].
---
arch/powerpc/boot/dts/canyonlands.dts | 18 ++
arch/powerpc/boot/dts/katmai.dts | 18 ++
arch/powerpc/boot/dts/kilauea.dts | 28 +++
arch/powerpc/boot/dts/redwood.dts | 20 ++
arch/powerpc/platforms/40x/Kconfig|2 +
arch/powerpc/platforms/44x/Kconfig|6 +
arch/powerpc/sysdev/Kconfig |7 +
arch/powerpc/sysdev/Makefile |1 +
arch/powerpc/sysdev/ppc4xx_msi.c | 311 +
9 files changed, 411 insertions(+), 0 deletions(-)
create mode 100644 arch/powerpc/sysdev/ppc4xx_msi.c
diff --git a/arch/powerpc/boot/dts/canyonlands.dts
b/arch/powerpc/boot/dts/canyonlands.dts
index a303703..5a8e04e 100644
--- a/arch/powerpc/boot/dts/canyonlands.dts
+++ b/arch/powerpc/boot/dts/canyonlands.dts
@@ -519,5 +519,23 @@
0x0 0x0 0x0 0x3 &UIC3 0x12 0x4 /* swizzled int
C */
0x0 0x0 0x0 0x4 &UIC3 0x13 0x4 /* swizzled int
D */>;
};
+
+ MSI: ppc4xx-...@c1000 {
+ compatible = "amcc,ppc4xx-msi", "ppc4xx-msi";
+ reg = < 0xC 0x1000 0x100>;
+ sdr-base = <0x36C>;
+ msi-data = <0x>;
+ msi-mask = <0x>;
+ interrupt-count = <3>;
+ interrupts = <0 1 2 3>;
+ interrupt-parent = <&UIC3>;
+ #interrupt-cells = <1>;
+ #address-cells = <0>;
+ #size-cells = <0>;
+ interrupt-map = <0 &UIC3 0x18 1
+ 1 &UIC3 0x19 1
+ 2 &UIC3 0x1A 1
+ 3 &UIC3 0x1B 1>;
+ };
};
};
diff --git a/arch/powerpc/boot/dts/katmai.dts b/arch/powerpc/boot/dts/katmai.dts
index 7c3be5e..f913dbe 100644
--- a/arch/powerpc/boot/dts/katmai.dts
+++ b/arch/powerpc/boot/dts/katmai.dts
@@ -442,6 +442,24 @@
0x0 0x0 0x0 0x4 &UIC3 0xb 0x4 /* swizzled int D
*/>;
};
+ MSI: ppc4xx-...@40030 {
+ compatible = "amcc,ppc4xx-msi", "ppc4xx-msi";
+ reg = < 0x4 0x0030 0x100>;
+ sdr-base = <0x3B0>;
+ msi-data = <0x>;
+ msi-mask = <0x>;
+ interrupt-count = <3>;
+ interrupts =<0 1 2 3>;
+ interrupt-parent = <&UIC0>;
+ #interrupt-cells = <1>;
+ #address-cells = <0>;
+ #size-cells = <0>;
+ interrupt-map = <0 &UIC0 0xC 1
+ 1 &UIC0 0x0D 1
+ 2 &UIC0 0x0E 1
+ 3 &UIC0 0x0F 1>;
+ };
+
I2O: i...@40010 {
compatible = "ibm,i2o-440spe";
reg = <0x0004 0x0010 0x100>;
diff --git a/arch/powerpc/boot/dts/kilauea.dts
b/arch/powerpc/boot/dts/kilauea.dts
index 083e68e..21e88f5 100644
--- a/arch/powerpc/boot/dts/kilauea.dts
+++ b/arch/powerpc/boot/dts/kilauea.dts
@@ -394,5 +394,33 @@
0x0 0x0 0x0 0x3 &UIC2 0xd 0x4 /* swizzled int C
*/
0x0 0x0 0x0 0x4 &UIC2 0xe 0x4 /* swizzled int D
*/>;
};
+
+ MSI: ppc4xx-...@c1000 {
+ compatible = "amcc,ppc4xx-msi", "ppc4xx-msi";
+ reg = < 0x0 0xEF62 0x100>;
+ sdr-base = <0x4B0>;
+ msi-data = <0x>;
+ msi-mask = <0x>;
+ interrupt-count = <12>;
+ interrupts = <0 1 2 3 4 5 6 7 8 9 0
Re: [PATCH v2] fsldma: add support to 36-bit physical address
On Mon, 15 Nov 2010 11:43:12 -0600 Kumar Gala wrote: > > On Nov 15, 2010, at 10:13 AM, Timur Tabi wrote: > > > On Mon, Nov 15, 2010 at 9:16 AM, Kumar Gala > > wrote: > > > >> The programming model (if you look at the free-space in the registers and > >> data structures) supports a 64-bit address. I'm trying to avoid changing > >> the driver in the future if we have >36-bit. However this is such a minor > >> worry that I'll stop and just ack the patch as is. > > > > I must still be missing something. I'm looking at the description of > > the SATR register in the MPC8572 RM, and it shows this: > > > > 0 - 3 | 4 - 5 | 6 | 7 | 8 - 11 | 12 - 15 | 16-21 | > > 22-31 > > --- | STFLOWLVL | SPCIORDER | SSME | STRANSINT | SREADTTYPE | --- | ESAD > > > > The most that we can extend ESAD to is 16 bits, for a total of a > > 48-bit physical address. Where are the other 16 bits supposed to go? > > I was looking at the link addresses. I stand corrected so our max is 48-bits. Looks like 42 bits -- just because bits 16-21 could be used to extend ESAD doesn't mean that they have been. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2] fsldma: add support to 36-bit physical address
On Nov 15, 2010, at 10:13 AM, Timur Tabi wrote: > On Mon, Nov 15, 2010 at 9:16 AM, Kumar Gala wrote: > >> The programming model (if you look at the free-space in the registers and >> data structures) supports a 64-bit address. I'm trying to avoid changing >> the driver in the future if we have >36-bit. However this is such a minor >> worry that I'll stop and just ack the patch as is. > > I must still be missing something. I'm looking at the description of > the SATR register in the MPC8572 RM, and it shows this: > > 0 - 3 | 4 - 5 | 6 | 7 | 8 - 11 | 12 - 15 | 16-21 | 22-31 > --- | STFLOWLVL | SPCIORDER | SSME | STRANSINT | SREADTTYPE | --- | ESAD > > The most that we can extend ESAD to is 16 bits, for a total of a > 48-bit physical address. Where are the other 16 bits supposed to go? I was looking at the link addresses. I stand corrected so our max is 48-bits. - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2] fsldma: add support to 36-bit physical address
On Nov 11, 2010, at 6:16 AM, Li Yang wrote: > Expand the dma_mask of fsldma device to 36-bit, indicating that the > DMA engine can deal with 36-bit physical address and does not need > the SWIOTLB to create bounce buffer for it when doing dma_map_*(). > > Signed-off-by: Li Yang > --- > Add more detailed commit message > > drivers/dma/fsldma.c |4 +++- > 1 files changed, 3 insertions(+), 1 deletions(-) Acked-by: Kumar Gala - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 2/2] powerpc: pcm030/032: add pagesize to dts
On Mon, Nov 15, 2010 at 06:25:16PM +0100, Wolfram Sang wrote:
> Signed-off-by: Wolfram Sang
> ---
> arch/powerpc/boot/dts/pcm030.dts |1 +
> arch/powerpc/boot/dts/pcm032.dts |3 ++-
> 2 files changed, 3 insertions(+), 1 deletions(-)
>
> diff --git a/arch/powerpc/boot/dts/pcm030.dts
> b/arch/powerpc/boot/dts/pcm030.dts
> index 8a4ec30..e7c36bc 100644
> --- a/arch/powerpc/boot/dts/pcm030.dts
> +++ b/arch/powerpc/boot/dts/pcm030.dts
> @@ -259,6 +259,7 @@
> eep...@52 {
> compatible = "catalyst,24c32";
> reg = <0x52>;
> + pagesize = <32>;
I think you'd better drop the pagesize property altogether, and
instead make the compatible string more specific (if needed at
all. are there any 'catalyst,24c32' chips with pagesize != 32?)
Thanks,
--
Anton Vorontsov
email: cbouatmai...@gmail.com
irc://irc.freenode.net/bd2
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 2/2] powerpc: pcm030/032: add pagesize to dts
Signed-off-by: Wolfram Sang
---
arch/powerpc/boot/dts/pcm030.dts |1 +
arch/powerpc/boot/dts/pcm032.dts |3 ++-
2 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/boot/dts/pcm030.dts b/arch/powerpc/boot/dts/pcm030.dts
index 8a4ec30..e7c36bc 100644
--- a/arch/powerpc/boot/dts/pcm030.dts
+++ b/arch/powerpc/boot/dts/pcm030.dts
@@ -259,6 +259,7 @@
eep...@52 {
compatible = "catalyst,24c32";
reg = <0x52>;
+ pagesize = <32>;
};
};
diff --git a/arch/powerpc/boot/dts/pcm032.dts b/arch/powerpc/boot/dts/pcm032.dts
index 85d857a..e175e2c 100644
--- a/arch/powerpc/boot/dts/pcm032.dts
+++ b/arch/powerpc/boot/dts/pcm032.dts
@@ -257,8 +257,9 @@
reg = <0x51>;
};
eep...@52 {
- compatible = "at24,24c32";
+ compatible = "catalyst,24c32";
reg = <0x52>;
+ pagesize = <32>;
};
};
--
1.7.2.3
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 1/2] misc: at24: parse OF-data, too
Information about the pagesize and read-only-status may also come from
the devicetree. Parse this data, too, and act accordingly. While we are
here, change the initialization printout a bit. write_max is useful to
know to detect performance bottlenecks, the rest is superfluous.
Signed-off-by: Wolfram Sang
---
Grant: As mentioned at ELCE10, I could pretty much respin this old approach I
tried roughly a year ago (just with archdata then). If the approach and docs
are good, I am fine with the patches entering via one of your trees.
Documentation/powerpc/dts-bindings/eeprom.txt | 28 ++
drivers/misc/eeprom/at24.c| 33 -
2 files changed, 53 insertions(+), 6 deletions(-)
create mode 100644 Documentation/powerpc/dts-bindings/eeprom.txt
diff --git a/Documentation/powerpc/dts-bindings/eeprom.txt
b/Documentation/powerpc/dts-bindings/eeprom.txt
new file mode 100644
index 000..4342c10
--- /dev/null
+++ b/Documentation/powerpc/dts-bindings/eeprom.txt
@@ -0,0 +1,28 @@
+EEPROMs (I2C)
+
+Required properties:
+
+ - compatible : should be ","
+If there is no specific driver for , a generic
+driver based on is selected. Possible types are:
+24c00, 24c01, 24c02, 24c04, 24c08, 24c16, 24c32, 24c64,
+24c128, 24c256, 24c512, 24c1024, spd
+
+ - reg : the I2C address of the EEPROM
+
+Optional properties:
+
+ - pagesize : the length of the pagesize for writing. Please consult the
+ manual of your device, that value varies a lot. A wrong value
+ may result in data loss! If not specified, a safety value of
+ '1' is used which will be very slow.
+
+ - read-only: this parameterless property disables writes to the eeprom
+
+Example:
+
+eep...@52 {
+ compatible = "atmel,24c32";
+ reg = <0x52>;
+ pagesize = <32>;
+};
diff --git a/drivers/misc/eeprom/at24.c b/drivers/misc/eeprom/at24.c
index 559b0b3..aaf16cb 100644
--- a/drivers/misc/eeprom/at24.c
+++ b/drivers/misc/eeprom/at24.c
@@ -20,6 +20,7 @@
#include
#include
#include
+#include
#include
#include
@@ -457,6 +458,27 @@ static ssize_t at24_macc_write(struct memory_accessor
*macc, const char *buf,
/*-*/
+#ifdef CONFIG_OF
+static void at24_get_ofdata(struct i2c_client *client,
+ struct at24_platform_data *chip)
+{
+ const u32 *val;
+ struct device_node *node = client->dev.of_node;
+
+ if (node) {
+ if (of_get_property(node, "read-only", NULL))
+ chip->flags |= AT24_FLAG_READONLY;
+ val = of_get_property(node, "pagesize", NULL);
+ if (val)
+ chip->page_size = *val;
+ }
+}
+#else
+static void at24_get_ofdata(struct i2c_client *client,
+ struct at24_platform_data *chip)
+{ }
+#endif /* CONFIG_OF */
+
static int at24_probe(struct i2c_client *client, const struct i2c_device_id
*id)
{
struct at24_platform_data chip;
@@ -485,6 +507,9 @@ static int at24_probe(struct i2c_client *client, const
struct i2c_device_id *id)
*/
chip.page_size = 1;
+ /* update chipdata if OF is present */
+ at24_get_ofdata(client, &chip);
+
chip.setup = NULL;
chip.context = NULL;
}
@@ -597,19 +622,15 @@ static int at24_probe(struct i2c_client *client, const
struct i2c_device_id *id)
i2c_set_clientdata(client, at24);
- dev_info(&client->dev, "%zu byte %s EEPROM %s\n",
+ dev_info(&client->dev, "%zu byte %s EEPROM, %s, %u bytes/write\n",
at24->bin.size, client->name,
- writable ? "(writable)" : "(read-only)");
+ writable ? "writable" : "read-only", at24->write_max);
if (use_smbus == I2C_SMBUS_WORD_DATA ||
use_smbus == I2C_SMBUS_BYTE_DATA) {
dev_notice(&client->dev, "Falling back to %s reads, "
"performance will suffer\n", use_smbus ==
I2C_SMBUS_WORD_DATA ? "word" : "byte");
}
- dev_dbg(&client->dev,
- "page_size %d, num_addresses %d, write_max %d, use_smbus %d\n",
- chip.page_size, num_addresses,
- at24->write_max, use_smbus);
/* export data to kernel code */
if (chip.setup)
--
1.7.2.3
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2] fsldma: add support to 36-bit physical address
On Mon, Nov 15, 2010 at 9:16 AM, Kumar Gala wrote: > The programming model (if you look at the free-space in the registers and > data structures) supports a 64-bit address. I'm trying to avoid changing the > driver in the future if we have >36-bit. However this is such a minor worry > that I'll stop and just ack the patch as is. I must still be missing something. I'm looking at the description of the SATR register in the MPC8572 RM, and it shows this: 0 - 3 | 4 - 5 | 6 | 7 | 8 - 11 | 12 - 15 | 16-21 | 22-31 --- | STFLOWLVL | SPCIORDER | SSME | STRANSINT | SREADTTYPE | --- | ESAD The most that we can extend ESAD to is 16 bits, for a total of a 48-bit physical address. Where are the other 16 bits supposed to go? -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2] fsldma: add support to 36-bit physical address
On Nov 13, 2010, at 4:43 PM, Timur Tabi wrote: > On Thu, Nov 11, 2010 at 5:56 AM, Kumar Gala wrote: > >> Is there any reason we shouldn't set DMA_BIT_MASK(64) since the DMA block >> programming model allows the address to be 64-bits? > > Can you explain that? The DMA registers only have room for 36 bits > for the physical address. The programming model (if you look at the free-space in the registers and data structures) supports a 64-bit address. I'm trying to avoid changing the driver in the future if we have >36-bit. However this is such a minor worry that I'll stop and just ack the patch as is. - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
