* Re: [PATCH] 64K page support for kexec
From: Milton Miller @ 2007-04-25 5:48 UTC (permalink / raw)
To: Olof Johansson, Luke Browning, Benjamin Herrenschmidt; +Cc: ppcdev, cbe-oss-dev
In-Reply-To: <20070424230708.GA10401@lixom.net>
>
>
> > > > + /*
> > > > + * FIXME, this could be made more efficient by storing the type
> > > > + * of hash algorithm in mmu_psize_defs[]. The code below
> assumes
> > > > + * the number of bits in the va representing the offset in the
> > > > + * page is less than 23. This affects the hash algorithm that
> is
> > > > + * used. When 16G pages are supported, a new hash algorithm
> > > > + * needs to be provided. See POWER ISA Book III.
> > > > + *
> > > > + * The code below works for 16M, 64K, and 4K pages.
> > > > + */
> > >
> > > A BUG_ON() when other sizes are hit could be a good idea?
> >
> > a BUG_ON if the B bit is set would be useful too. (that is 1T segment
> > HPTE).
>
> Yep.
NNNNOOOOO!!!!
Do NOT add any BUG() is this code!
Look at the context:
(1) We are tearing down *ALL* mappings. That includes the
kernel linear mapping and the mapping of the kernel text.
(2) We are in real mode. There is no way back to virtural
mode. See (1).
(3) We hove put the new kernel in memory. There is no data
that was not a part of the static data or bss sections. There
are no per-cpu variables. Nothing with vmalloc. Nothing with
kmalloc. Nothing with alloc_pages.
(4) If this is the panic kernel case, we are allready crashed
and trying to get into a new envrionment to dump memory.
Intentionally failing that is the last thing you want to do.
(5) This hook is only used by kexec_sequence, called by
machine_kexec. At the beginning of that function there
is the comment "its too late to fail here."
Bottom line: Don't even think of causing any trap here, just
execute as best as you know how. You dohn't have any way to
tell the user you failed anyways.
milton
^ permalink raw reply
* Re: [PATCH] generic check_legacy_ioport
From: Arnd Bergmann @ 2007-04-25 7:49 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: Christian Krafft, Olaf Hering, linuxppc-dev
In-Reply-To: <0e76c9675bd1bcf4b7ed6bf83da8c3d7@kernel.crashing.org>
On Wednesday 25 April 2007, Segher Boessenkool wrote:
> > I don't think there are any powerpc machines where it can find=20
> > something
> > there, but we decided to leave the code architecture independent in
> > case there ever are, and just to add the check_legacy_ioport call in=20
> > there.
>=20
> SLOF/JS21 (at least some versions of it) have an "ipmi"
> node on the "isa" bus. =A0And the kernel ipmi driver actually
> works on it, too (no idea about the currently proposed
> scanning though -- but the principle is correct at least).
It won'd be found by the of_platform_driver part of ipmi,
since devices on the ISA bus do not get added to the linux
device tree.
If the ipmi node on the ISA bus is located at the standardized
legacy I/O port range, it should get found by the later probing,
if check_legacy_ioport allows it.
We might still want to have the driver use a proper of_device,
which would require the maple platform code to add this device
during probing.
Arnd <><
^ permalink raw reply
* Re: [PATCH 1/5] [PPC] Rework Kconfig dependancies for Xilinx Virtex ppc405 platform
From: Peter Korsgaard @ 2007-04-25 12:03 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <11766220692537-git-send-email-grant.likely@secretlab.ca>
>>>>> "GL" == Grant Likely <grant.likely@secretlab.ca> writes:
GL> Reverse dependency order for Xilinx Virtex parts. For these
GL> parts, It makes more sense for boards/chips to specify which
GL> features they provide instead of the features listing the parts
GL> they are implemented in. I think it also makes adding new board
GL> ports simpler.
GL> Signed-off-by: Grant Likely <grant.likely@secretlab.ca> ---
Acked-by: Peter Korsgaard <jacmet@sunsite.dk>
--
Bye, Peter Korsgaard
^ permalink raw reply
* Re: [PATCH 2/5] [PPC] Merge common virtex header files
From: Peter Korsgaard @ 2007-04-25 12:07 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <11766220693636-git-send-email-grant.likely@secretlab.ca>
>>>>> "GL" == Grant Likely <grant.likely@secretlab.ca> writes:
Hi,
GL> The header files for the ml403 and ml300 are virtually identical,
GL> merge them into a single file.
GL> diff --git a/include/asm-ppc/ibm4xx.h b/include/asm-ppc/ibm4xx.h
GL> index 92fd02d..ed6891a 100644
GL> --- a/include/asm-ppc/ibm4xx.h
GL> +++ b/include/asm-ppc/ibm4xx.h
GL> @@ -47,12 +47,8 @@
GL> #include <platforms/4xx/walnut.h>
GL> #endif
GL>
GL> -#if defined(CONFIG_XILINX_ML300)
GL> -#include <platforms/4xx/xilinx_ml300.h>
GL> -#endif
GL> -
GL> -#if defined(CONFIG_XILINX_ML403)
GL> -#include <platforms/4xx/xilinx_ml403.h>
GL> +#if defined(CONFIG_XILINX_VIRTEX)
GL> +#include <platforms/4xx/virtex.h>
GL> #endif
Could we make that
#if defined(CONFIG_XILINX_ML300) || defined(CONFIG_XILINX_ML403)
instead? I'm using RedBoot on a virtex platform, and hence another
struct bd_info than the ML300/ML403.
Other than that,
Acked-by: Peter Korsgaard <jacmet@sunsite.dk>
--
Bye, Peter Korsgaard
^ permalink raw reply
* Re: [PATCH 3/5] [PPC] New registration for common Xilinx Virtex ppc405 platform devices
From: Peter Korsgaard @ 2007-04-25 12:11 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <1176622070387-git-send-email-grant.likely@secretlab.ca>
>>>>> "GL" == Grant Likely <grant.likely@secretlab.ca> writes:
Hi,
GL> Currently virtex support in mainline make use of the
GL> infrastructure in arch/ppc/syslib/ppc_sys.c for registering common
GL> devices on virtex ppc405 platforms. The ppc_sys.c code is not
GL> well suited to the dynamic nature of FPGA designs and makes adding
GL> new board ports more complex. This patch adds a new listing of
GL> common devices which does not depend on the ppc_sys.c
GL> infrastructure.
GL> +/* UART 8250 driver platform data table */
GL> +struct plat_serial8250_port virtex_serial_platform_data[] = {
GL> +#if defined(XPAR_UARTNS550_0_BASEADDR)
GL> + XPAR_UART(0),
GL> +#endif
GL> +#if defined(XPAR_UARTNS550_1_BASEADDR)
GL> + XPAR_UART(1),
GL> +#endif
GL> +#if defined(XPAR_UARTNS550_2_BASEADDR)
GL> + XPAR_UART(2),
GL> +#endif
GL> +#if defined(XPAR_UARTNS550_3_BASEADDR)
GL> + XPAR_UART(3),
GL> +#endif
GL> + { }, /* terminated by empty record */
GL> +};
Could we at the same time increase the amount of UARTs supported? We
have designs with 5 16550s.
Other than that,
Acked-by: Peter Korsgaard <jacmet@sunsite.dk>
--
Bye, Peter Korsgaard
^ permalink raw reply
* Re: [PATCH 4/5] [PPC] Stop using ppc_sys for Xilinx Virtex boards
From: Peter Korsgaard @ 2007-04-25 12:12 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <11766220702647-git-send-email-grant.likely@secretlab.ca>
>>>>> "GL" == Grant Likely <grant.likely@secretlab.ca> writes:
Hi,
GL> The arch/ppc/syslib/ppc_sys.c infrastructure does not work well
GL> for the virtex ports. Move the ml300 and ml403 board ports over
GL> to use the new virtex_devices infrastructure.
Acked-by: Peter Korsgaard <jacmet@sunsite.dk>
--
Bye, Peter Korsgaard
^ permalink raw reply
* Re: [PATCH 5/5] [PPC] Add uartlite boot console driver for the zImage wrapper
From: Peter Korsgaard @ 2007-04-25 12:13 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <11766220713124-git-send-email-grant.likely@secretlab.ca>
>>>>> "GL" == Grant Likely <grant.likely@secretlab.ca> writes:
Hi,
GL> Signed-off-by: Grant Likely <grant.likely@secretlab.ca> ---
Acked-by: Peter Korsgaard <jacmet@sunsite.dk>
--
Bye, Peter Korsgaard
^ permalink raw reply
* Re: Flat device tree definitions for FLASH and MTD partitioning
From: Wolfgang Grandegger @ 2007-04-25 12:55 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: linuxppc-embedded
In-Reply-To: <4618DE4A.4020404@ru.mvista.com>
Sergei Shtylyov wrote:
> Hello, I wrote:
>
>>> are there already some thought or even example code on how to define
>>> Flash memory and MTD partitions in the DTS. This would avoid the
>>> ackward MTD partitioning via static structure or boot line argument
>>> and could be done in a generic way.
>
>> See Documentation/powerpc/booting-without-of.txt and
>> drivers/mtd/physmap_of.c for what's been already done.
>
> I meant drivers/mtd/maps/physmap_of.c
I had a closer look to this driver. Unfortunately, it can not handle yet
multiple FLASH banks. This could be achieved with an additional
property "bank_count". What do you think?
Wolfgang.
^ permalink raw reply
* Re: [PATCH] Xilinx framebuffer device driver
From: Andrei Konovalov @ 2007-04-25 13:06 UTC (permalink / raw)
To: Grant Likely; +Cc: Rick Moleres, linuxppc-embedded
In-Reply-To: <528646bc0704241517g595bf7bfqe54e40b05f74e933@mail.gmail.com>
Grant Likely wrote:
> On 4/24/07, Andrei Konovalov <akonovalov@ru.mvista.com> wrote:
>> Add support for the video controller IP block included into Xilinx
>> ML300 and
>> ML403 reference designs.
>>
>> Signed-off-by: Andrei Konovalov <akonovalov@ru.mvista.com>
>> ---
>>
>> This patch relies on the "Patchset to establish sanity in Xilinx
>> Virtex support" by Gran Likely to have
>> the frame buffer device registered on the platform bus. Without this
>> patchset one needs to fill in
>> the struct platform_device and make sure platform_device_register() is
>> called elsewhere.
>>
>> Reviews and comments are welcome.
>>
>> Would be nice to get this driver into mainline for the 2.6.22.
>
> Quick comment on first perusal: The driver uses the out_be32 macro
> directly for accessing registers, which doesn't work if the FB block
> is configured for DCR access (like the ML403 reference design).
Yes, that's true.
But (at least) the EDK 8.1 reference design for ML403 has also opb2dcr bridge.
That's why I've tested the patch without problems on ML403 (in addition
to ML300).
I'll add DCR access, but not sure if I need a separate bitstream to
test DCR access (could I access the DCR registers directly in presence
of the bridge or not).
> There will need to be a property in the platform device binding to determine
> how to access registers.
OK.
The only problem is that there is no indication in the xparameters.h of how the
registers should be accessed (via DCR or opb).
Let's suppose XPAR_TFT_0_USE_DCR would be added by EDK (like XPAR_XINTC_USE_DCR
is used for the interrupt controller).
> Cheers,
> g.
>
Thanks,
Andrei
^ permalink raw reply
* Re: [PATCH] 64K page support for kexec
From: Luke Browning @ 2007-04-25 13:06 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: linuxppc-dev, Paul Mackerras, cbe-oss-dev, Arnd Bergmann
In-Reply-To: <1177454894.14873.142.camel@localhost.localdomain>
On Wed, 2007-04-25 at 08:48 +1000, Benjamin Herrenschmidt wrote:
> Getting better :-)
>
> Sorry for the constant nagging, let's say I'm a bit perfectionist...
>
so am I. That is why I redid the patch instead of going with the
previous version.
> > -static unsigned long slot2va(unsigned long hpte_v, unsigned long slot)
> > -{
> > - unsigned long avpn = HPTE_V_AVPN_VAL(hpte_v);
> > - unsigned long va;
> > -
> > - va = avpn << 23;
> > -
> > - if (! (hpte_v & HPTE_V_LARGE)) {
> > - unsigned long vpi, pteg;
> > -
> > - pteg = slot / HPTES_PER_GROUP;
> > - if (hpte_v & HPTE_V_SECONDARY)
> > - pteg = ~pteg;
>
> Hrm... hpte_decode ends up being a pretty big function... I suppose
> that's ok.
>
It is bigger because it combines two functions. I think it is better
this way as it will make it easier to add support for 16G pages and 1T
segments in the future.
> > +#define LP_SHIFT 12
> > +#define LP_BITS 8
> > +#define LP_MASK(i) ((((1 << LP_BITS) - 1) >> (i)) << LP_SHIFT)
> > +
> > +static void hpte_decode(hpte_t *hpte, unsigned long slot,
> > + int *psize, unsigned long *va)
> > +{
> > + unsigned long hpte_r = hpte->r;
> > + unsigned long hpte_v = hpte->v;
> > + unsigned long avpn;
> > + int i, size, shift, penc, avpnm_bits;
> > +
> > + if (!(hpte_v & HPTE_V_LARGE))
> > + size = MMU_PAGE_4K;
> > +#if 0
> > + else if (hpte_v & 0x4000000000000000UL)
> > + size = MMU_PAGE_16G;
> > +#endif
>
> Remove the above. I don't think it's right anyway. We'll deal with 16G
> pages when we start using them.
OK. I put it there mainly as a place holder. How many page sizes do
you expect to support in a 1TB segment?
>
> > + else if (!(hpte_r & LP_MASK(0)))
> > + size = MMU_PAGE_16M;
>
> Is that correct ? (The above).
> I haven't quite noticed in the previous
> instances of the patch, sorry about that but I don't think that's the
> way to detect the "old style" 16M pages... I -suspect- that the normal
> algorithm will work for them, that is, they'll have a penc of 0 which
> will match what's in the mmu_psize_defs[MMU_PAGE_16M] but it's worth
> actually testing it.
Ok.
>
> Now that I think about it, it's possible that I lead you on the wrong
> track there initially... Sorry about that.
>
> I think your above code will treat anything with a penc of 0 as a 16M
> page, which might be true with current implementations, is also, I
> think, not mandated by the arch, is it ? (I don't have my 2.03 at hand
> as I'm writing this email).
right. The encoding is implementation dependent. There is a minimum
size requirement that comes into play, but that works the other way.
penc of zero has a minimum page size requirement of 8K.
I will remove the test and use the array for the comparison.
>
> > + else {
> > + for (i = 0; i < LP_BITS; i++) {
> > + if ((hpte_r & LP_MASK(i+1)) == LP_MASK(i+1))
> > + break;
> > + }
> > + penc = LP_MASK(i+1) >> LP_SHIFT;
> > + for (size = MMU_PAGE_64K; size < MMU_PAGE_16M; size++) {
> > + if (!mmu_psize_defs[size].shift)
> > + continue;
> > + if (penc == mmu_psize_defs[size].penc)
> > + break;
> > + }
> > + }
> >
> > - vpi = ((va >> 28) ^ pteg) & htab_hash_mask;
> > + /*
> > + * FIXME, this could be made more efficient by storing the type
> > + * of hash algorithm in mmu_psize_defs[]. The code below assumes
> > + * the number of bits in the va representing the offset in the
> > + * page is less than 23. This affects the hash algorithm that is
> > + * used. When 16G pages are supported, a new hash algorithm
> > + * needs to be provided. See POWER ISA Book III.
> > + *
> > + * The code below works for 16M, 64K, and 4K pages.
> > + */
>
> I'm not 100% certain about your comment. The by type of hash algorithm
> you mean the segment size right ? This is not directly related to the
> page size. While 1T segments are mandatory for 16G pages, they can also
> hold normal page sizes... If we're going to implement support for 1T
> segment, we should get the segment size (and thus the hash algorithm)
> from the B bit of the PTE.
yes. what you said is correct. I was thinking that you might want to
double the number of array elements so that you could apply a different
hash algorithm based on the type of segments.
>
> In fact, when doing 1T segments, we'll have to deal with them regardless
> of the page size (the hashing will be different for all page sizes).
>
> > + shift = mmu_psize_defs[size].shift;
> > + if (mmu_psize_defs[size].avpnm)
> > + avpnm_bits = __ilog2_u64(mmu_psize_defs[size].avpnm) + 1;
> > + else
> > + avpnm_bits = 0;
> > + if (shift - avpnm_bits <= 23) {
> > + avpn = HPTE_V_AVPN_VAL(hpte_v) << 23;
> > +
> > + if (shift < 23) {
> > + unsigned long vpi, pteg;
> > +
> > + pteg = slot / HPTES_PER_GROUP;
> > + if (hpte_v & HPTE_V_SECONDARY)
> > + pteg = ~pteg;
> > + vpi = ((avpn >> 28) ^ pteg) & htab_hash_mask;
> > + avpn |= (vpi << mmu_psize_defs[size].shift);
> > + }
> > + }
> > +#if 0
> > + /* 16GB page hash, p > 23 */
> > + else {
> >
> > - va |= vpi << PAGE_SHIFT;
> > }
> > +#endif
>
> Just don't keep the code in #if 0, just a comment about something
> needing to be done for 16G ...
>
ok.
> > - return va;
> > + *va = avpn;
> > + *psize = size;
> > }
> >
> > /*
> > @@ -374,8 +420,6 @@ static unsigned long slot2va(unsigned lo
> > *
> > * TODO: add batching support when enabled. remember, no dynamic memory here,
> > * athough there is the control page available...
> > - *
> > - * XXX FIXME: 4k only for now !
> > */
> > static void native_hpte_clear(void)
> > {
> > @@ -383,6 +427,7 @@ static void native_hpte_clear(void)
> > hpte_t *hptep = htab_address;
> > unsigned long hpte_v;
> > unsigned long pteg_count;
> > + int psize;
> >
> > pteg_count = htab_hash_mask + 1;
> >
> > @@ -408,8 +453,9 @@ static void native_hpte_clear(void)
> > * already hold the native_tlbie_lock.
> > */
> > if (hpte_v & HPTE_V_VALID) {
> > + hpte_decode(hptep, slot, &psize, &hpte_v);
> > hptep->v = 0;
> > - __tlbie(slot2va(hpte_v, slot), MMU_PAGE_4K);
> > + __tlbie(hpte_v, psize);
> > }
> > }
> >
> >
>
^ permalink raw reply
* Re: [PATCH 1/6] Start split out of common open firmware code
From: Segher Boessenkool @ 2007-04-25 13:07 UTC (permalink / raw)
To: David Miller; +Cc: sfr, paulus, linuxppc-dev
In-Reply-To: <20070424.212736.115930755.davem@davemloft.net>
>> The SPARC tree carries the same broken code -- is
>> this just a case of code copying, or are there
>> actual SPARC machines with such broken trees?
>
> There have been many cases of missed or even erroneous
> properties on sparc tree, but I am not too sure about
> the cell counting cases.
>
> Let's do this, once the consolidation is done keeping
> behavior as-is, give me a patch to review that changing
> the cell counting bits and I'll verify it against
> all the machines I have here plus some OFW tree dumps.
Okay, good plan. Let's try this as soon as the current
patch series hits the powerpc tree.
Segher
^ permalink raw reply
* Re: [PATCH 1/6] Start split out of common open firmware code
From: Segher Boessenkool @ 2007-04-25 13:11 UTC (permalink / raw)
To: David Miller; +Cc: sfr, paulus, linuxppc-dev
In-Reply-To: <20070424.212902.00454541.davem@davemloft.net>
>> end up with the OF analogue to an MSI layer that only
>> ever can work on intel compatible platforms.
>
> Please don't use this straw-man.
>
> These days it works perfectly fine on sparc64.
Yes, but how long did that take? And why? That's my
point, not that "after this things cannot be solved
anymore" -- sure they can, it gets a lot harder though.
Segher
^ permalink raw reply
* Re: [PATCH 3/6] Consolidate of_find_property
From: Segher Boessenkool @ 2007-04-25 13:13 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: ppc-dev, Paul Mackerras, David S. Miller, Stephen Rothwell
In-Reply-To: <1177477630.14873.185.camel@localhost.localdomain>
>> The question is, what ppc drivers would break if we used strcmp
>> instead of strcasecmp? I have a dim memory that some Apple machines
>> had "ata" and others had "ATA" for the hard disk, for instance.
>
> ata/ATA and ide/IDE is the main one that comes to mind, but I wouldn't
> exclude something like Powermac vs. PowerMac or that sort of thing... I
> remember a case related bug about 2 years ago but can't find what it
> was ...
>
> I think it's safe to settle on strcasecmp for most things for now
Yes, it's hard to imagine any case where strcasecmp(),
although technically incorrect, would break anything.
Please document in the code that is _is_ wrong and _why_
it is done though.
Segher
^ permalink raw reply
* Re: [PATCH] generic check_legacy_ioport
From: Segher Boessenkool @ 2007-04-25 13:33 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: Christian Krafft, Olaf Hering, linuxppc-dev
In-Reply-To: <200704250949.17795.arnd@arndb.de>
>> SLOF/JS21 (at least some versions of it) have an "ipmi"
>> node on the "isa" bus. =A0And the kernel ipmi driver actually
>> works on it, too (no idea about the currently proposed
>> scanning though -- but the principle is correct at least).
>
> It won'd be found by the of_platform_driver part of ipmi,
> since devices on the ISA bus do not get added to the linux
> device tree.
Drat. Why not?
> If the ipmi node on the ISA bus is located at the standardized
> legacy I/O port range, it should get found by the later probing,
> if check_legacy_ioport allows it.
"Standardised" hahaha. No, it is at some other
address.
> We might still want to have the driver use a proper of_device,
> which would require the maple platform code to add this device
> during probing.
That sounds like the only option then. Does
this have to be done per platform though? It
sounds perfectly safe to do it in more generic
code.
Segher
^ permalink raw reply
* Re: Flat device tree definitions for FLASH and MTD partitioning
From: Sergei Shtylyov @ 2007-04-25 13:35 UTC (permalink / raw)
To: Wolfgang Grandegger; +Cc: linuxppc-embedded
In-Reply-To: <462F4FD1.6080900@grandegger.com>
Hello.
Wolfgang Grandegger wrote:
>>>> are there already some thought or even example code on how to define
>>>> Flash memory and MTD partitions in the DTS. This would avoid the
>>>> ackward MTD partitioning via static structure or boot line argument
>>>> and could be done in a generic way.
>>> See Documentation/powerpc/booting-without-of.txt and
>>> drivers/mtd/physmap_of.c for what's been already done.
>> I meant drivers/mtd/maps/physmap_of.c
> I had a closer look to this driver. Unfortunately, it can not handle yet
> multiple FLASH banks. This could be achieved with an additional
> property "bank_count". What do you think?
I'm not sure what banks you're talking about -- note that this driver is equivalen in functionality to the plain 'physmap' driver and there's inherited "bank-width" property that handles flash banking.
> Wolfgang.
MBR, Sergei
^ permalink raw reply
* Re: Flat device tree definitions for FLASH and MTD partitioning
From: Wolfgang Grandegger @ 2007-04-25 14:02 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: linuxppc-embedded
In-Reply-To: <462F592F.7000409@ru.mvista.com>
Sergei Shtylyov wrote:
> Hello.
>
> Wolfgang Grandegger wrote:
>
>>>>> are there already some thought or even example code on how to
>>>>> define Flash memory and MTD partitions in the DTS. This would avoid
>>>>> the ackward MTD partitioning via static structure or boot line
>>>>> argument and could be done in a generic way.
>
>>>> See Documentation/powerpc/booting-without-of.txt and
>>>> drivers/mtd/physmap_of.c for what's been already done.
>
>>> I meant drivers/mtd/maps/physmap_of.c
>
>> I had a closer look to this driver. Unfortunately, it can not handle
>> yet multiple FLASH banks. This could be achieved with an additional
>> property "bank_count". What do you think?
>
> I'm not sure what banks you're talking about -- note that this driver
> is equivalen in functionality to the plain 'physmap' driver and there's
> inherited "bank-width" property that handles flash banking.
Yes, I know. Nevertheless the driver cannot handle flash regions
composed of more than on FLASH bank because we need to probe every bank.
Search for "BANK" in drivers/mtd/maps" to understand what I mean.
Wolfgang.
^ permalink raw reply
* Re: Flat device tree definitions for FLASH and MTD partitioning
From: Sergei Shtylyov @ 2007-04-25 14:34 UTC (permalink / raw)
To: Wolfgang Grandegger; +Cc: linuxppc-embedded
In-Reply-To: <462F5F86.3060309@grandegger.com>
Hello.
Wolfgang Grandegger wrote:
>>>>>> are there already some thought or even example code on how to
>>>>>> define Flash memory and MTD partitions in the DTS. This would
>>>>>> avoid the ackward MTD partitioning via static structure or boot
>>>>>> line argument and could be done in a generic way.
>>>>> See Documentation/powerpc/booting-without-of.txt and
>>>>> drivers/mtd/physmap_of.c for what's been already done.
>>>> I meant drivers/mtd/maps/physmap_of.c
>>> I had a closer look to this driver. Unfortunately, it can not handle
>>> yet multiple FLASH banks. This could be achieved with an additional
>>> property "bank_count". What do you think?
Please use hyphen, not underscore in property names ("device_type" seems an only exception from this rule).
>> I'm not sure what banks you're talking about -- note that this driver
>> is equivalen in functionality to the plain 'physmap' driver and
>> there's inherited "bank-width" property that handles flash banking.
> Yes, I know. Nevertheless the driver cannot handle flash regions
> composed of more than on FLASH bank because we need to probe every bank.
> Search for "BANK" in drivers/mtd/maps" to understand what I mean.
Hm, from what I could see, those banks are separate maps registered to MTD subsys separately.
What's the point of adding a count property when we simply can define multiple "rom" devices?
> Wolfgang.
MBR, Sergei
^ permalink raw reply
* Re: [PATCH][RFC] i2c: adds support for i2c bus on 8xx
From: Vitaly Bordug @ 2007-04-25 17:06 UTC (permalink / raw)
To: Jean Delvare; +Cc: linuxppc-dev@ozlabs.org, lkml
In-Reply-To: <20070423111950.129856eb@hyperion.delvare>
[-- Attachment #1: Type: text/plain, Size: 4942 bytes --]
Jean Delvare wrote:
> Hi Vitaly,
>
> On Sun, 22 Apr 2007 15:29:37 +0400, Vitaly Bordug wrote:
>
>> On Sat, 21 Apr 2007 09:57:07 +0200 Jean Delvare wrote:
>>
>>> I wonder what's the point of having a separate i2c algorithm driver.
>>> We don't expect any other driver than i2c-rpx to ever use it, do we?
>>> In that case, all the code should be added to i2c-rpx directly, this
>>> will makes things more simple and more efficient.
>>>
>> That is how it was back in 2.4 - if you see combine is a good move,
>> I'm OK with it. But what shouldn't be rpc then - basically rpx(lite) is
>> 8xx-based target, so let's call it all mpc8xx then.
>>
>
> Sure, I'm fine with a name change. If it makes more sense to name that
> driver i2c-mpc8xx, that's OK with me.
>
>
>>>> + tmo = jiffies + 1 * HZ;
>>>> + while (!(in_8(&i2c->i2c_i2cer) & 0x11 || time_after(jiffies, tmo))) ;/* Busy wait, with a timeout */
>>>>
>>> This could result in a one-second busy loop, not very friendly for
>>> other drivers. It should sleep while waiting. Line too long, please
>>> fold.
>>>
>> Can you please elaborate a little here (or just point to the
>> similar code)? I assume we should not block here, handling timeout
>> in a waitqueue...
>>
>
> Blocking is not a problem. The problem is that you are keeping the CPU
> for yourself while waiting, for up to one full second. That's not
> acceptable. You should at least call schedule() or cond_resced() (I
> don't know the difference, I admit) and/or cpu_relax() as is done in
> i2c-mpc, i2c-ibm_iic and scx200_acb, or even sleep, as is done in
> i2c-omap. Search for "time_after" in these 4 drivers for examples. I
> believe that sleeping is more friendly.
>
>
OK, very clear, thanks.
>>> You do not appear to handle repeated start. I can tell because the
>>> code handles all messages the exact same way, be they the first,
>>> second or last message of a group. This means that you don't really
>>> implement the I2C protocol, but an approximation of it. It might be
>>> sufficient for some I2C chips, but others will break. Look in the
>>> specifications of your device for how this could be fixed.
>>>
>> I doubt 8xx has a full-fledged i2c protocol stuff onboard, and basic
>> code that were residing in 2.4 repo suite my needs quite well (afaict
>> many others just don't care :)).
>> I just think it is silly to drop the code already implemented and working
>> even if it requires some efforts to bring it up to shape.
>>
>
> Well as far as I can see, only the repeated start is missing, so it's
> not that far from a complete implementation. If the hardware can do it,
> you simply have to add it to the driver. If the hardware really doesn't
> do it (which would surprise me, but you never know), of course you
> cannot implement it in the driver and we'll have to live with (well,
> without) it. But that's definitely an issue to keep in mind if I2C chip
> drivers start failing when used together with this bus driver.
>
>
>>>> +static struct i2c_adapter rpx_ops = {
>>>>
>>> Could be const?
>>>
>>>
>> prolly yes.
>>
>>>> + .owner = THIS_MODULE,
>>>> + .name = "m8xx",
>>>>
>>> Find a better name (e.g. "i2c-rpx").
>>>
>>>
>> What about mpc8xx?
>>
>
> i2c-mpc8xx then, OK.
>
>
>>>> +/* Structure for a device driver */
>>>> +static struct device_driver i2c_rpx_driver = {
>>>> + .name = "fsl-i2c-cpm",
>>>> + .bus = &platform_bus_type,
>>>> + .probe = i2c_rpx_probe,
>>>> + .remove = i2c_rpx_remove,
>>>> +};
>>>>
>>> Why don't you declare it as a struct platform_driver, register it with
>>> platform_driver_register() and unregister it with
>>> platform_driver_unregister()?
>>>
>> Well. This stuff belongs to CPM1, of the mpc8xx family, but the
>> target boards are different, and they may/should provide board
>> specific inits and filling of platform data. With
>> platform_driver_register we may end up with ifdef stuff here
>> (which is evil).
>>
>
> I don't follow you here, sorry. Platform devices are declared by
> board-specific code which can include all the needed initialization.
> And device-specific data can be carried to the platform driver for
> further use. The platform device/driver infrastructure is meant to
> handle that kind of situation, so there really is no excuse that I can
> see not to use it. i2c-omap and i2c-mpc use it. As a matter of fact you
> _are_ declaring a platform driver (.bus = &platform_bus_type), just not
> using the standard way.
>
>
Standard way here - platform devices got registered from elsewhere -
from arch/ppc/ppc_sys.c if arch/ppc or from
arch/powerpc/sysdev/fsl_soc.c if powerpc.
Every way (powerpc is more flexible since is pulling the information
from the firmware-passed device tree) fills in the resources and
platform data, and
is capable with device/drive bound you are talking about.
--
Thanks, Vitaly
[-- Attachment #2: Type: text/html, Size: 6359 bytes --]
^ permalink raw reply
* Re: [PATCH][RFC][POWERPC] i2c: adds support for i2c bus on 8xx
From: Vitaly Bordug @ 2007-04-25 17:01 UTC (permalink / raw)
To: Olof Johansson; +Cc: Jean Delvare, linuxppc-dev@ozlabs.org, lkml
In-Reply-To: <20070423025709.GA28805@lixom.net>
[-- Attachment #1: Type: text/plain, Size: 4624 bytes --]
Olof Johansson wrote:
> On Fri, Apr 20, 2007 at 08:27:14AM +0400, Vitaly Bordug wrote:
>
>
>> diff --git a/arch/powerpc/platforms/8xx/mpc885ads_setup.c b/arch/powerpc/platforms/8xx/mpc885ads_setup.c
>> index 9bd81c7..d32e066 100644
>> --- a/arch/powerpc/platforms/8xx/mpc885ads_setup.c
>> +++ b/arch/powerpc/platforms/8xx/mpc885ads_setup.c
>> @@ -51,6 +51,7 @@ static void init_smc1_uart_ioports(struc
>> static void init_smc2_uart_ioports(struct fs_uart_platform_info* fpi);
>> static void init_scc3_ioports(struct fs_platform_info* ptr);
>> static void init_irda_ioports(void);
>> +static void init_i2c_ioports(void);
>>
>> void __init mpc885ads_board_setup(void)
>> {
>> @@ -120,6 +121,10 @@ #endif
>> #ifdef CONFIG_8XX_SIR
>> init_irda_ioports();
>> #endif
>> +
>> +#ifdef CONFIG_I2C_RPXLITE
>> + init_i2c_ioports();
>> +#endif
>>
>
> Does it hurt to always do it, even when the driver is not enabled? THat'd
> do away with an ifdef.
>
>
Well it will hurt - 8xx has conflicting io pin configurations, and
nothing should be set up "just in case".
> Also, if you move the static function up, you don't need a prototype. That
> goes for other stuff in this file too.
>
>
>> }
>>
>>
>> @@ -361,6 +366,15 @@ static void init_irda_ioports()
>> immr_unmap(cp);
>> }
>>
>> +static void init_i2c_ioports()
>> +{
>> + cpm8xx_t *cp = (cpm8xx_t *)immr_map(im_cpm);
>> +
>> + setbits32(&cp->cp_pbpar, 0x00000030);
>> + setbits32(&cp->cp_pbdir, 0x00000030);
>> + setbits16(&cp->cp_pbodr, 0x0030);
>> +}
>>
>
> Looks like you moved this out of the driver and into the platform
> code. What happens to other platforms where it's used?
>
>
i2c && 8xx combo never work with 2.6 at least in mainstream. That's why
related stuff were scheduled to removal by Jean even,
before I came up with this stuff.
>> +
>> int platform_device_skip(const char *model, int id)
>> {
>> #ifdef CONFIG_MPC8xx_SECOND_ETH_SCC3
>> diff --git a/arch/powerpc/sysdev/fsl_soc.c b/arch/powerpc/sysdev/fsl_soc.c
>> index 419b688..7ecd537 100644
>> --- a/arch/powerpc/sysdev/fsl_soc.c
>> +++ b/arch/powerpc/sysdev/fsl_soc.c
>> @@ -331,7 +331,7 @@ static int __init fsl_i2c_of_init(void)
>> for (np = NULL, i = 0;
>> (np = of_find_compatible_node(np, "i2c", "fsl-i2c")) != NULL;
>> i++) {
>> - struct resource r[2];
>> + struct resource r[3];
>>
>
> Why? No code that uses it has been changed. Is it a bugfix?
>
>
maybe something stray...
>> struct fsl_i2c_platform_data i2c_data;
>> const unsigned char *flags = NULL;
>>
>> @@ -1215,4 +1215,63 @@ err:
>>
>> arch_initcall(fs_irda_of_init);
>>
>> +static const char *i2c_regs = "regs";
>> +static const char *i2c_pram = "pram";
>> +static const char *i2c_irq = "interrupt";
>> +
>> +static int __init fsl_i2c_cpm_of_init(void)
>> +{
>> + struct device_node *np;
>> + unsigned int i;
>> + struct platform_device *i2c_dev;
>> + int ret;
>> +
>> + for (np = NULL, i = 0;
>> + (np = of_find_compatible_node(np, "i2c", "fsl-i2c-cpm")) != NULL;
>> + i++) {
>> + struct resource r[3];
>> + struct fsl_i2c_platform_data i2c_data;
>> +
>> + memset(&r, 0, sizeof(r));
>> + memset(&i2c_data, 0, sizeof(i2c_data));
>> +
>> + ret = of_address_to_resource(np, 0, &r[0]);
>> + if (ret)
>> + goto err;
>> + r[0].name = i2c_regs;
>> +
>> + ret = of_address_to_resource(np, 1, &r[1]);
>> + if (ret)
>> + goto err;
>> + r[1].name = i2c_pram;
>> +
>> + r[2].start = r[2].end = irq_of_parse_and_map(np, 0);
>> + r[2].flags = IORESOURCE_IRQ;
>> + r[2].name = i2c_irq;
>> +
>> + i2c_dev = platform_device_register_simple("fsl-i2c-cpm", i, &r[0], 3);
>> + if (IS_ERR(i2c_dev)) {
>> + ret = PTR_ERR(i2c_dev);
>> + goto err;
>> + }
>> +
>> + ret =
>> + platform_device_add_data(i2c_dev, &i2c_data,
>> + sizeof(struct
>> + fsl_i2c_platform_data));
>> + if (ret)
>> + goto unreg;
>> + }
>> +
>> + return 0;
>> +
>> +unreg:
>> + platform_device_unregister(i2c_dev);
>> +err:
>> + return ret;
>> +}
>> +
>> +arch_initcall(fsl_i2c_cpm_of_init);
>>
>
> This could all be done with an of_platform driver instead, and avoid the above.
> (Someone else already suggested that I believe).
>
>
I know i know. But it was decided, while both ppc/ and powerpc/ wander
around, platform devices way is preferrable.
It is apparent why - so far only mpc885 is alive in arch/powerpc, and it
is not going to change soon for 8xx. OTOH,
some stuff from arch/ppc might use it/add BSP configuration etc.
Having some devices on of_device and some on pdev look kinda messy.
Thanks,
Vitaly
[-- Attachment #2: Type: text/html, Size: 5458 bytes --]
^ permalink raw reply
* Re: [PATCH 3/6] Consolidate of_find_property
From: Matt Sealey @ 2007-04-25 17:46 UTC (permalink / raw)
To: Segher Boessenkool
Cc: Stephen Rothwell, Paul Mackerras, David S. Miller, ppc-dev
In-Reply-To: <c249005137aa3e50c25221f6849a70ea@kernel.crashing.org>
Can't the ata/ATA thing be fixed by simply fixing device trees where it
happens? strncmp seems the standards-compliant route to take.. why clutter
the common parsing routines with fixes for deviant platforms?
The Mac obviously has a few of_platform things where you can add a
compatible search for ata then ATA, keeping it all in the drivers (where
relevant) and in the platform setup (where necessary)
--
Matt Sealey <matt@genesi-usa.com>
Genesi, Manager, Developer Relations
Segher Boessenkool wrote:
>>> The question is, what ppc drivers would break if we used strcmp
>>> instead of strcasecmp? I have a dim memory that some Apple machines
>>> had "ata" and others had "ATA" for the hard disk, for instance.
>> ata/ATA and ide/IDE is the main one that comes to mind, but I wouldn't
>> exclude something like Powermac vs. PowerMac or that sort of thing... I
>> remember a case related bug about 2 years ago but can't find what it
>> was ...
>>
>> I think it's safe to settle on strcasecmp for most things for now
>
> Yes, it's hard to imagine any case where strcasecmp(),
> although technically incorrect, would break anything.
> Please document in the code that is _is_ wrong and _why_
> it is done though.
>
>
> Segher
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ permalink raw reply
* Re: [PATCH] Xilinx framebuffer device driver
From: Andrei Konovalov @ 2007-04-25 18:06 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: Rick Moleres, linuxppc-embedded
In-Reply-To: <200704250035.18673.arnd@arndb.de>
Hi Arnd,
Arnd Bergmann wrote:
>> + .activate = FB_ACTIVATE_NOW,
>> + .height = 99, /* in mm of NEC NL6448BC20-08 on ML300 */
>> + .width = 132 /* in mm of NEC NL6448BC20-08 on ML300 */
>> +};
>
> The size looks very specific to a particular display hardware. I guess
> when the driver gets converted to an of_platform_driver, this should come
> from the device tree.
>
> Until then, maybe a config option, with a reasonable default would be
> right.
I could add these to platform data.
Together with the "use DCR access" option.
Say,
--------------------------------------------------------
struct xilinxfb_platform_data {
u32 use_dcr;
u32 screen_height_mm;
u32 screen_width_mm;
};
static struct xilinxfb_platform_data xilinxfb_pdata = {
#if defined(XPAR_TFT_0_USE_DCR) && (XPAR_TFT_0_USE_DCR != 0)
.use_dcr = 1;
#else
.use_dcr = 0;
#endif
.screen_height_mm = CONFIG_FB_XILINX_SCR_HEIGHT;
.screen_width_mm = CONFIG_FB_XILINX_SCR_WIDTH;
};
...
/* ML300/403 reference design framebuffer */
#if defined(XPAR_TFT_0_BASEADDR)
{
.name = "xilinxfb",
.id = 0,
.dev.platform_data = &xilinxfb_pdata,
.num_resources = 1,
.resource = (struct resource[]) {
{
.start = XPAR_TFT_0_BASEADDR,
.end = XPAR_TFT_0_BASEADDR+7,
.flags = IORESOURCE_IO,
},
},
},
#endif
--------------------------------------------------------
Does it look OK?
>> +
>> +struct xilinxfb_drvdata {
>> +
>> + struct fb_info info; /* FB driver info record */
>> +
>> + unsigned long regs_phys; /* phys. address of the control registers */
>> + u32 *regs; /* virt. address of the control registers */
>> +
>> + unsigned char *fb_virt; /* virt. address of the frame buffer */
>
> The virtual addresses should be marked as __iomem, so you can check the correct
> usage with sparse.
OK. Thanks.
> Not sure about regs_phys. Can this be beyond the 32 bit limit on any machine?
The driver is for Xilinx FPGAs only (the video controller is the "soft core" IP
block).
My personal feeling is that someday in the future Virtex FPGAs would carry ppc440 "hard" cores.
But all current FPGAs have only ppc405 "hard core" CPU blocks inside (0, 1 or several per chip).
Another option is to use Microblaze "soft core" CPU which is 32-bit too.
I doubt someone would connect a Virtex FPGA to a "standalone" CPU to use
the FPGA as video controller (this is not impossible though).
I.e. for the moment
u32 regs_phys;
should be OK.
Other options could be
dma_addr_t regs_phys;
or
resource_size_t regs_phys;
which are u32 or u64 depending on the architecture.
But both don't sound like intended specifically for phys. addresses
(not necessary DMA-able).
What would you recommend?
>> +
>> + drvdata = kmalloc(sizeof(struct xilinxfb_drvdata), GFP_KERNEL);
>> + if (!drvdata) {
>> + printk(KERN_ERR "Couldn't allocate device private record\n");
>> + return -ENOMEM;
>> + }
>> + memset((void*)drvdata, 0, sizeof(struct xilinxfb_drvdata));
>
> Use
> drvdata = kzalloc(sizeof (*drvdata), GFP_KERNEL);
Oops.. Sure I will.
>> + drvdata->regs_phys = regs_res->start;
>> + drvdata->regs = (u32 *) ioremap(regs_res->start, 8);
>
> u32 __iomem*
OK
> Arnd <><
Thanks,
Andrei
^ permalink raw reply
* Re: [PATCH] Xilinx framebuffer device driver
From: Andrei Konovalov @ 2007-04-25 18:16 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-embedded
In-Reply-To: <462F98B4.2000108@ru.mvista.com>
Grant,
Andrei Konovalov wrote:
> I could add these to platform data.
> Together with the "use DCR access" option.
> Say,
>
> --------------------------------------------------------
> struct xilinxfb_platform_data {
> u32 use_dcr;
> u32 screen_height_mm;
> u32 screen_width_mm;
> };
>
> static struct xilinxfb_platform_data xilinxfb_pdata = {
> #if defined(XPAR_TFT_0_USE_DCR) && (XPAR_TFT_0_USE_DCR != 0)
> .use_dcr = 1;
> #else
> .use_dcr = 0;
> #endif
IOW I am trying to avoid conditional compilation like:
#if defined(XPAR_TFT_0_USE_DCR) && (XPAR_TFT_0_USE_DCR != 0)
#define xilinxfb_out_be32(addr, mask) mtdcr((addr), (mask))
#else
#define xilinxfb_out_be32(addr, mask) out_be32((addr), (mask))
#endif
- as this would make the driver to include xparameters.h which would
be an issue when moving to the OF device tree.
Or "use DCR" could be a Kconfig option for the driver.
Thanks,
Andrei
^ permalink raw reply
* Re: [PATCH] ppc: Add support for bigger page sizes than 4KB on PPC44x
From: Yuri Tikhonov @ 2007-04-25 17:37 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <17921.3150.242081.66071@cargo.ozlabs.ibm.com>
The patch replaces the CONFIG_PPC_PAGE_SHIFT integer option with choice of
three boolean options
Signed-off-by: Yuri Tikhonov <yur@emcraft.com>
--
diff --git a/arch/ppc/Kconfig b/arch/ppc/Kconfig
index 72af523..5eb58dc 100644
--- a/arch/ppc/Kconfig
+++ b/arch/ppc/Kconfig
@@ -1201,15 +1201,24 @@ config SECCOMP
If unsure, say Y. Only embedded should say N here.
-config PPC_PAGE_SHIFT
- int "Page size (12=>4KB; 14=>16KB; 16=>64KB)" if 44x
- default "12"
- range 12 16
- help
+choice
+ prompt "Page size"
+ default PPC_PAGE_4K
+ ---help---
The PAGE_SIZE definition. Increasing the page size may
improve the system performance in some dedicated cases.
- If unsure, set it to 12 (4KB).
+ If unsure, set it to 4 KB.
+
+config PPC_PAGE_4K
+ bool "4 KB"
+
+config PPC_PAGE_16K
+ bool "16 KB" if 44x
+
+config PPC_PAGE_64K
+ bool "64 KB" if 44x
+endchoice
endmenu
diff --git a/include/asm-ppc/page.h b/include/asm-ppc/page.h
index 0b8f354..f46712e 100644
--- a/include/asm-ppc/page.h
+++ b/include/asm-ppc/page.h
@@ -4,7 +4,13 @@
#include <asm/asm-compat.h>
/* PAGE_SHIFT determines the page size */
-#define PAGE_SHIFT CONFIG_PPC_PAGE_SHIFT
+#if defined(CONFIG_PPC_PAGE_4K)
+#define PAGE_SHIFT 12
+#elif defined(CONFIG_PPC_PAGE_16K)
+#define PAGE_SHIFT 14
+#elif defined(CONFIG_PPC_PAGE_64K)
+#define PAGE_SHIFT 16
+#endif
#define PAGE_SIZE (ASM_CONST(1) << PAGE_SHIFT)
/*
^ permalink raw reply related
* Re: [PATCH] Xilinx framebuffer device driver
From: Grant Likely @ 2007-04-25 18:35 UTC (permalink / raw)
To: Andrei Konovalov; +Cc: linuxppc-embedded
In-Reply-To: <462F9B1A.3090906@ru.mvista.com>
On 4/25/07, Andrei Konovalov <akonovalov@ru.mvista.com> wrote:
> Grant,
>
> > static struct xilinxfb_platform_data xilinxfb_pdata = {
> > #if defined(XPAR_TFT_0_USE_DCR) && (XPAR_TFT_0_USE_DCR != 0)
> > .use_dcr = 1;
> > #else
> > .use_dcr = 0;
> > #endif
>
> IOW I am trying to avoid conditional compilation like:
I agree 100%. All the device options should be specified dynamically.
Heck, it should be possible to build a single kernel and boot it on
just about any design.
>
> #if defined(XPAR_TFT_0_USE_DCR) && (XPAR_TFT_0_USE_DCR != 0)
> #define xilinxfb_out_be32(addr, mask) mtdcr((addr), (mask))
> #else
> #define xilinxfb_out_be32(addr, mask) out_be32((addr), (mask))
> #endif
>
> - as this would make the driver to include xparameters.h which would
> be an issue when moving to the OF device tree.
Which is a bad thing. I believe that the Xilinx folks would like to
use the device tree for the microblaze target also; but there is a
fair bit of work that need to be done before that is feasable.
>
> Or "use DCR" could be a Kconfig option for the driver.
My preference would be for it to be a runtime thing.
--
Grant Likely, B.Sc. P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: Howto read I2C on MPC5200 Lite
From: Matthias Fechner @ 2007-04-25 18:48 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <20070404084950.GF18236@moe.telargo.com>
[-- Attachment #1: Type: text/plain, Size: 1185 bytes --]
Hi Domen,
Domen Puncer wrote:
> I can't reproduce your no-errors behaviour. I tried unplugging network
> cable and compiling out the fec driver.
i did the last weeks some tests and it seems that the "problem" persists.
I boot my system like descripted below and I have an error rate of about
5%. If I reboot my system, start start the program and then unplug the
networkcable the error rate is much lower.
This is my configuration:
Board MPC5200 Lite5200 Evaluation board (not version b)
U-Boot 1.2.0-gfdd1d6dc (Mar 6 2007 - 12:52:10)
Kernel is loaded via tftp and the complete filesystem is mounted via NFS.
Crosscompile/basesystem is ELDK 4.1.
You can see exactly what I did under:
http://wiki.idefix.fechner.net/index.php/IceCube
Kernel is Linux-2.6.21-mpc52xx-g7e5e3d6f-d with some patches from the
mailinglist (I2C patches and powermanagement patches you submitted on
the ML) and Xenomai support.
I attach my kernel config and a small program with which i read my Maxim
6633 temperatur sensor you can order it as sample on the maxim website.
Maybe something is wrong with the program or it is a problem with the
MPC5200 which is fixed with the 5200b.
Thx a lot
Matthias
[-- Attachment #2: config --]
[-- Type: text/plain, Size: 23245 bytes --]
#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.21-rc2
# Wed Mar 21 21:18:10 2007
#
CONFIG_MMU=y
CONFIG_GENERIC_HARDIRQS=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_ARCH_HAS_ILOG2_U32=y
# CONFIG_ARCH_HAS_ILOG2_U64 is not set
CONFIG_GENERIC_HWEIGHT=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_PPC=y
CONFIG_PPC32=y
CONFIG_GENERIC_NVRAM=y
CONFIG_GENERIC_FIND_NEXT_BIT=y
CONFIG_SCHED_NO_NO_OMIT_FRAME_POINTER=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_GENERIC_BUG=y
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
#
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y
CONFIG_BROKEN_ON_SMP=y
CONFIG_INIT_ENV_ARG_LIMIT=32
#
# General setup
#
CONFIG_LOCALVERSION=""
CONFIG_LOCALVERSION_AUTO=y
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
# CONFIG_IPC_NS is not set
CONFIG_SYSVIPC_SYSCTL=y
# CONFIG_POSIX_MQUEUE is not set
# CONFIG_BSD_PROCESS_ACCT is not set
# CONFIG_TASKSTATS is not set
# CONFIG_UTS_NS is not set
# CONFIG_AUDIT is not set
CONFIG_IKCONFIG=y
CONFIG_IKCONFIG_PROC=y
CONFIG_SYSFS_DEPRECATED=y
# CONFIG_RELAY is not set
CONFIG_INITRAMFS_SOURCE=""
# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set
CONFIG_SYSCTL=y
# CONFIG_EMBEDDED is not set
CONFIG_SYSCTL_SYSCALL=y
CONFIG_KALLSYMS=y
# CONFIG_KALLSYMS_ALL is not set
# CONFIG_KALLSYMS_EXTRA_PASS is not set
CONFIG_HOTPLUG=y
CONFIG_PRINTK=y
CONFIG_BUG=y
CONFIG_ELF_CORE=y
CONFIG_BASE_FULL=y
CONFIG_FUTEX=y
CONFIG_EPOLL=y
CONFIG_SHMEM=y
CONFIG_SLAB=y
CONFIG_VM_EVENT_COUNTERS=y
CONFIG_RT_MUTEXES=y
# CONFIG_TINY_SHMEM is not set
CONFIG_BASE_SMALL=0
# CONFIG_SLOB is not set
#
# Loadable module support
#
CONFIG_MODULES=y
CONFIG_MODULE_UNLOAD=y
# CONFIG_MODULE_FORCE_UNLOAD is not set
CONFIG_MODVERSIONS=y
# CONFIG_MODULE_SRCVERSION_ALL is not set
CONFIG_KMOD=y
#
# Block layer
#
CONFIG_BLOCK=y
# CONFIG_LBD is not set
# CONFIG_BLK_DEV_IO_TRACE is not set
# CONFIG_LSF is not set
#
# IO Schedulers
#
CONFIG_IOSCHED_NOOP=y
CONFIG_IOSCHED_AS=y
CONFIG_IOSCHED_DEADLINE=y
CONFIG_IOSCHED_CFQ=y
# CONFIG_DEFAULT_AS is not set
# CONFIG_DEFAULT_DEADLINE is not set
CONFIG_DEFAULT_CFQ=y
# CONFIG_DEFAULT_NOOP is not set
CONFIG_DEFAULT_IOSCHED="cfq"
#
# Real-time sub-system
#
CONFIG_XENOMAI=y
CONFIG_XENO_OPT_NUCLEUS=y
CONFIG_XENO_OPT_PERVASIVE=y
# CONFIG_XENO_OPT_ISHIELD is not set
CONFIG_XENO_OPT_PRIOCPL=y
CONFIG_XENO_OPT_SECURITY_ACCESS=y
CONFIG_XENO_OPT_PIPELINE_HEAD=y
CONFIG_XENO_OPT_PIPE=y
CONFIG_XENO_OPT_PIPE_NRDEV=32
CONFIG_XENO_OPT_REGISTRY=y
CONFIG_XENO_OPT_REGISTRY_NRSLOTS=512
CONFIG_XENO_OPT_SYS_HEAPSZ=128
CONFIG_XENO_OPT_STATS=y
# CONFIG_XENO_OPT_DEBUG is not set
#
# Timing
#
# CONFIG_XENO_OPT_TIMING_PERIODIC is not set
CONFIG_XENO_OPT_TIMING_TIMERLAT=0
CONFIG_XENO_OPT_TIMING_SCHEDLAT=0
#
# Scalability
#
# CONFIG_XENO_OPT_SCALABLE_SCHED is not set
CONFIG_XENO_OPT_TIMER_LIST=y
# CONFIG_XENO_OPT_TIMER_HEAP is not set
# CONFIG_XENO_OPT_TIMER_WHEEL is not set
#
# Shared interrupts
#
# CONFIG_XENO_OPT_SHIRQ_LEVEL is not set
# CONFIG_XENO_OPT_SHIRQ_EDGE is not set
#
# Machine
#
CONFIG_XENO_HW_FPU=y
#
# Interfaces
#
CONFIG_XENO_SKIN_NATIVE=y
CONFIG_XENO_OPT_NATIVE_PERIOD=0
CONFIG_XENO_OPT_NATIVE_PIPE=y
CONFIG_XENO_OPT_NATIVE_PIPE_BUFSZ=4096
CONFIG_XENO_OPT_NATIVE_REGISTRY=y
CONFIG_XENO_OPT_NATIVE_SEM=y
CONFIG_XENO_OPT_NATIVE_EVENT=y
CONFIG_XENO_OPT_NATIVE_MUTEX=y
CONFIG_XENO_OPT_NATIVE_COND=y
CONFIG_XENO_OPT_NATIVE_QUEUE=y
CONFIG_XENO_OPT_NATIVE_HEAP=y
CONFIG_XENO_OPT_NATIVE_ALARM=y
CONFIG_XENO_OPT_NATIVE_MPS=y
# CONFIG_XENO_OPT_NATIVE_INTR is not set
CONFIG_XENO_SKIN_POSIX=y
CONFIG_XENO_OPT_POSIX_PERIOD=0
# CONFIG_XENO_OPT_POSIX_SHM is not set
# CONFIG_XENO_OPT_POSIX_INTR is not set
CONFIG_XENO_OPT_DEBUG_POSIX=y
# CONFIG_XENO_SKIN_PSOS is not set
# CONFIG_XENO_SKIN_UITRON is not set
# CONFIG_XENO_SKIN_VRTX is not set
# CONFIG_XENO_SKIN_VXWORKS is not set
# CONFIG_XENO_SKIN_RTAI is not set
CONFIG_XENO_SKIN_RTDM=y
CONFIG_XENO_OPT_RTDM_PERIOD=0
CONFIG_XENO_OPT_RTDM_FILDES=128
#
# Drivers
#
#
# Serial drivers
#
# CONFIG_XENO_DRIVERS_16550A is not set
#
# Testing drivers
#
CONFIG_XENO_DRIVERS_TIMERBENCH=m
CONFIG_XENO_DRIVERS_IRQBENCH=m
CONFIG_XENO_DRIVERS_SWITCHTEST=m
#
# CAN drivers
#
# CONFIG_XENO_DRIVERS_CAN is not set
#
# Processor
#
CONFIG_6xx=y
# CONFIG_40x is not set
# CONFIG_44x is not set
# CONFIG_8xx is not set
# CONFIG_E200 is not set
# CONFIG_E500 is not set
CONFIG_PPC_FPU=y
# CONFIG_PPC_DCR_NATIVE is not set
# CONFIG_ALTIVEC is not set
# CONFIG_TAU is not set
# CONFIG_KEXEC is not set
# CONFIG_CPU_FREQ is not set
# CONFIG_WANT_EARLY_SERIAL is not set
CONFIG_PPC_STD_MMU=y
#
# Platform options
#
# CONFIG_PPC_PREP is not set
# CONFIG_APUS is not set
# CONFIG_KATANA is not set
# CONFIG_WILLOW is not set
# CONFIG_CPCI690 is not set
# CONFIG_POWERPMC250 is not set
# CONFIG_CHESTNUT is not set
# CONFIG_SPRUCE is not set
# CONFIG_HDPU is not set
# CONFIG_EV64260 is not set
# CONFIG_LOPEC is not set
# CONFIG_MVME5100 is not set
# CONFIG_PPLUS is not set
# CONFIG_PRPMC750 is not set
# CONFIG_PRPMC800 is not set
# CONFIG_SANDPOINT is not set
# CONFIG_RADSTONE_PPC7D is not set
# CONFIG_PAL4 is not set
# CONFIG_EST8260 is not set
# CONFIG_SBC82xx is not set
# CONFIG_SBS8260 is not set
# CONFIG_RPX8260 is not set
# CONFIG_TQM8260 is not set
# CONFIG_PM82X is not set
# CONFIG_ADS8272 is not set
# CONFIG_PQ2FADS is not set
CONFIG_LITE5200=y
# CONFIG_LITE5200B is not set
# CONFIG_MPC834x_SYS is not set
# CONFIG_EV64360 is not set
# CONFIG_P3M750 is not set
# CONFIG_TQM834x is not set
# CONFIG_TQM8272 is not set
CONFIG_PPC_MPC52xx=y
CONFIG_PPC_BESTCOMM=y
# CONFIG_SMP is not set
CONFIG_IPIPE=y
# CONFIG_HIGHMEM is not set
CONFIG_ARCH_POPULATES_NODE_MAP=y
# CONFIG_HZ_100 is not set
CONFIG_HZ_250=y
# CONFIG_HZ_300 is not set
# CONFIG_HZ_1000 is not set
CONFIG_HZ=250
CONFIG_PREEMPT_NONE=y
# CONFIG_PREEMPT_VOLUNTARY is not set
# CONFIG_PREEMPT is not set
CONFIG_SELECT_MEMORY_MODEL=y
CONFIG_FLATMEM_MANUAL=y
# CONFIG_DISCONTIGMEM_MANUAL is not set
# CONFIG_SPARSEMEM_MANUAL is not set
CONFIG_FLATMEM=y
CONFIG_FLAT_NODE_MEM_MAP=y
# CONFIG_SPARSEMEM_STATIC is not set
CONFIG_SPLIT_PTLOCK_CPUS=4
# CONFIG_RESOURCES_64BIT is not set
CONFIG_ZONE_DMA_FLAG=1
CONFIG_BINFMT_ELF=y
# CONFIG_BINFMT_MISC is not set
CONFIG_CMDLINE_BOOL=y
CONFIG_CMDLINE="console=ttyS0 root=/dev/ram0 rw"
CONFIG_PM=y
CONFIG_PM_LEGACY=y
# CONFIG_PM_DEBUG is not set
# CONFIG_PM_SYSFS_DEPRECATED is not set
# CONFIG_SOFTWARE_SUSPEND is not set
CONFIG_SECCOMP=y
CONFIG_ISA_DMA_API=y
#
# Bus options
#
CONFIG_ZONE_DMA=y
CONFIG_GENERIC_ISA_DMA=y
# CONFIG_PPC_I8259 is not set
# CONFIG_PPC_INDIRECT_PCI is not set
CONFIG_PCI=y
CONFIG_PCI_DOMAINS=y
# CONFIG_PCI_DEBUG is not set
#
# PCCARD (PCMCIA/CardBus) support
#
# CONFIG_PCCARD is not set
#
# PCI Express support
#
#
# Advanced setup
#
CONFIG_ADVANCED_OPTIONS=y
CONFIG_HIGHMEM_START=0xfe000000
# CONFIG_LOWMEM_SIZE_BOOL is not set
CONFIG_LOWMEM_SIZE=0x30000000
# CONFIG_KERNEL_START_BOOL is not set
CONFIG_KERNEL_START=0xc0000000
# CONFIG_TASK_SIZE_BOOL is not set
CONFIG_TASK_SIZE=0x80000000
# CONFIG_BOOT_LOAD_BOOL is not set
CONFIG_BOOT_LOAD=0x00800000
#
# Networking
#
CONFIG_NET=y
#
# Networking options
#
# CONFIG_NETDEBUG is not set
CONFIG_PACKET=y
# CONFIG_PACKET_MMAP is not set
CONFIG_UNIX=y
CONFIG_XFRM=y
# CONFIG_XFRM_USER is not set
# CONFIG_XFRM_SUB_POLICY is not set
# CONFIG_XFRM_MIGRATE is not set
# CONFIG_NET_KEY is not set
CONFIG_INET=y
# CONFIG_IP_MULTICAST is not set
# CONFIG_IP_ADVANCED_ROUTER is not set
CONFIG_IP_FIB_HASH=y
CONFIG_IP_PNP=y
CONFIG_IP_PNP_DHCP=y
# CONFIG_IP_PNP_BOOTP is not set
# CONFIG_IP_PNP_RARP is not set
# CONFIG_NET_IPIP is not set
# CONFIG_NET_IPGRE is not set
# CONFIG_ARPD is not set
# CONFIG_SYN_COOKIES is not set
# CONFIG_INET_AH is not set
# CONFIG_INET_ESP is not set
# CONFIG_INET_IPCOMP is not set
# CONFIG_INET_XFRM_TUNNEL is not set
# CONFIG_INET_TUNNEL is not set
# CONFIG_INET_XFRM_MODE_TRANSPORT is not set
# CONFIG_INET_XFRM_MODE_TUNNEL is not set
CONFIG_INET_XFRM_MODE_BEET=y
CONFIG_INET_DIAG=y
CONFIG_INET_TCP_DIAG=y
# CONFIG_TCP_CONG_ADVANCED is not set
CONFIG_TCP_CONG_CUBIC=y
CONFIG_DEFAULT_TCP_CONG="cubic"
# CONFIG_TCP_MD5SIG is not set
# CONFIG_IPV6 is not set
# CONFIG_INET6_XFRM_TUNNEL is not set
# CONFIG_INET6_TUNNEL is not set
# CONFIG_NETWORK_SECMARK is not set
# CONFIG_NETFILTER is not set
#
# DCCP Configuration (EXPERIMENTAL)
#
# CONFIG_IP_DCCP is not set
#
# SCTP Configuration (EXPERIMENTAL)
#
# CONFIG_IP_SCTP is not set
#
# TIPC Configuration (EXPERIMENTAL)
#
# CONFIG_TIPC is not set
# CONFIG_ATM is not set
# CONFIG_BRIDGE is not set
# CONFIG_VLAN_8021Q is not set
# CONFIG_DECNET is not set
# CONFIG_LLC2 is not set
# CONFIG_IPX is not set
# CONFIG_ATALK is not set
# CONFIG_X25 is not set
# CONFIG_LAPB is not set
# CONFIG_ECONET is not set
# CONFIG_WAN_ROUTER is not set
#
# QoS and/or fair queueing
#
# CONFIG_NET_SCHED is not set
#
# Network testing
#
# CONFIG_NET_PKTGEN is not set
# CONFIG_HAMRADIO is not set
# CONFIG_IRDA is not set
# CONFIG_BT is not set
# CONFIG_IEEE80211 is not set
#
# Device Drivers
#
#
# Generic Driver Options
#
CONFIG_STANDALONE=y
# CONFIG_PREVENT_FIRMWARE_BUILD is not set
# CONFIG_FW_LOADER is not set
# CONFIG_DEBUG_DRIVER is not set
# CONFIG_DEBUG_DEVRES is not set
# CONFIG_SYS_HYPERVISOR is not set
#
# Connector - unified userspace <-> kernelspace linker
#
# CONFIG_CONNECTOR is not set
#
# Memory Technology Devices (MTD)
#
# CONFIG_MTD is not set
#
# Parallel port support
#
# CONFIG_PARPORT is not set
#
# Plug and Play support
#
# CONFIG_PNPACPI is not set
#
# Block devices
#
# CONFIG_BLK_DEV_FD is not set
# CONFIG_BLK_CPQ_DA is not set
# CONFIG_BLK_CPQ_CISS_DA is not set
# CONFIG_BLK_DEV_DAC960 is not set
# CONFIG_BLK_DEV_UMEM is not set
# CONFIG_BLK_DEV_COW_COMMON is not set
CONFIG_BLK_DEV_LOOP=m
# CONFIG_BLK_DEV_CRYPTOLOOP is not set
# CONFIG_BLK_DEV_NBD is not set
# CONFIG_BLK_DEV_SX8 is not set
CONFIG_BLK_DEV_RAM=y
CONFIG_BLK_DEV_RAM_COUNT=16
CONFIG_BLK_DEV_RAM_SIZE=4096
CONFIG_BLK_DEV_RAM_BLOCKSIZE=1024
CONFIG_BLK_DEV_INITRD=y
# CONFIG_CDROM_PKTCDVD is not set
# CONFIG_ATA_OVER_ETH is not set
#
# Misc devices
#
# CONFIG_SGI_IOC4 is not set
# CONFIG_TIFM_CORE is not set
#
# ATA/ATAPI/MFM/RLL support
#
# CONFIG_IDE is not set
#
# SCSI device support
#
# CONFIG_RAID_ATTRS is not set
# CONFIG_SCSI is not set
# CONFIG_SCSI_NETLINK is not set
#
# Serial ATA (prod) and Parallel ATA (experimental) drivers
#
# CONFIG_ATA is not set
#
# Multi-device support (RAID and LVM)
#
# CONFIG_MD is not set
#
# Fusion MPT device support
#
# CONFIG_FUSION is not set
#
# IEEE 1394 (FireWire) support
#
# CONFIG_IEEE1394 is not set
#
# I2O device support
#
# CONFIG_I2O is not set
#
# Macintosh device drivers
#
# CONFIG_MAC_EMUMOUSEBTN is not set
# CONFIG_WINDFARM is not set
#
# Network device support
#
CONFIG_NETDEVICES=y
# CONFIG_DUMMY is not set
# CONFIG_BONDING is not set
# CONFIG_EQUALIZER is not set
# CONFIG_TUN is not set
#
# ARCnet devices
#
# CONFIG_ARCNET is not set
#
# PHY device support
#
# CONFIG_PHYLIB is not set
#
# Ethernet (10 or 100Mbit)
#
CONFIG_NET_ETHERNET=y
CONFIG_MII=y
# CONFIG_HAPPYMEAL is not set
# CONFIG_SUNGEM is not set
# CONFIG_CASSINI is not set
# CONFIG_NET_VENDOR_3COM is not set
#
# Tulip family network device support
#
# CONFIG_NET_TULIP is not set
# CONFIG_HP100 is not set
# CONFIG_NET_PCI is not set
#
# MPC5200 Networking Options
#
CONFIG_FEC_MPC52xx=y
CONFIG_USE_MDIO=y
#
# Ethernet (1000 Mbit)
#
# CONFIG_ACENIC is not set
# CONFIG_DL2K is not set
# CONFIG_E1000 is not set
# CONFIG_NS83820 is not set
# CONFIG_HAMACHI is not set
# CONFIG_YELLOWFIN is not set
# CONFIG_R8169 is not set
# CONFIG_SIS190 is not set
# CONFIG_SKGE is not set
# CONFIG_SKY2 is not set
# CONFIG_SK98LIN is not set
# CONFIG_TIGON3 is not set
# CONFIG_BNX2 is not set
# CONFIG_QLA3XXX is not set
# CONFIG_ATL1 is not set
#
# Ethernet (10000 Mbit)
#
# CONFIG_CHELSIO_T1 is not set
# CONFIG_CHELSIO_T3 is not set
# CONFIG_IXGB is not set
# CONFIG_S2IO is not set
# CONFIG_MYRI10GE is not set
# CONFIG_NETXEN_NIC is not set
#
# Token Ring devices
#
# CONFIG_TR is not set
#
# Wireless LAN (non-hamradio)
#
# CONFIG_NET_RADIO is not set
#
# Wan interfaces
#
# CONFIG_WAN is not set
# CONFIG_FDDI is not set
# CONFIG_HIPPI is not set
# CONFIG_PPP is not set
# CONFIG_SLIP is not set
# CONFIG_SHAPER is not set
# CONFIG_NETCONSOLE is not set
# CONFIG_NETPOLL is not set
# CONFIG_NET_POLL_CONTROLLER is not set
#
# ISDN subsystem
#
# CONFIG_ISDN is not set
#
# Telephony Support
#
# CONFIG_PHONE is not set
#
# Input device support
#
CONFIG_INPUT=y
# CONFIG_INPUT_FF_MEMLESS is not set
#
# Userland interfaces
#
CONFIG_INPUT_MOUSEDEV=y
CONFIG_INPUT_MOUSEDEV_PSAUX=y
CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024
CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768
# CONFIG_INPUT_JOYDEV is not set
# CONFIG_INPUT_TSDEV is not set
CONFIG_INPUT_EVDEV=y
CONFIG_INPUT_EVBUG=y
#
# Input Device Drivers
#
# CONFIG_INPUT_KEYBOARD is not set
# CONFIG_INPUT_MOUSE is not set
# CONFIG_INPUT_JOYSTICK is not set
# CONFIG_INPUT_TOUCHSCREEN is not set
# CONFIG_INPUT_MISC is not set
#
# Hardware I/O ports
#
CONFIG_SERIO=y
# CONFIG_SERIO_I8042 is not set
CONFIG_SERIO_SERPORT=y
# CONFIG_SERIO_PCIPS2 is not set
# CONFIG_SERIO_RAW is not set
# CONFIG_GAMEPORT is not set
#
# Character devices
#
CONFIG_VT=y
CONFIG_VT_CONSOLE=y
CONFIG_HW_CONSOLE=y
# CONFIG_VT_HW_CONSOLE_BINDING is not set
# CONFIG_SERIAL_NONSTANDARD is not set
#
# Serial drivers
#
# CONFIG_SERIAL_8250 is not set
#
# Non-8250 serial port support
#
# CONFIG_SERIAL_UARTLITE is not set
CONFIG_SERIAL_CORE=y
CONFIG_SERIAL_CORE_CONSOLE=y
CONFIG_SERIAL_MPC52xx=y
CONFIG_SERIAL_MPC52xx_CONSOLE=y
CONFIG_SERIAL_MPC52xx_CONSOLE_BAUD=9600
# CONFIG_SERIAL_JSM is not set
CONFIG_UNIX98_PTYS=y
CONFIG_LEGACY_PTYS=y
CONFIG_LEGACY_PTY_COUNT=256
#
# IPMI
#
# CONFIG_IPMI_HANDLER is not set
#
# Watchdog Cards
#
# CONFIG_WATCHDOG is not set
CONFIG_HW_RANDOM=y
# CONFIG_NVRAM is not set
# CONFIG_GEN_RTC is not set
# CONFIG_DTLK is not set
# CONFIG_R3964 is not set
# CONFIG_APPLICOM is not set
# CONFIG_AGP is not set
# CONFIG_DRM is not set
# CONFIG_RAW_DRIVER is not set
#
# TPM devices
#
# CONFIG_TCG_TPM is not set
#
# I2C support
#
CONFIG_I2C=m
CONFIG_I2C_CHARDEV=m
#
# I2C Algorithms
#
CONFIG_I2C_ALGOBIT=m
CONFIG_I2C_ALGOPCF=m
CONFIG_I2C_ALGOPCA=m
#
# I2C Hardware Bus support
#
# CONFIG_I2C_ALI1535 is not set
# CONFIG_I2C_ALI1563 is not set
# CONFIG_I2C_ALI15X3 is not set
# CONFIG_I2C_AMD756 is not set
# CONFIG_I2C_AMD8111 is not set
# CONFIG_I2C_I801 is not set
# CONFIG_I2C_I810 is not set
# CONFIG_I2C_PIIX4 is not set
CONFIG_I2C_MPC=m
# CONFIG_I2C_MPC8260 is not set
# CONFIG_I2C_NFORCE2 is not set
# CONFIG_I2C_OCORES is not set
# CONFIG_I2C_PARPORT_LIGHT is not set
# CONFIG_I2C_PASEMI is not set
# CONFIG_I2C_PROSAVAGE is not set
# CONFIG_I2C_SAVAGE4 is not set
# CONFIG_I2C_SIS5595 is not set
# CONFIG_I2C_SIS630 is not set
# CONFIG_I2C_SIS96X is not set
CONFIG_I2C_STUB=m
# CONFIG_I2C_VIA is not set
# CONFIG_I2C_VIAPRO is not set
# CONFIG_I2C_VOODOO3 is not set
# CONFIG_I2C_PCA_ISA is not set
#
# Miscellaneous I2C Chip support
#
CONFIG_SENSORS_DS1337=m
CONFIG_SENSORS_DS1374=m
CONFIG_SENSORS_EEPROM=m
# CONFIG_SENSORS_MAX6900 is not set
CONFIG_SENSORS_PCF8574=m
CONFIG_SENSORS_PCA9539=m
CONFIG_SENSORS_PCF8591=m
CONFIG_SENSORS_M41T00=m
CONFIG_SENSORS_MAX6875=m
CONFIG_I2C_DEBUG_CORE=y
CONFIG_I2C_DEBUG_ALGO=y
CONFIG_I2C_DEBUG_BUS=y
CONFIG_I2C_DEBUG_CHIP=y
#
# SPI support
#
# CONFIG_SPI is not set
# CONFIG_SPI_MASTER is not set
#
# Dallas's 1-wire bus
#
# CONFIG_W1 is not set
#
# Hardware Monitoring support
#
CONFIG_HWMON=y
# CONFIG_HWMON_VID is not set
# CONFIG_SENSORS_ABITUGURU is not set
# CONFIG_SENSORS_AD7414 is not set
# CONFIG_SENSORS_ADM1021 is not set
# CONFIG_SENSORS_ADM1025 is not set
# CONFIG_SENSORS_ADM1026 is not set
# CONFIG_SENSORS_ADM1029 is not set
# CONFIG_SENSORS_ADM1031 is not set
# CONFIG_SENSORS_ADM9240 is not set
# CONFIG_SENSORS_ASB100 is not set
# CONFIG_SENSORS_ATXP1 is not set
# CONFIG_SENSORS_DS1621 is not set
# CONFIG_SENSORS_F71805F is not set
# CONFIG_SENSORS_FM75 is not set
# CONFIG_SENSORS_FSCHER is not set
# CONFIG_SENSORS_FSCPOS is not set
# CONFIG_SENSORS_GL518SM is not set
# CONFIG_SENSORS_GL520SM is not set
# CONFIG_SENSORS_IT87 is not set
# CONFIG_SENSORS_LM63 is not set
# CONFIG_SENSORS_LM75 is not set
# CONFIG_SENSORS_LM77 is not set
# CONFIG_SENSORS_LM78 is not set
# CONFIG_SENSORS_LM80 is not set
# CONFIG_SENSORS_LM83 is not set
# CONFIG_SENSORS_LM85 is not set
# CONFIG_SENSORS_LM87 is not set
# CONFIG_SENSORS_LM90 is not set
# CONFIG_SENSORS_LM92 is not set
# CONFIG_SENSORS_MAX1619 is not set
# CONFIG_SENSORS_PC87360 is not set
# CONFIG_SENSORS_PC87427 is not set
# CONFIG_SENSORS_SIS5595 is not set
# CONFIG_SENSORS_SMSC47M1 is not set
# CONFIG_SENSORS_SMSC47M192 is not set
# CONFIG_SENSORS_SMSC47B397 is not set
# CONFIG_SENSORS_VIA686A is not set
# CONFIG_SENSORS_VT1211 is not set
# CONFIG_SENSORS_VT8231 is not set
# CONFIG_SENSORS_W83781D is not set
# CONFIG_SENSORS_W83791D is not set
# CONFIG_SENSORS_W83792D is not set
# CONFIG_SENSORS_W83793 is not set
# CONFIG_SENSORS_W83L785TS is not set
# CONFIG_SENSORS_W83627HF is not set
# CONFIG_SENSORS_W83627EHF is not set
# CONFIG_HWMON_DEBUG_CHIP is not set
#
# Multifunction device drivers
#
# CONFIG_MFD_SM501 is not set
#
# Multimedia devices
#
# CONFIG_VIDEO_DEV is not set
#
# Digital Video Broadcasting Devices
#
# CONFIG_DVB is not set
#
# Graphics support
#
# CONFIG_BACKLIGHT_LCD_SUPPORT is not set
# CONFIG_FB is not set
# CONFIG_FB_IBM_GXT4500 is not set
#
# Console display driver support
#
CONFIG_VGA_CONSOLE=y
# CONFIG_VGACON_SOFT_SCROLLBACK is not set
CONFIG_DUMMY_CONSOLE=y
#
# Sound
#
# CONFIG_SOUND is not set
#
# HID Devices
#
CONFIG_HID=y
# CONFIG_HID_DEBUG is not set
#
# USB support
#
CONFIG_USB_ARCH_HAS_HCD=y
CONFIG_USB_ARCH_HAS_OHCI=y
CONFIG_USB_ARCH_HAS_EHCI=y
# CONFIG_USB is not set
#
# NOTE: USB_STORAGE enables SCSI, and 'SCSI disk support'
#
#
# USB Gadget Support
#
# CONFIG_USB_GADGET is not set
#
# MMC/SD Card support
#
# CONFIG_MMC is not set
#
# LED devices
#
# CONFIG_NEW_LEDS is not set
#
# LED drivers
#
#
# LED Triggers
#
#
# InfiniBand support
#
# CONFIG_INFINIBAND is not set
#
# EDAC - error detection and reporting (RAS) (EXPERIMENTAL)
#
#
# Real Time Clock
#
# CONFIG_RTC_CLASS is not set
#
# DMA Engine support
#
# CONFIG_DMA_ENGINE is not set
#
# DMA Clients
#
#
# DMA Devices
#
#
# Auxiliary Display support
#
#
# Virtualization
#
#
# File systems
#
CONFIG_EXT2_FS=y
# CONFIG_EXT2_FS_XATTR is not set
# CONFIG_EXT2_FS_XIP is not set
# CONFIG_EXT3_FS is not set
# CONFIG_EXT4DEV_FS is not set
# CONFIG_REISERFS_FS is not set
# CONFIG_JFS_FS is not set
# CONFIG_FS_POSIX_ACL is not set
# CONFIG_XFS_FS is not set
# CONFIG_GFS2_FS is not set
# CONFIG_OCFS2_FS is not set
# CONFIG_MINIX_FS is not set
# CONFIG_ROMFS_FS is not set
CONFIG_INOTIFY=y
CONFIG_INOTIFY_USER=y
# CONFIG_QUOTA is not set
CONFIG_DNOTIFY=y
# CONFIG_AUTOFS_FS is not set
# CONFIG_AUTOFS4_FS is not set
# CONFIG_FUSE_FS is not set
#
# CD-ROM/DVD Filesystems
#
# CONFIG_ISO9660_FS is not set
# CONFIG_UDF_FS is not set
#
# DOS/FAT/NT Filesystems
#
# CONFIG_MSDOS_FS is not set
# CONFIG_VFAT_FS is not set
# CONFIG_NTFS_FS is not set
#
# Pseudo filesystems
#
CONFIG_PROC_FS=y
CONFIG_PROC_KCORE=y
CONFIG_PROC_SYSCTL=y
CONFIG_SYSFS=y
CONFIG_TMPFS=y
# CONFIG_TMPFS_POSIX_ACL is not set
# CONFIG_HUGETLB_PAGE is not set
CONFIG_RAMFS=y
# CONFIG_CONFIGFS_FS is not set
#
# Miscellaneous filesystems
#
# CONFIG_ADFS_FS is not set
# CONFIG_AFFS_FS is not set
# CONFIG_HFS_FS is not set
# CONFIG_HFSPLUS_FS is not set
# CONFIG_BEFS_FS is not set
# CONFIG_BFS_FS is not set
# CONFIG_EFS_FS is not set
# CONFIG_CRAMFS is not set
# CONFIG_VXFS_FS is not set
# CONFIG_HPFS_FS is not set
# CONFIG_QNX4FS_FS is not set
# CONFIG_SYSV_FS is not set
# CONFIG_UFS_FS is not set
#
# Network File Systems
#
CONFIG_NFS_FS=y
CONFIG_NFS_V3=y
# CONFIG_NFS_V3_ACL is not set
# CONFIG_NFS_V4 is not set
# CONFIG_NFS_DIRECTIO is not set
# CONFIG_NFSD is not set
CONFIG_ROOT_NFS=y
CONFIG_LOCKD=y
CONFIG_LOCKD_V4=y
CONFIG_NFS_COMMON=y
CONFIG_SUNRPC=y
# CONFIG_RPCSEC_GSS_KRB5 is not set
# CONFIG_RPCSEC_GSS_SPKM3 is not set
# CONFIG_SMB_FS is not set
# CONFIG_CIFS is not set
# CONFIG_NCP_FS is not set
# CONFIG_CODA_FS is not set
# CONFIG_AFS_FS is not set
# CONFIG_9P_FS is not set
#
# Partition Types
#
# CONFIG_PARTITION_ADVANCED is not set
CONFIG_MSDOS_PARTITION=y
#
# Native Language Support
#
CONFIG_NLS=y
CONFIG_NLS_DEFAULT="iso8859-1"
# CONFIG_NLS_CODEPAGE_437 is not set
# CONFIG_NLS_CODEPAGE_737 is not set
# CONFIG_NLS_CODEPAGE_775 is not set
# CONFIG_NLS_CODEPAGE_850 is not set
# CONFIG_NLS_CODEPAGE_852 is not set
# CONFIG_NLS_CODEPAGE_855 is not set
# CONFIG_NLS_CODEPAGE_857 is not set
# CONFIG_NLS_CODEPAGE_860 is not set
# CONFIG_NLS_CODEPAGE_861 is not set
# CONFIG_NLS_CODEPAGE_862 is not set
# CONFIG_NLS_CODEPAGE_863 is not set
# CONFIG_NLS_CODEPAGE_864 is not set
# CONFIG_NLS_CODEPAGE_865 is not set
# CONFIG_NLS_CODEPAGE_866 is not set
# CONFIG_NLS_CODEPAGE_869 is not set
# CONFIG_NLS_CODEPAGE_936 is not set
# CONFIG_NLS_CODEPAGE_950 is not set
# CONFIG_NLS_CODEPAGE_932 is not set
# CONFIG_NLS_CODEPAGE_949 is not set
# CONFIG_NLS_CODEPAGE_874 is not set
# CONFIG_NLS_ISO8859_8 is not set
# CONFIG_NLS_CODEPAGE_1250 is not set
# CONFIG_NLS_CODEPAGE_1251 is not set
# CONFIG_NLS_ASCII is not set
CONFIG_NLS_ISO8859_1=m
# CONFIG_NLS_ISO8859_2 is not set
# CONFIG_NLS_ISO8859_3 is not set
# CONFIG_NLS_ISO8859_4 is not set
# CONFIG_NLS_ISO8859_5 is not set
# CONFIG_NLS_ISO8859_6 is not set
# CONFIG_NLS_ISO8859_7 is not set
# CONFIG_NLS_ISO8859_9 is not set
# CONFIG_NLS_ISO8859_13 is not set
# CONFIG_NLS_ISO8859_14 is not set
# CONFIG_NLS_ISO8859_15 is not set
# CONFIG_NLS_KOI8_R is not set
# CONFIG_NLS_KOI8_U is not set
# CONFIG_NLS_UTF8 is not set
#
# Distributed Lock Manager
#
# CONFIG_DLM is not set
#
# Library routines
#
CONFIG_BITREVERSE=y
# CONFIG_CRC_CCITT is not set
# CONFIG_CRC16 is not set
CONFIG_CRC32=y
# CONFIG_LIBCRC32C is not set
CONFIG_PLIST=y
CONFIG_HAS_IOMEM=y
CONFIG_HAS_IOPORT=y
# CONFIG_PROFILING is not set
#
# Kernel hacking
#
# CONFIG_PRINTK_TIME is not set
CONFIG_ENABLE_MUST_CHECK=y
CONFIG_MAGIC_SYSRQ=y
# CONFIG_UNUSED_SYMBOLS is not set
# CONFIG_DEBUG_FS is not set
# CONFIG_HEADERS_CHECK is not set
# CONFIG_IPIPE_DEBUG is not set
CONFIG_IPIPE_TRACE_ENABLE_VALUE=0
CONFIG_DEBUG_KERNEL=y
# CONFIG_DEBUG_SHIRQ is not set
CONFIG_LOG_BUF_SHIFT=14
CONFIG_DETECT_SOFTLOCKUP=y
# CONFIG_SCHEDSTATS is not set
# CONFIG_TIMER_STATS is not set
# CONFIG_DEBUG_SLAB is not set
# CONFIG_DEBUG_RT_MUTEXES is not set
# CONFIG_RT_MUTEX_TESTER is not set
# CONFIG_DEBUG_SPINLOCK is not set
# CONFIG_DEBUG_MUTEXES is not set
CONFIG_DEBUG_SPINLOCK_SLEEP=y
# CONFIG_DEBUG_LOCKING_API_SELFTESTS is not set
# CONFIG_DEBUG_KOBJECT is not set
CONFIG_DEBUG_BUGVERBOSE=y
CONFIG_DEBUG_INFO=y
# CONFIG_DEBUG_VM is not set
# CONFIG_DEBUG_LIST is not set
CONFIG_FORCED_INLINING=y
# CONFIG_RCU_TORTURE_TEST is not set
# CONFIG_FAULT_INJECTION is not set
# CONFIG_XMON is not set
# CONFIG_BDI_SWITCH is not set
CONFIG_SERIAL_TEXT_DEBUG=y
#
# Security options
#
# CONFIG_KEYS is not set
# CONFIG_SECURITY is not set
#
# Cryptographic options
#
# CONFIG_CRYPTO is not set
[-- Attachment #3: CMakeLists.txt --]
[-- Type: text/plain, Size: 149 bytes --]
add_executable (readMax6633 readMax6633.c)
add_executable (bitOperation bitOperation.c)
INSTALL(PROGRAMS readMax6633 bitOperation DESTINATION bin)
[-- Attachment #4: readMax6633.c --]
[-- Type: text/x-csrc, Size: 2384 bytes --]
/* read the data from max6633 */
#include <errno.h>
#include <string.h>
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <fcntl.h>
#include "i2c-dev.h"
#include "version.h"
static __inline__ unsigned short swap_bytes(unsigned short val)
{
return(val >> 8) | (val << 8);
}
int main(void)
{
int res,address,file;
char filename[20];
unsigned short temp;
long funcs;
int i2cbus;
int errorCount,successfullCount;
double errorRate;
errorCount=0;
successfullCount=0;
errorRate=0;
i2cbus=1;
address=0x40;
sprintf(filename,"/dev/i2c-%d",i2cbus);
if((file=open(filename,O_RDWR))<0)
{
fprintf(stderr,"Error: could not open file %s: %s\n",filename,strerror(errno));
exit(1);
}
/* check adapter functionality */
if(ioctl(file,I2C_FUNCS,&funcs) < 0)
{
fprintf(stderr, "Error: could not get the adapter functionality matrix: %s\n",strerror(errno));
goto ERROR0;
}
if(!(funcs & I2C_FUNC_SMBUS_READ_BYTE_DATA))
{
fprintf(stderr,"Error: Adapter for i2cbus %d",i2cbus);
fprintf(stderr," does not have byte read capability\n");
goto ERROR0;
}
if(!(funcs & I2C_FUNC_SMBUS_READ_WORD_DATA))
{
fprintf(stderr,"Error: Adapter for i2cbus %d",i2cbus);
fprintf(stderr," does not have word read capability\n");
goto ERROR0;
}
/* use FORCE so that we can look at registers even when a driver
is also running */
if(ioctl(file,I2C_SLAVE,address) <0)
{
fprintf(stderr,"Error: Could not set address to %d: %s\n",address, strerror(errno));
goto ERROR0;
}
fprintf(stderr,"Read with word_data\n");
while(1)
{
temp=res=i2c_smbus_read_word_data(file,0);
if(res<0)
{
fprintf(stderr,"Error: Could not read the value from the i2c device\n");
errorCount++;
}else
{
successfullCount++;
}
temp=swap_bytes(temp);
temp=temp >> 3;
if(errorCount>0 && successfullCount>0)
{
errorRate=(double)errorCount/(double)successfullCount*(double)100;
}
printf("Success: %i, Errorcount: %i, Errorrate: %f%, Temp: %f\n",successfullCount,errorCount, errorRate,(float)(temp*0.0625));
sleep(1);
}
printf("\nCalculate temp\n");
close(file);
exit(0);
ERROR0:
close(file);
exit(1);
}
[-- Attachment #5: i2c-dev.h --]
[-- Type: text/x-chdr, Size: 12375 bytes --]
/*
i2c-dev.h - i2c-bus driver, char device interface
Copyright (C) 1995-97 Simon G. Vogl
Copyright (C) 1998-99 Frodo Looijaard <frodol@dds.nl>
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., 675 Mass Ave, Cambridge, MA 02139, USA.
*/
/* $Id: i2c-dev.h,v 1.1.1.1 2005/01/21 17:09:47 drlove Exp $ */
#ifndef LIB_I2CDEV_H
#define LIB_I2CDEV_H
#include <linux/types.h>
#include <sys/ioctl.h>
/* -- i2c.h -- */
/*
* I2C Message - used for pure i2c transaction, also from /dev interface
*/
struct i2c_msg {
__u16 addr; /* slave address */
unsigned short flags;
#define I2C_M_TEN 0x10 /* we have a ten bit chip address */
#define I2C_M_RD 0x01
#define I2C_M_NOSTART 0x4000
#define I2C_M_REV_DIR_ADDR 0x2000
#define I2C_M_IGNORE_NAK 0x1000
#define I2C_M_NO_RD_ACK 0x0800
short len; /* msg length */
char *buf; /* pointer to msg data */
int err;
short done;
};
/* To determine what functionality is present */
#define I2C_FUNC_I2C 0x00000001
#define I2C_FUNC_10BIT_ADDR 0x00000002
#define I2C_FUNC_PROTOCOL_MANGLING 0x00000004 /* I2C_M_{REV_DIR_ADDR,NOSTART,..} */
#define I2C_FUNC_SMBUS_HWPEC_CALC 0x00000008 /* SMBus 2.0 */
#define I2C_FUNC_SMBUS_READ_WORD_DATA_PEC 0x00000800 /* SMBus 2.0 */
#define I2C_FUNC_SMBUS_WRITE_WORD_DATA_PEC 0x00001000 /* SMBus 2.0 */
#define I2C_FUNC_SMBUS_PROC_CALL_PEC 0x00002000 /* SMBus 2.0 */
#define I2C_FUNC_SMBUS_BLOCK_PROC_CALL_PEC 0x00004000 /* SMBus 2.0 */
#define I2C_FUNC_SMBUS_BLOCK_PROC_CALL 0x00008000 /* SMBus 2.0 */
#define I2C_FUNC_SMBUS_QUICK 0x00010000
#define I2C_FUNC_SMBUS_READ_BYTE 0x00020000
#define I2C_FUNC_SMBUS_WRITE_BYTE 0x00040000
#define I2C_FUNC_SMBUS_READ_BYTE_DATA 0x00080000
#define I2C_FUNC_SMBUS_WRITE_BYTE_DATA 0x00100000
#define I2C_FUNC_SMBUS_READ_WORD_DATA 0x00200000
#define I2C_FUNC_SMBUS_WRITE_WORD_DATA 0x00400000
#define I2C_FUNC_SMBUS_PROC_CALL 0x00800000
#define I2C_FUNC_SMBUS_READ_BLOCK_DATA 0x01000000
#define I2C_FUNC_SMBUS_WRITE_BLOCK_DATA 0x02000000
#define I2C_FUNC_SMBUS_READ_I2C_BLOCK 0x04000000 /* I2C-like block xfer */
#define I2C_FUNC_SMBUS_WRITE_I2C_BLOCK 0x08000000 /* w/ 1-byte reg. addr. */
#define I2C_FUNC_SMBUS_READ_I2C_BLOCK_2 0x10000000 /* I2C-like block xfer */
#define I2C_FUNC_SMBUS_WRITE_I2C_BLOCK_2 0x20000000 /* w/ 2-byte reg. addr. */
#define I2C_FUNC_SMBUS_READ_BLOCK_DATA_PEC 0x40000000 /* SMBus 2.0 */
#define I2C_FUNC_SMBUS_WRITE_BLOCK_DATA_PEC 0x80000000 /* SMBus 2.0 */
#define I2C_FUNC_SMBUS_BYTE I2C_FUNC_SMBUS_READ_BYTE | \
I2C_FUNC_SMBUS_WRITE_BYTE
#define I2C_FUNC_SMBUS_BYTE_DATA I2C_FUNC_SMBUS_READ_BYTE_DATA | \
I2C_FUNC_SMBUS_WRITE_BYTE_DATA
#define I2C_FUNC_SMBUS_WORD_DATA I2C_FUNC_SMBUS_READ_WORD_DATA | \
I2C_FUNC_SMBUS_WRITE_WORD_DATA
#define I2C_FUNC_SMBUS_BLOCK_DATA I2C_FUNC_SMBUS_READ_BLOCK_DATA | \
I2C_FUNC_SMBUS_WRITE_BLOCK_DATA
#define I2C_FUNC_SMBUS_I2C_BLOCK I2C_FUNC_SMBUS_READ_I2C_BLOCK | \
I2C_FUNC_SMBUS_WRITE_I2C_BLOCK
#define I2C_FUNC_SMBUS_I2C_BLOCK_2 I2C_FUNC_SMBUS_READ_I2C_BLOCK_2 | \
I2C_FUNC_SMBUS_WRITE_I2C_BLOCK_2
#define I2C_FUNC_SMBUS_BLOCK_DATA_PEC I2C_FUNC_SMBUS_READ_BLOCK_DATA_PEC | \
I2C_FUNC_SMBUS_WRITE_BLOCK_DATA_PEC
#define I2C_FUNC_SMBUS_WORD_DATA_PEC I2C_FUNC_SMBUS_READ_WORD_DATA_PEC | \
I2C_FUNC_SMBUS_WRITE_WORD_DATA_PEC
#define I2C_FUNC_SMBUS_READ_BYTE_PEC I2C_FUNC_SMBUS_READ_BYTE_DATA
#define I2C_FUNC_SMBUS_WRITE_BYTE_PEC I2C_FUNC_SMBUS_WRITE_BYTE_DATA
#define I2C_FUNC_SMBUS_READ_BYTE_DATA_PEC I2C_FUNC_SMBUS_READ_WORD_DATA
#define I2C_FUNC_SMBUS_WRITE_BYTE_DATA_PEC I2C_FUNC_SMBUS_WRITE_WORD_DATA
#define I2C_FUNC_SMBUS_BYTE_PEC I2C_FUNC_SMBUS_BYTE_DATA
#define I2C_FUNC_SMBUS_BYTE_DATA_PEC I2C_FUNC_SMBUS_WORD_DATA
#define I2C_FUNC_SMBUS_EMUL I2C_FUNC_SMBUS_QUICK | \
I2C_FUNC_SMBUS_BYTE | \
I2C_FUNC_SMBUS_BYTE_DATA | \
I2C_FUNC_SMBUS_WORD_DATA | \
I2C_FUNC_SMBUS_PROC_CALL | \
I2C_FUNC_SMBUS_WRITE_BLOCK_DATA | \
I2C_FUNC_SMBUS_WRITE_BLOCK_DATA_PEC | \
I2C_FUNC_SMBUS_I2C_BLOCK
/*
* Data for SMBus Messages
*/
#define I2C_SMBUS_BLOCK_MAX 32 /* As specified in SMBus standard */
#define I2C_SMBUS_I2C_BLOCK_MAX 32 /* Not specified but we use same structure */
union i2c_smbus_data {
__u8 byte;
__u16 word;
__u8 block[I2C_SMBUS_BLOCK_MAX + 3]; /* block[0] is used for length */
/* one more for read length in block process call */
/* and one more for PEC */
};
/* smbus_access read or write markers */
#define I2C_SMBUS_READ 1
#define I2C_SMBUS_WRITE 0
/* SMBus transaction types (size parameter in the above functions)
Note: these no longer correspond to the (arbitrary) PIIX4 internal codes! */
#define I2C_SMBUS_QUICK 0
#define I2C_SMBUS_BYTE 1
#define I2C_SMBUS_BYTE_DATA 2
#define I2C_SMBUS_WORD_DATA 3
#define I2C_SMBUS_PROC_CALL 4
#define I2C_SMBUS_BLOCK_DATA 5
#define I2C_SMBUS_I2C_BLOCK_DATA 6
#define I2C_SMBUS_BLOCK_PROC_CALL 7 /* SMBus 2.0 */
#define I2C_SMBUS_BLOCK_DATA_PEC 8 /* SMBus 2.0 */
#define I2C_SMBUS_PROC_CALL_PEC 9 /* SMBus 2.0 */
#define I2C_SMBUS_BLOCK_PROC_CALL_PEC 10 /* SMBus 2.0 */
#define I2C_SMBUS_WORD_DATA_PEC 11 /* SMBus 2.0 */
/* ----- commands for the ioctl like i2c_command call:
* note that additional calls are defined in the algorithm and hw
* dependent layers - these can be listed here, or see the
* corresponding header files.
*/
/* -> bit-adapter specific ioctls */
#define I2C_RETRIES 0x0701 /* number of times a device address */
/* should be polled when not */
/* acknowledging */
#define I2C_TIMEOUT 0x0702 /* set timeout - call with int */
/* this is for i2c-dev.c */
#define I2C_SLAVE 0x0703 /* Change slave address */
/* Attn.: Slave address is 7 or 10 bits */
#define I2C_SLAVE_FORCE 0x0706 /* Change slave address */
/* Attn.: Slave address is 7 or 10 bits */
/* This changes the address, even if it */
/* is already taken! */
#define I2C_TENBIT 0x0704 /* 0 for 7 bit addrs, != 0 for 10 bit */
#define I2C_FUNCS 0x0705 /* Get the adapter functionality */
#define I2C_RDWR 0x0707 /* Combined R/W transfer (one stop only)*/
#define I2C_PEC 0x0708 /* != 0 for SMBus PEC */
#if 0
#define I2C_ACK_TEST 0x0710 /* See if a slave is at a specific address */
#endif
#define I2C_SMBUS 0x0720 /* SMBus-level access */
/* -- i2c.h -- */
/* Note: 10-bit addresses are NOT supported! */
/* This is the structure as used in the I2C_SMBUS ioctl call */
struct i2c_smbus_ioctl_data {
char read_write;
__u8 command;
int size;
union i2c_smbus_data *data;
};
/* This is the structure as used in the I2C_RDWR ioctl call */
struct i2c_rdwr_ioctl_data {
struct i2c_msg *msgs; /* pointers to i2c_msgs */
int nmsgs; /* number of i2c_msgs */
};
static inline __s32 i2c_smbus_access(int file, char read_write, __u8 command,
int size, union i2c_smbus_data *data)
{
struct i2c_smbus_ioctl_data args;
args.read_write = read_write;
args.command = command;
args.size = size;
args.data = data;
return ioctl(file,I2C_SMBUS,&args);
}
static inline __s32 i2c_smbus_write_quick(int file, __u8 value)
{
return i2c_smbus_access(file,value,0,I2C_SMBUS_QUICK,NULL);
}
static inline __s32 i2c_smbus_read_byte(int file)
{
union i2c_smbus_data data;
if (i2c_smbus_access(file,I2C_SMBUS_READ,0,I2C_SMBUS_BYTE,&data))
return -1;
else
return 0x0FF & data.byte;
}
static inline __s32 i2c_smbus_write_byte(int file, __u8 value)
{
return i2c_smbus_access(file,I2C_SMBUS_WRITE,value,
I2C_SMBUS_BYTE,NULL);
}
static inline __s32 i2c_smbus_read_byte_data(int file, __u8 command)
{
union i2c_smbus_data data;
if (i2c_smbus_access(file,I2C_SMBUS_READ,command,
I2C_SMBUS_BYTE_DATA,&data))
return -1;
else
return 0x0FF & data.byte;
}
static inline __s32 i2c_smbus_write_byte_data(int file, __u8 command,
__u8 value)
{
union i2c_smbus_data data;
data.byte = value;
return i2c_smbus_access(file,I2C_SMBUS_WRITE,command,
I2C_SMBUS_BYTE_DATA, &data);
}
static inline __s32 i2c_smbus_read_word_data(int file, __u8 command)
{
union i2c_smbus_data data;
if (i2c_smbus_access(file,I2C_SMBUS_READ,command,
I2C_SMBUS_WORD_DATA,&data))
return -1;
else
return 0x0FFFF & data.word;
}
static inline __s32 i2c_smbus_write_word_data(int file, __u8 command,
__u16 value)
{
union i2c_smbus_data data;
data.word = value;
return i2c_smbus_access(file,I2C_SMBUS_WRITE,command,
I2C_SMBUS_WORD_DATA, &data);
}
static inline __s32 i2c_smbus_process_call(int file, __u8 command, __u16 value)
{
union i2c_smbus_data data;
data.word = value;
if (i2c_smbus_access(file,I2C_SMBUS_WRITE,command,
I2C_SMBUS_PROC_CALL,&data))
return -1;
else
return 0x0FFFF & data.word;
}
/* Returns the number of read bytes */
static inline __s32 i2c_smbus_read_block_data(int file, __u8 command,
__u8 *values)
{
union i2c_smbus_data data;
int i;
if (i2c_smbus_access(file,I2C_SMBUS_READ,command,
I2C_SMBUS_BLOCK_DATA,&data))
return -1;
else {
for (i = 1; i <= data.block[0]; i++)
values[i-1] = data.block[i];
return data.block[0];
}
}
static inline __s32 i2c_smbus_write_block_data(int file, __u8 command,
__u8 length, __u8 *values)
{
union i2c_smbus_data data;
int i;
if (length > 32)
length = 32;
for (i = 1; i <= length; i++)
data.block[i] = values[i-1];
data.block[0] = length;
return i2c_smbus_access(file,I2C_SMBUS_WRITE,command,
I2C_SMBUS_BLOCK_DATA, &data);
}
/* Returns the number of read bytes */
static inline __s32 i2c_smbus_read_i2c_block_data(int file, __u8 command,
__u8 *values)
{
union i2c_smbus_data data;
int i;
if (i2c_smbus_access(file,I2C_SMBUS_READ,command,
I2C_SMBUS_I2C_BLOCK_DATA,&data))
return -1;
else {
for (i = 1; i <= data.block[0]; i++)
values[i-1] = data.block[i];
return data.block[0];
}
}
static inline __s32 i2c_smbus_write_i2c_block_data(int file, __u8 command,
__u8 length, __u8 *values)
{
union i2c_smbus_data data;
int i;
if (length > 32)
length = 32;
for (i = 1; i <= length; i++)
data.block[i] = values[i-1];
data.block[0] = length;
return i2c_smbus_access(file,I2C_SMBUS_WRITE,command,
I2C_SMBUS_I2C_BLOCK_DATA, &data);
}
/* Returns the number of read bytes */
static inline __s32 i2c_smbus_block_process_call(int file, __u8 command,
__u8 length, __u8 *values)
{
union i2c_smbus_data data;
int i;
if (length > 32)
length = 32;
for (i = 1; i <= length; i++)
data.block[i] = values[i-1];
data.block[0] = length;
if (i2c_smbus_access(file,I2C_SMBUS_WRITE,command,
I2C_SMBUS_BLOCK_PROC_CALL,&data))
return -1;
else {
for (i = 1; i <= data.block[0]; i++)
values[i-1] = data.block[i];
return data.block[0];
}
}
#endif /* LIB_I2CDEV_H */
^ 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