* Re: AW: PowerPC PCI DMA issues (prefetch/coherency?)
From: Tom Burns @ 2009-09-09 13:43 UTC (permalink / raw)
To: lebon; +Cc: Prodyut Hazarika, Andrea Zypchen, linuxppc-dev, azilkie
In-Reply-To: <4AA7AD65.7070403@lebon.org.ua>
Hi,
With the default config for the Sequoia board on 2.6.24, calling
pci_dma_sync_sg_for_cpu() results in executing
invalidate_dcache_range() in arch/ppc/kernel/misc.S from __dma_sync().
This OOPses on PPC440 since it tries to call directly the assembly
instruction dcbi, which can only be executed in supervisor mode. We
tried that before resorting to manual cache line management with
usermode-safe assembly calls.
Regards,
Tom Burns
International Datacasting Corporation
Mikhail Zolotaryov wrote:
> Hi,
>
> Why manage cache lines manually, if appropriate code is a part of
> __dma_sync / dma_sync_single_for_device of DMA API ? (implies
> CONFIG_NOT_COHERENT_CACHE enabled, as default for Sequoia Board)
>
> Prodyut Hazarika wrote:
>> Hi Adam,
>>
>>
>>> Yes, I am using the 440EPx (same as the sequoia board). Our
>>> ideDriver is DMA'ing blocks of 192-byte data over the PCI bus
>>>
>> (using
>>
>>> the Sil0680A PCI-IDE bridge). Most of the DMA's (depending on timing)
>>> end up being partially corrupted when we try to parse the data in the
>>> virtual page. We have confirmed the data is good before the PCI-IDE
>>> bridge. We are creating two 8K pages and map them to physical DMA
>>>
>> memory
>>
>>> using single-entry scatter/gather structs. When a DMA block is
>>> corrupted, we see a random portion of it (always a multiple of 16byte
>>> cache lines) is overwritten with old data from the last time the
>>>
>> buffer
>>
>>> was used.
>>
>> This looks like a cache coherency problem.
>> Can you ensure that the TLB entries corresponding to the DMA region has
>> the CacheInhibit bit set.
>> You will need a BDI connected to your system.
>>
>> Also, you will need to invalidate and flush the lines appropriately,
>> since in 440 cores,
>> L1Cache coherency is managed entirely by software.
>> Please look at drivers/net/ibm_newemac/mal.c and core.c for example on
>> how to do it.
>>
>> Thanks
>> Prodyut
>>
>> On Thu, 2009-09-03 at 13:27 -0700, Prodyut Hazarika wrote:
>>
>>> Hi Adam,
>>>
>>>
>>>> Are you sure there is L2 cache on the 440?
>>>>
>>> It depends on the SoC you are using. SoC like 460EX (Canyonlands
>>>
>> board)
>>
>>> have L2Cache.
>>> It seems you are using a Sequoia board, which has a 440EPx SoC. 440EPx
>>> has a 440 cpu core, but no L2Cache.
>>> Could you please tell me which SoC you are using?
>>> You can also refer to the appropriate dts file to see if there is L2C.
>>> For example, in canyonlands.dts (460EX based board), we have the L2C
>>> entry.
>>> L2C0: l2c {
>>> ...
>>> }
>>>
>>>
>>>> I am seeing this problem with our custom IDE driver which is based on
>>>>
>>
>>
>>>> pretty old code. Our driver uses pci_alloc_consistent() to allocate
>>>>
>> the
>>
>>>> physical DMA memory and alloc_pages() to allocate a virtual page.
>>>> It then uses pci_map_sg() to map to a scatter/gather buffer.
>>>> Perhaps I should convert these to the DMA API calls as you suggest.
>>>>
>>> Could you give more details on the consistency problem? It is a good
>>> idea to change to the new DMA APIs, but pci_alloc_consistent() should
>>> work too
>>>
>>> Thanks
>>> Prodyut
>>>
>>> On Thu, 2009-09-03 at 19:57 +1000, Benjamin Herrenschmidt wrote:
>>>
>>>> On Thu, 2009-09-03 at 09:05 +0100, Chris Pringle wrote:
>>>>
>>>>> Hi Adam,
>>>>>
>>>>> If you have a look in include/asm-ppc/pgtable.h for the following
>>>>>
>>> section:
>>>
>>>>> #ifdef CONFIG_44x
>>>>> #define _PAGE_BASE (_PAGE_PRESENT | _PAGE_ACCESSED |
>>>>>
>>> _PAGE_GUARDED)
>>>
>>>>> #else
>>>>> #define _PAGE_BASE (_PAGE_PRESENT | _PAGE_ACCESSED)
>>>>> #endif
>>>>>
>>>>> Try adding _PAGE_COHERENT to the appropriate line above and see if
>>>>>
>>> that
>>>>> fixes your issue - this causes the 'M' bit to be set on the page
>>>>>
>>> which
>>>>> sure enforce cache coherency. If it doesn't, you'll need to check
>>>>>
>>> the
>>>>> 'M' bit isn't being masked out in head_44x.S (it was originally
>>>>>
>>> masked
>>>>> out on arch/powerpc, but was fixed in later kernels when the cache
>>>>>
>>
>>
>>>>> coherency issues with non-SMP systems were resolved).
>>>>>
>>>> I have some doubts about the usefulness of doing that for 4xx.
>>>>
>> AFAIK,
>>
>>>> the 440 core just ignores M.
>>>>
>>>> The problem lies probably elsewhere. Maybe the L2 cache coherency
>>>>
>>> isn't
>>>
>>>> enabled or not working ?
>>>>
>>>> The L1 cache on 440 is simply not coherent, so drivers have to make
>>>>
>>> sure
>>>
>>>> they use the appropriate DMA APIs which will do cache flushing when
>>>> needed.
>>>>
>>>> Adam, what driver is causing you that sort of problems ?
>>>>
>>>> Cheers,
>>>> Ben.
>>>>
>>>>
>>>>
>
>
^ permalink raw reply
* Re: AW: PowerPC PCI DMA issues (prefetch/coherency?)
From: Mikhail Zolotaryov @ 2009-09-09 14:12 UTC (permalink / raw)
To: tburns; +Cc: Prodyut Hazarika, Andrea Zypchen, linuxppc-dev, azilkie
In-Reply-To: <4AA7B0EC.4000106@datacast.com>
Hi Tom,
possible solution could be to use tasklet to perform DMA-related job (as
in most cases DMA transfer is interrupt driven - makes sense).
Tom Burns wrote:
> Hi,
>
> With the default config for the Sequoia board on 2.6.24, calling
> pci_dma_sync_sg_for_cpu() results in executing
> invalidate_dcache_range() in arch/ppc/kernel/misc.S from
> __dma_sync(). This OOPses on PPC440 since it tries to call directly
> the assembly instruction dcbi, which can only be executed in
> supervisor mode. We tried that before resorting to manual cache line
> management with usermode-safe assembly calls.
>
> Regards,
> Tom Burns
> International Datacasting Corporation
>
> Mikhail Zolotaryov wrote:
>> Hi,
>>
>> Why manage cache lines manually, if appropriate code is a part of
>> __dma_sync / dma_sync_single_for_device of DMA API ? (implies
>> CONFIG_NOT_COHERENT_CACHE enabled, as default for Sequoia Board)
>>
>> Prodyut Hazarika wrote:
>>> Hi Adam,
>>>
>>>
>>>> Yes, I am using the 440EPx (same as the sequoia board). Our
>>>> ideDriver is DMA'ing blocks of 192-byte data over the PCI bus
>>>>
>>> (using
>>>
>>>> the Sil0680A PCI-IDE bridge). Most of the DMA's (depending on timing)
>>>> end up being partially corrupted when we try to parse the data in the
>>>> virtual page. We have confirmed the data is good before the PCI-IDE
>>>> bridge. We are creating two 8K pages and map them to physical DMA
>>>>
>>> memory
>>>
>>>> using single-entry scatter/gather structs. When a DMA block is
>>>> corrupted, we see a random portion of it (always a multiple of 16byte
>>>> cache lines) is overwritten with old data from the last time the
>>>>
>>> buffer
>>>
>>>> was used.
>>>
>>> This looks like a cache coherency problem.
>>> Can you ensure that the TLB entries corresponding to the DMA region has
>>> the CacheInhibit bit set.
>>> You will need a BDI connected to your system.
>>>
>>> Also, you will need to invalidate and flush the lines appropriately,
>>> since in 440 cores,
>>> L1Cache coherency is managed entirely by software.
>>> Please look at drivers/net/ibm_newemac/mal.c and core.c for example on
>>> how to do it.
>>>
>>> Thanks
>>> Prodyut
>>>
>>> On Thu, 2009-09-03 at 13:27 -0700, Prodyut Hazarika wrote:
>>>
>>>> Hi Adam,
>>>>
>>>>
>>>>> Are you sure there is L2 cache on the 440?
>>>>>
>>>> It depends on the SoC you are using. SoC like 460EX (Canyonlands
>>>>
>>> board)
>>>
>>>> have L2Cache.
>>>> It seems you are using a Sequoia board, which has a 440EPx SoC. 440EPx
>>>> has a 440 cpu core, but no L2Cache.
>>>> Could you please tell me which SoC you are using?
>>>> You can also refer to the appropriate dts file to see if there is L2C.
>>>> For example, in canyonlands.dts (460EX based board), we have the L2C
>>>> entry.
>>>> L2C0: l2c {
>>>> ...
>>>> }
>>>>
>>>>
>>>>> I am seeing this problem with our custom IDE driver which is based on
>>>>>
>>>
>>>
>>>>> pretty old code. Our driver uses pci_alloc_consistent() to allocate
>>>>>
>>> the
>>>
>>>>> physical DMA memory and alloc_pages() to allocate a virtual page.
>>>>> It then uses pci_map_sg() to map to a scatter/gather buffer.
>>>>> Perhaps I should convert these to the DMA API calls as you suggest.
>>>>>
>>>> Could you give more details on the consistency problem? It is a good
>>>> idea to change to the new DMA APIs, but pci_alloc_consistent() should
>>>> work too
>>>>
>>>> Thanks
>>>> Prodyut
>>>> On Thu, 2009-09-03 at 19:57 +1000, Benjamin Herrenschmidt wrote:
>>>>
>>>>> On Thu, 2009-09-03 at 09:05 +0100, Chris Pringle wrote:
>>>>>
>>>>>> Hi Adam,
>>>>>>
>>>>>> If you have a look in include/asm-ppc/pgtable.h for the following
>>>>>>
>>>> section:
>>>>
>>>>>> #ifdef CONFIG_44x
>>>>>> #define _PAGE_BASE (_PAGE_PRESENT | _PAGE_ACCESSED |
>>>>>>
>>>> _PAGE_GUARDED)
>>>>
>>>>>> #else
>>>>>> #define _PAGE_BASE (_PAGE_PRESENT | _PAGE_ACCESSED)
>>>>>> #endif
>>>>>>
>>>>>> Try adding _PAGE_COHERENT to the appropriate line above and see if
>>>>>>
>>>> that
>>>>>> fixes your issue - this causes the 'M' bit to be set on the page
>>>>>>
>>>> which
>>>>>> sure enforce cache coherency. If it doesn't, you'll need to check
>>>>>>
>>>> the
>>>>>> 'M' bit isn't being masked out in head_44x.S (it was originally
>>>>>>
>>>> masked
>>>>>> out on arch/powerpc, but was fixed in later kernels when the cache
>>>>>>
>>>
>>>
>>>>>> coherency issues with non-SMP systems were resolved).
>>>>>>
>>>>> I have some doubts about the usefulness of doing that for 4xx.
>>>>>
>>> AFAIK,
>>>
>>>>> the 440 core just ignores M.
>>>>>
>>>>> The problem lies probably elsewhere. Maybe the L2 cache coherency
>>>>>
>>>> isn't
>>>>
>>>>> enabled or not working ?
>>>>>
>>>>> The L1 cache on 440 is simply not coherent, so drivers have to make
>>>>>
>>>> sure
>>>>
>>>>> they use the appropriate DMA APIs which will do cache flushing when
>>>>> needed.
>>>>>
>>>>> Adam, what driver is causing you that sort of problems ?
>>>>>
>>>>> Cheers,
>>>>> Ben.
>>>>>
>>>>>
>>>>>
>>
>>
>
>
^ permalink raw reply
* Re: AW: PowerPC PCI DMA issues (prefetch/coherency?)
From: Tom Burns @ 2009-09-09 14:10 UTC (permalink / raw)
To: lebon; +Cc: Prodyut Hazarika, Andrea Zypchen, linuxppc-dev, azilkie
In-Reply-To: <4AA7B7EA.2090500@lebon.org.ua>
Hi Mikhail,
Sorry, this DMA code is in a tasklet. Are you suggesting the processor
is in supervisor mode at that time? Calling pci_dma_sync_sg_for_cpu()
from the tasklet context is what generates the OOPS. The entire oops is
as follows, if it's relevant:
Oops: kernel access of bad area, sig: 11 [#1]
NIP: c0003ab0 LR: c0010c30 CTR: 02400001
REGS: df117bd0 TRAP: 0300 Tainted: P (2.6.24.2)
MSR: 00029000 <EE,ME> CR: 44224042 XER: 20000000
DEAR: 3fd39000, ESR: 00800000
TASK = de5db7d0[157] 'cat' THREAD: df116000
GPR00: e11e5854 df117c80 de5db7d0 3fd39000 02400001 0000001f 00000002
0079a169
GPR08: 00000001 c0310000 00000000 c0010c84 24224042 101c0dac c0310000
10177000
GPR16: deb14200 df116000 e12062d0 e11f6104 de0f16c0 e11f0000 c0310000
e11f59cc
GPR24: e11f62d0 e11f0000 e11f0000 00000000 00000002 defee014 3fd39008
87d39009
NIP [c0003ab0] invalidate_dcache_range+0x1c/0x30
LR [c0010c30] __dma_sync+0x58/0xac
Call Trace:
[df117c80] [0000000a] 0xa (unreliable)
[df117c90] [e11e5854] DoTasklet+0x67c/0xc90 [ideDriverDuo_cyph]
[df117ce0] [c001ee24] tasklet_action+0x60/0xcc
[df117cf0] [c001ef04] __do_softirq+0x74/0xe0
[df117d10] [c00067a8] do_softirq+0x54/0x58
[df117d20] [c001edb4] irq_exit+0x48/0x58
[df117d30] [c00069d0] do_IRQ+0x6c/0xc0
[df117d40] [c00020e0] ret_from_except+0x0/0x18
[df117e00] [c00501e0] unmap_vmas+0x2c4/0x560
[df117e90] [c0053ebc] exit_mmap+0x64/0xec
[df117ec0] [c00171ac] mmput+0x50/0xd4
[df117ed0] [c001aef8] exit_mm+0x80/0xe0
[df117ef0] [c001c818] do_exit+0x134/0x6f8
[df117f30] [c001ce14] do_group_exit+0x38/0x74
[df117f40] [c0001a80] ret_from_syscall+0x0/0x3c
Instruction dump:
7c0018ac 38630020 4200fff8 7c0004ac 4e800020 38a0001f 7c632878 7c832050
7c842a14 5484d97f 4d820020 7c8903a6 <7c001bac> 38630020 4200fff8
7c0004ac
Kernel panic - not syncing: Aiee, killing interrupt handler!
Rebooting in 180 seconds..
Cheers,
Tom
Mikhail Zolotaryov wrote:
> Hi Tom,
>
> possible solution could be to use tasklet to perform DMA-related job
> (as in most cases DMA transfer is interrupt driven - makes sense).
>
>
> Tom Burns wrote:
>> Hi,
>>
>> With the default config for the Sequoia board on 2.6.24, calling
>> pci_dma_sync_sg_for_cpu() results in executing
>> invalidate_dcache_range() in arch/ppc/kernel/misc.S from
>> __dma_sync(). This OOPses on PPC440 since it tries to call directly
>> the assembly instruction dcbi, which can only be executed in
>> supervisor mode. We tried that before resorting to manual cache line
>> management with usermode-safe assembly calls.
>>
>> Regards,
>> Tom Burns
>> International Datacasting Corporation
>>
>> Mikhail Zolotaryov wrote:
>>> Hi,
>>>
>>> Why manage cache lines manually, if appropriate code is a part of
>>> __dma_sync / dma_sync_single_for_device of DMA API ? (implies
>>> CONFIG_NOT_COHERENT_CACHE enabled, as default for Sequoia Board)
>>>
>>> Prodyut Hazarika wrote:
>>>> Hi Adam,
>>>>
>>>>
>>>>> Yes, I am using the 440EPx (same as the sequoia board). Our
>>>>> ideDriver is DMA'ing blocks of 192-byte data over the PCI bus
>>>>>
>>>> (using
>>>>
>>>>> the Sil0680A PCI-IDE bridge). Most of the DMA's (depending on timing)
>>>>> end up being partially corrupted when we try to parse the data in the
>>>>> virtual page. We have confirmed the data is good before the PCI-IDE
>>>>> bridge. We are creating two 8K pages and map them to physical DMA
>>>>>
>>>> memory
>>>>
>>>>> using single-entry scatter/gather structs. When a DMA block is
>>>>> corrupted, we see a random portion of it (always a multiple of 16byte
>>>>> cache lines) is overwritten with old data from the last time the
>>>>>
>>>> buffer
>>>>
>>>>> was used.
>>>>
>>>> This looks like a cache coherency problem.
>>>> Can you ensure that the TLB entries corresponding to the DMA region
>>>> has
>>>> the CacheInhibit bit set.
>>>> You will need a BDI connected to your system.
>>>>
>>>> Also, you will need to invalidate and flush the lines appropriately,
>>>> since in 440 cores,
>>>> L1Cache coherency is managed entirely by software.
>>>> Please look at drivers/net/ibm_newemac/mal.c and core.c for example on
>>>> how to do it.
>>>>
>>>> Thanks
>>>> Prodyut
>>>>
>>>> On Thu, 2009-09-03 at 13:27 -0700, Prodyut Hazarika wrote:
>>>>
>>>>> Hi Adam,
>>>>>
>>>>>
>>>>>> Are you sure there is L2 cache on the 440?
>>>>>>
>>>>> It depends on the SoC you are using. SoC like 460EX (Canyonlands
>>>>>
>>>> board)
>>>>
>>>>> have L2Cache.
>>>>> It seems you are using a Sequoia board, which has a 440EPx SoC.
>>>>> 440EPx
>>>>> has a 440 cpu core, but no L2Cache.
>>>>> Could you please tell me which SoC you are using?
>>>>> You can also refer to the appropriate dts file to see if there is
>>>>> L2C.
>>>>> For example, in canyonlands.dts (460EX based board), we have the L2C
>>>>> entry.
>>>>> L2C0: l2c {
>>>>> ...
>>>>> }
>>>>>
>>>>>
>>>>>> I am seeing this problem with our custom IDE driver which is
>>>>>> based on
>>>>>>
>>>>
>>>>
>>>>>> pretty old code. Our driver uses pci_alloc_consistent() to allocate
>>>>>>
>>>> the
>>>>
>>>>>> physical DMA memory and alloc_pages() to allocate a virtual page.
>>>>>> It then uses pci_map_sg() to map to a scatter/gather buffer.
>>>>>> Perhaps I should convert these to the DMA API calls as you suggest.
>>>>>>
>>>>> Could you give more details on the consistency problem? It is a good
>>>>> idea to change to the new DMA APIs, but pci_alloc_consistent() should
>>>>> work too
>>>>>
>>>>> Thanks
>>>>> Prodyut On Thu, 2009-09-03 at 19:57 +1000, Benjamin Herrenschmidt
>>>>> wrote:
>>>>>
>>>>>> On Thu, 2009-09-03 at 09:05 +0100, Chris Pringle wrote:
>>>>>>
>>>>>>> Hi Adam,
>>>>>>>
>>>>>>> If you have a look in include/asm-ppc/pgtable.h for the following
>>>>>>>
>>>>> section:
>>>>>
>>>>>>> #ifdef CONFIG_44x
>>>>>>> #define _PAGE_BASE (_PAGE_PRESENT | _PAGE_ACCESSED |
>>>>>>>
>>>>> _PAGE_GUARDED)
>>>>>
>>>>>>> #else
>>>>>>> #define _PAGE_BASE (_PAGE_PRESENT | _PAGE_ACCESSED)
>>>>>>> #endif
>>>>>>>
>>>>>>> Try adding _PAGE_COHERENT to the appropriate line above and see if
>>>>>>>
>>>>> that
>>>>>>> fixes your issue - this causes the 'M' bit to be set on the page
>>>>>>>
>>>>> which
>>>>>>> sure enforce cache coherency. If it doesn't, you'll need to check
>>>>>>>
>>>>> the
>>>>>>> 'M' bit isn't being masked out in head_44x.S (it was originally
>>>>>>>
>>>>> masked
>>>>>>> out on arch/powerpc, but was fixed in later kernels when the cache
>>>>>>>
>>>>
>>>>
>>>>>>> coherency issues with non-SMP systems were resolved).
>>>>>>>
>>>>>> I have some doubts about the usefulness of doing that for 4xx.
>>>>>>
>>>> AFAIK,
>>>>
>>>>>> the 440 core just ignores M.
>>>>>>
>>>>>> The problem lies probably elsewhere. Maybe the L2 cache coherency
>>>>>>
>>>>> isn't
>>>>>
>>>>>> enabled or not working ?
>>>>>>
>>>>>> The L1 cache on 440 is simply not coherent, so drivers have to make
>>>>>>
>>>>> sure
>>>>>
>>>>>> they use the appropriate DMA APIs which will do cache flushing when
>>>>>> needed.
>>>>>>
>>>>>> Adam, what driver is causing you that sort of problems ?
>>>>>>
>>>>>> Cheers,
>>>>>> Ben.
>>>>>>
>>>>>>
>>>>>>
>>>
>>>
>>
>>
>
>
^ permalink raw reply
* Re: AW: PowerPC PCI DMA issues (prefetch/coherency?)
From: Mikhail Zolotaryov @ 2009-09-09 14:40 UTC (permalink / raw)
To: tburns; +Cc: Prodyut Hazarika, Andrea Zypchen, linuxppc-dev, azilkie
In-Reply-To: <4AA7B766.2040501@datacast.com>
Hi Tom,
In my case __dma_sync() calls flush_dcache_range() (it's due to
alignment) from a tasklet - no OOPS. It uses dcbf instruction instead of
dcbi - that's the difference as dcbf is not privileged.
Tom Burns wrote:
> Hi Mikhail,
>
> Sorry, this DMA code is in a tasklet. Are you suggesting the
> processor is in supervisor mode at that time? Calling
> pci_dma_sync_sg_for_cpu() from the tasklet context is what generates
> the OOPS. The entire oops is as follows, if it's relevant:
>
> Oops: kernel access of bad area, sig: 11 [#1]
> NIP: c0003ab0 LR: c0010c30 CTR: 02400001
> REGS: df117bd0 TRAP: 0300 Tainted: P (2.6.24.2)
> MSR: 00029000 <EE,ME> CR: 44224042 XER: 20000000
> DEAR: 3fd39000, ESR: 00800000
> TASK = de5db7d0[157] 'cat' THREAD: df116000
> GPR00: e11e5854 df117c80 de5db7d0 3fd39000 02400001 0000001f 00000002
> 0079a169
> GPR08: 00000001 c0310000 00000000 c0010c84 24224042 101c0dac c0310000
> 10177000
> GPR16: deb14200 df116000 e12062d0 e11f6104 de0f16c0 e11f0000 c0310000
> e11f59cc
> GPR24: e11f62d0 e11f0000 e11f0000 00000000 00000002 defee014 3fd39008
> 87d39009
> NIP [c0003ab0] invalidate_dcache_range+0x1c/0x30
> LR [c0010c30] __dma_sync+0x58/0xac
> Call Trace:
> [df117c80] [0000000a] 0xa (unreliable)
> [df117c90] [e11e5854] DoTasklet+0x67c/0xc90 [ideDriverDuo_cyph]
> [df117ce0] [c001ee24] tasklet_action+0x60/0xcc
> [df117cf0] [c001ef04] __do_softirq+0x74/0xe0
> [df117d10] [c00067a8] do_softirq+0x54/0x58
> [df117d20] [c001edb4] irq_exit+0x48/0x58
> [df117d30] [c00069d0] do_IRQ+0x6c/0xc0
> [df117d40] [c00020e0] ret_from_except+0x0/0x18
> [df117e00] [c00501e0] unmap_vmas+0x2c4/0x560
> [df117e90] [c0053ebc] exit_mmap+0x64/0xec
> [df117ec0] [c00171ac] mmput+0x50/0xd4
> [df117ed0] [c001aef8] exit_mm+0x80/0xe0
> [df117ef0] [c001c818] do_exit+0x134/0x6f8
> [df117f30] [c001ce14] do_group_exit+0x38/0x74
> [df117f40] [c0001a80] ret_from_syscall+0x0/0x3c
> Instruction dump:
> 7c0018ac 38630020 4200fff8 7c0004ac 4e800020 38a0001f 7c632878 7c832050
> 7c842a14 5484d97f 4d820020 7c8903a6 <7c001bac> 38630020 4200fff8
> 7c0004ac
> Kernel panic - not syncing: Aiee, killing interrupt handler!
> Rebooting in 180 seconds..
>
>
> Cheers,
> Tom
>
> Mikhail Zolotaryov wrote:
>> Hi Tom,
>>
>> possible solution could be to use tasklet to perform DMA-related job
>> (as in most cases DMA transfer is interrupt driven - makes sense).
>>
>>
>> Tom Burns wrote:
>>> Hi,
>>>
>>> With the default config for the Sequoia board on 2.6.24, calling
>>> pci_dma_sync_sg_for_cpu() results in executing
>>> invalidate_dcache_range() in arch/ppc/kernel/misc.S from
>>> __dma_sync(). This OOPses on PPC440 since it tries to call directly
>>> the assembly instruction dcbi, which can only be executed in
>>> supervisor mode. We tried that before resorting to manual cache
>>> line management with usermode-safe assembly calls.
>>>
>>> Regards,
>>> Tom Burns
>>> International Datacasting Corporation
>>>
>>> Mikhail Zolotaryov wrote:
>>>> Hi,
>>>>
>>>> Why manage cache lines manually, if appropriate code is a part of
>>>> __dma_sync / dma_sync_single_for_device of DMA API ? (implies
>>>> CONFIG_NOT_COHERENT_CACHE enabled, as default for Sequoia Board)
>>>>
>>>> Prodyut Hazarika wrote:
>>>>> Hi Adam,
>>>>>
>>>>>
>>>>>> Yes, I am using the 440EPx (same as the sequoia board). Our
>>>>>> ideDriver is DMA'ing blocks of 192-byte data over the PCI bus
>>>>>>
>>>>> (using
>>>>>
>>>>>> the Sil0680A PCI-IDE bridge). Most of the DMA's (depending on
>>>>>> timing)
>>>>>> end up being partially corrupted when we try to parse the data in
>>>>>> the
>>>>>> virtual page. We have confirmed the data is good before the PCI-IDE
>>>>>> bridge. We are creating two 8K pages and map them to physical DMA
>>>>>>
>>>>> memory
>>>>>
>>>>>> using single-entry scatter/gather structs. When a DMA block is
>>>>>> corrupted, we see a random portion of it (always a multiple of
>>>>>> 16byte
>>>>>> cache lines) is overwritten with old data from the last time the
>>>>>>
>>>>> buffer
>>>>>
>>>>>> was used.
>>>>>
>>>>> This looks like a cache coherency problem.
>>>>> Can you ensure that the TLB entries corresponding to the DMA
>>>>> region has
>>>>> the CacheInhibit bit set.
>>>>> You will need a BDI connected to your system.
>>>>>
>>>>> Also, you will need to invalidate and flush the lines appropriately,
>>>>> since in 440 cores,
>>>>> L1Cache coherency is managed entirely by software.
>>>>> Please look at drivers/net/ibm_newemac/mal.c and core.c for
>>>>> example on
>>>>> how to do it.
>>>>>
>>>>> Thanks
>>>>> Prodyut
>>>>>
>>>>> On Thu, 2009-09-03 at 13:27 -0700, Prodyut Hazarika wrote:
>>>>>
>>>>>> Hi Adam,
>>>>>>
>>>>>>
>>>>>>> Are you sure there is L2 cache on the 440?
>>>>>>>
>>>>>> It depends on the SoC you are using. SoC like 460EX (Canyonlands
>>>>>>
>>>>> board)
>>>>>
>>>>>> have L2Cache.
>>>>>> It seems you are using a Sequoia board, which has a 440EPx SoC.
>>>>>> 440EPx
>>>>>> has a 440 cpu core, but no L2Cache.
>>>>>> Could you please tell me which SoC you are using?
>>>>>> You can also refer to the appropriate dts file to see if there is
>>>>>> L2C.
>>>>>> For example, in canyonlands.dts (460EX based board), we have the L2C
>>>>>> entry.
>>>>>> L2C0: l2c {
>>>>>> ...
>>>>>> }
>>>>>>
>>>>>>
>>>>>>> I am seeing this problem with our custom IDE driver which is
>>>>>>> based on
>>>>>>>
>>>>>
>>>>>
>>>>>>> pretty old code. Our driver uses pci_alloc_consistent() to allocate
>>>>>>>
>>>>> the
>>>>>
>>>>>>> physical DMA memory and alloc_pages() to allocate a virtual
>>>>>>> page. It then uses pci_map_sg() to map to a scatter/gather
>>>>>>> buffer. Perhaps I should convert these to the DMA API calls as
>>>>>>> you suggest.
>>>>>>>
>>>>>> Could you give more details on the consistency problem? It is a good
>>>>>> idea to change to the new DMA APIs, but pci_alloc_consistent()
>>>>>> should
>>>>>> work too
>>>>>>
>>>>>> Thanks
>>>>>> Prodyut On Thu, 2009-09-03 at 19:57 +1000, Benjamin
>>>>>> Herrenschmidt wrote:
>>>>>>
>>>>>>> On Thu, 2009-09-03 at 09:05 +0100, Chris Pringle wrote:
>>>>>>>
>>>>>>>> Hi Adam,
>>>>>>>>
>>>>>>>> If you have a look in include/asm-ppc/pgtable.h for the following
>>>>>>>>
>>>>>> section:
>>>>>>
>>>>>>>> #ifdef CONFIG_44x
>>>>>>>> #define _PAGE_BASE (_PAGE_PRESENT | _PAGE_ACCESSED |
>>>>>>>>
>>>>>> _PAGE_GUARDED)
>>>>>>
>>>>>>>> #else
>>>>>>>> #define _PAGE_BASE (_PAGE_PRESENT | _PAGE_ACCESSED)
>>>>>>>> #endif
>>>>>>>>
>>>>>>>> Try adding _PAGE_COHERENT to the appropriate line above and see if
>>>>>>>>
>>>>>> that
>>>>>>>> fixes your issue - this causes the 'M' bit to be set on the page
>>>>>>>>
>>>>>> which
>>>>>>>> sure enforce cache coherency. If it doesn't, you'll need to check
>>>>>>>>
>>>>>> the
>>>>>>>> 'M' bit isn't being masked out in head_44x.S (it was originally
>>>>>>>>
>>>>>> masked
>>>>>>>> out on arch/powerpc, but was fixed in later kernels when the cache
>>>>>>>>
>>>>>
>>>>>
>>>>>>>> coherency issues with non-SMP systems were resolved).
>>>>>>>>
>>>>>>> I have some doubts about the usefulness of doing that for 4xx.
>>>>>>>
>>>>> AFAIK,
>>>>>
>>>>>>> the 440 core just ignores M.
>>>>>>>
>>>>>>> The problem lies probably elsewhere. Maybe the L2 cache coherency
>>>>>>>
>>>>>> isn't
>>>>>>
>>>>>>> enabled or not working ?
>>>>>>>
>>>>>>> The L1 cache on 440 is simply not coherent, so drivers have to make
>>>>>>>
>>>>>> sure
>>>>>>
>>>>>>> they use the appropriate DMA APIs which will do cache flushing when
>>>>>>> needed.
>>>>>>>
>>>>>>> Adam, what driver is causing you that sort of problems ?
>>>>>>>
>>>>>>> Cheers,
>>>>>>> Ben.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>
^ permalink raw reply
* [PATCH] 82xx: kmalloc failure ignored in ep8248e_mdio_probe()
From: Roel Kluin @ 2009-09-09 14:49 UTC (permalink / raw)
To: benh, paulus, linuxppc-dev, Andrew Morton
Prevent NULL dereference if kmalloc() fails. Also clean up if
of_mdiobus_register() returns an error.
Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
---
Found with sed: http://kernelnewbies.org/roelkluin
Please review.
diff --git a/arch/powerpc/platforms/82xx/ep8248e.c b/arch/powerpc/platforms/82xx/ep8248e.c
index 51fcae4..f9aee18 100644
--- a/arch/powerpc/platforms/82xx/ep8248e.c
+++ b/arch/powerpc/platforms/82xx/ep8248e.c
@@ -132,12 +132,25 @@ static int __devinit ep8248e_mdio_probe(struct of_device *ofdev,
return -ENOMEM;
bus->irq = kmalloc(sizeof(int) * PHY_MAX_ADDR, GFP_KERNEL);
+ if (bus->irq == NULL) {
+ ret = -ENOMEM;
+ goto err_free_bus;
+ }
bus->name = "ep8248e-mdio-bitbang";
bus->parent = &ofdev->dev;
snprintf(bus->id, MII_BUS_ID_SIZE, "%x", res.start);
- return of_mdiobus_register(bus, ofdev->node);
+ ret = of_mdiobus_register(bus, ofdev->node);
+ if (ret)
+ goto err_free_irq;
+
+ return 0;
+err_free_irq:
+ kfree(bus->irq);
+err_free_bus:
+ free_mdio_bitbang(bus);
+ return ret;
}
static int ep8248e_mdio_remove(struct of_device *ofdev)
^ permalink raw reply related
* [PATCH] powerpc: kmalloc failure ignored in vio_build_iommu_table()
From: Roel Kluin @ 2009-09-09 15:02 UTC (permalink / raw)
To: benh, paulus, linuxppc-dev, Andrew Morton
Prevent NULL dereference if kmalloc() fails.
Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
---
Found with sed: http://kernelnewbies.org/roelkluin
diff --git a/arch/powerpc/kernel/vio.c b/arch/powerpc/kernel/vio.c
index 819e59f..1f5266f 100644
--- a/arch/powerpc/kernel/vio.c
+++ b/arch/powerpc/kernel/vio.c
@@ -1054,6 +1054,8 @@ static struct iommu_table *vio_build_iommu_table(struct vio_dev *dev)
return NULL;
tbl = kmalloc(sizeof(*tbl), GFP_KERNEL);
+ if (tbl == NULL)
+ return NULL;
of_parse_dma_window(dev->dev.archdata.of_node, dma_window,
&tbl->it_index, &offset, &size);
^ permalink raw reply related
* Re: some questions [gpio]
From: Grant Likely @ 2009-09-09 17:10 UTC (permalink / raw)
To: Vitaly Bordug, linuxppc-dev, devicetree-discuss
In-Reply-To: <20090909155053.7b79f4d3@vitb-lp>
(Added devicetree and linuxppc-dev to cc: list)
On Wed, Sep 9, 2009 at 5:50 AM, Vitaly Bordug<vitb@kernel.crashing.org> wrote:
> Hi Grant,
>
> Remember I was asking some time ago about multiple gpio chips per
> device node to enable sint gpio on 52xx?
>
> I need an advice again: adding multiple chips is OK but it stores
> address of the of_gpio_chip or smth like that in device_node->data.
> And that is used in routine that grabs all data from gpios<>. Hereby
> to implement multiple chips, I'd need to store in device_node ->data
> ponter to the array of gpio_chips, and to store actual amount of those
> chips somewhere, + study of_get_gpio_flags() to traverse several
> gpio_chips. That way, gpio_cells would be 3. Seems a little overkill...
Hmmm. Refactoring the existing binding in non-backwards compatible
ways is not okay. gpio_cells cannot be changed from 2 to 3 without
breaking existing users.
> Maybe it would be better to split away gpio_sint stuff?
I don't like it much since it kind of is one block of registers.
However, a binding change must be made regardless because the current
binding has no method of describing the sint pins (or the output-only
pins for that matter). That leaves 2 options that I see:
1) Add a new node for the sint register range in the GPIO standard
registers block.
2) add some kind of offset to the 1st cell in the gpio property. (ie.
0-0x20 for simple GPIOs, 0x200-0x207 for interrupt gpios, and
0x100-0x107 for output only gpios)
I'll ignore which approach is easier to implement currently in Linux
and try to focus on what the best binding would be. Option 2 looks
pretty ugly and non-intuitive to me. The only advantage there is it
keeps things described as a single block in the mpc5200 user manual
all in one node. However, I think the clarity of option 1 wins out,
especially considering that there isn't currently any code that tries
to describe the sint pins in the device tree, so it has a smaller
likelyhood of causing breakage.
... so it would seem that my opinion on this matter is now the exact
opposite from the last time I talked to you now that I've actually
looked at the binding. :-)
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH] * mpc8313erdb.dts: Fixed eTSEC interrupt assignment.
From: Scott Wood @ 2009-09-09 18:22 UTC (permalink / raw)
To: Roland Lezuo; +Cc: linuxppc-dev
In-Reply-To: <25940478.1252060285938.JavaMail.root@viefep11.chello.at>
On Fri, Sep 04, 2009 at 12:31:25PM +0200, Roland Lezuo wrote:
> The following patch is needed to correctly assign the IRQs for the
> gianfar driver on the MPC8313ERDB-revc boards. ERR and TX are swapped
> as well as the interrupt lines for the two devices.
And it will incorrectly assign them on older revisions of the chip.
We really should have a u-boot fixup based on SVR.
-Scott
^ permalink raw reply
* Re: MPC85xx External/Internal Interrupts
From: Scott Wood @ 2009-09-09 18:28 UTC (permalink / raw)
To: Sebastian Andrzej Siewior; +Cc: linuxppc-dev, Alemao, linux-kernel
In-Reply-To: <20090906110641.GA11350@Chamillionaire.breakpoint.cc>
On Sun, Sep 06, 2009 at 01:06:41PM +0200, Sebastian Andrzej Siewior wrote:
> irq_of_parse_and_map() creates a mapping between the hardware irq number
> as specified in the device tree and the linux number (virq) which is
> used within the linux api in request_irq() for instance.
> irq_of_parse_and_map() is essential to create a mapping between those
> two. The interrupt controller on the MPC8555 (mpic) specifies the first
> few interrupt numbers as external sources followed by internal sources.
> Now, during the init sequenze of the mpic every interrupt source
> (internal and external) becomes its uniqe vector number which identifies
> the source by a number. This number is the hardware interrupt number
> i.e. that thing in the device tree. The init sequence is a for loop
> which starts at 0 for the first interrupt source which happens to be
> external interrupt 0, 1 for external interrupt 1 and so on. At the time
> it reaches the first internal interrupt source the vector number is 16.
> That's why you always have an offset of 16 between every internal
> interupt source number in the MPC855ERM document and those weired
> numbers in the device tree :)
This seems to be a common point of confusion -- we should probably put
something in the dts bindings that explains it. Am I correct in assuming
that this particular internal/external split is Freescale-specific and
not a general OpenPIC thing?
-Scott
^ permalink raw reply
* Re: Question about e300 core decrementer interrupt
From: Scott Wood @ 2009-09-09 18:43 UTC (permalink / raw)
To: Kenneth Johansson; +Cc: linuxppc-dev, Li Tao-B22598
In-Reply-To: <1252494967.10293.6.camel@localhost>
On Wed, Sep 09, 2009 at 01:16:07PM +0200, Kenneth Johansson wrote:
> On Tue, 2009-09-08 at 13:48 +0800, Li Tao-B22598 wrote:
> > Dear all,
> >
> > I have a problem in MPC5121 sleep mode. As you know MPC5121 use e300c4
> > core. When I make the e300c4 core into sleep mode, it will return to
> > full power mode when the“decrementer interrupt” occurred.
> >
> > But in the e300 core reference manual said that the “decrementer
> > interrupt”have no effect when e300 core in sleep mode, because the
> > time
> > base and decrementer are disabled while the core is in sleep mode.
> > Can anybody explain about this procedure ?
I'm not specifically familiar with MPC5121, but I'll answer from the
perspective of MPC83xx which has a similar core:
The decrementer stops ticking when the core goes to sleep. However, if a
decrementer was already pending (but masked with MSR[EE]) before you
enter sleep mode, it will cause a wakeup.
To avoid this, the decrementer is set to a very large value prior to and
after disabling interrupts. See generic_suspend_disable_irqs() in
arch/powerpc/kernel/time.c. Is this not happening for you? Which kernel
version are you using, and what mechanism are you using to go to sleep?
> I'm a bit irritated that it's not as the "solution" can mean hardware
> changes an thus it's potentially expensive.
What sort of hardware changes?
-Scott
^ permalink raw reply
* Re: [PATCH] 82xx: kmalloc failure ignored in ep8248e_mdio_probe()
From: Scott Wood @ 2009-09-09 18:46 UTC (permalink / raw)
To: Roel Kluin; +Cc: Andrew Morton, paulus, linuxppc-dev
In-Reply-To: <4AA7C095.7090009@gmail.com>
On Wed, Sep 09, 2009 at 04:49:57PM +0200, Roel Kluin wrote:
> Prevent NULL dereference if kmalloc() fails. Also clean up if
> of_mdiobus_register() returns an error.
>
> Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
Acked-by: Scott Wood <scottwood@freescale.com>
-Scott
^ permalink raw reply
* Re: [FTRACE] Enabling function_graph causes OOPS
From: Steven Rostedt @ 2009-09-09 19:42 UTC (permalink / raw)
To: Sachin Sant; +Cc: linuxppc-dev
In-Reply-To: <4AA74AE2.5090001@in.ibm.com>
On Wed, 2009-09-09 at 11:57 +0530, Sachin Sant wrote:
> Steven Rostedt wrote:
> > I'm going through old email, and I found this. Do you still see this
> > error. I don't recall seeing it myself.
> >
> I can still recreate this with 31-rc9. When i enable tracing
> with function_graph i notice the following oops. This happens
> only once. Later if i try to enable/disable tracing i don't
> get this oops message. This behavior is observed only with
> function_graph. Other tracers work fine.
>
> Oops: Kernel access of bad area, sig: 11 [#1]
> SMP NR_CPUS=1024 NUMA pSeries
> Modules linked in: ipv6 fuse loop dm_mod sr_mod ehea ibmveth sg cdrom sd_mod crc_t10dif ibmvscsic scsi_transport_srp scsi_tgt scsi_mod
> NIP: c000000000008f30 LR: c000000000008f04 CTR: 80000000000f6d68
> REGS: c00000003e98f560 TRAP: 0300 Not tainted (2.6.31-rc9)
> MSR: 8000000000009032 <EE,ME,IR,DR> CR: 24000422 XER: 00000020
> DAR: 0000000000000008, DSISR: 0000000040000000
> TASK = c00000003e953b20[2483] 'irqbalance' THREAD: c00000003e98c000 CPU: 1
> GPR00: c000000000008f04 c00000003e98f7e0 d00000000117ed38 0000000000000000
> GPR04: 0000000000000000 0000000066000000 00000000000010bf 0000000000000000
> GPR08: 0000000000000000 800000010021bb40 00000000000000ff 800000010021bb60
> GPR12: 0000000000000002 c000000001032800 0000000000000000 ffffffffeffdff68
> GPR16: 00000fffa39fd6a0 00000fffa39e6c38 c00000003ebe9c38 fffffffffffff000
> GPR20: c00000002a6cf980 c00000003e98fdf8 c00000003e98fba8 00000fffa1740000
> GPR24: fffffffffffff000 8001000003000000 ffe0000000000000 0000000000000009
> GPR28: c00000003db40000 0000000000020000 d00000000117da78 c00000003e98f850
> NIP [c000000000008f30] .mod_return_to_handler+0x2c/0x64
> LR [c000000000008f04] .mod_return_to_handler+0x0/0x64
> Call Trace:
> [c00000003e98f7e0] [c00000002a6cf980] 0xc00000002a6cf980 (unreliable)
> [c00000003e98f850] [c000000000008f04] .mod_return_to_handler+0x0/0x64
> [c00000003e98f900] [c000000000008f04] .mod_return_to_handler+0x0/0x64
> [c00000003e98f9a0] [c000000000008f04] .mod_return_to_handler+0x0/0x64
Ah, seems the bug happens to be in the module handling. Does the call
back always have .mod_return_to_handler?
This doesn't surprise me any. The module code is a bit harry, and
function graph does some crazy crap with it.
-- Steve
> [c00000003e98fa30] [c000000000008ed0] .return_to_handler+0x0/0x34 (.bad_page_fault+0xc8/0xe8)
> [c00000003e98fb30] [c000000000008ed0] .return_to_handler+0x0/0x34 (handle_page_fault+0x3c/0x5c)
> [c00000003e98fc20] [c000000000008ed0] .return_to_handler+0x0/0x34 (.ehea_h_query_ehea_port+0x74/0x9c [ehea])
> [c00000003e98fcd0] [c000000000008ed0] .return_to_handler+0x0/0x34 (.ehea_get_stats+0xa0/0x1d0 [ehea])
> [c00000003e98fd80] [c000000000008ed0] .return_to_handler+0x0/0x34 (.dev_get_stats+0x50/0xec)
> [c00000003e98fe30] [c000000000008ed0] .return_to_handler+0x0/0x34 (.dev_seq_show+0x5c/0x140)
> Instruction dump:
> 4e800020 f881ffe0 f861ffe8 f841fff0 fbe1fff8 7c3f0b78 f821ff91 3c800000
> 60840000 788407c6 64840000 60840000 <e8440008> 48126375 60000000 7c6803a6
> ---[ end trace bb43efc994aed790 ]---
>
> function_graph traces are recorded and can be retrieved using
> /sys/kernel/debug/tracing/trace.
>
> 1) 3.936 us | }
> 1) | .release_console_sem() {
> 1) 0.594 us | ._spin_lock_irqsave();
> 1) 0.560 us | ._call_console_drivers();
> 1) 0.580 us | ._call_console_drivers();
> 1) 0.582 us | ._spin_lock_irqsave();
> 1) | .up() {
> 1) 0.592 us | ._spin_lock_irqsave();
> 1) 0.556 us | ._spin_unlock_irqrestore();
> 1) 2.842 us | }
> 1) 0.588 us | ._spin_unlock_irqrestore();
> 1) 9.750 us | }
> 1) + 75.274 us | }
> 1) | .die() {
> 1) | .oops_enter() {
>
> Thanks
> -Sachin
>
^ permalink raw reply
* Re: [PATCH] * mpc8313erdb.dts: Fixed eTSEC interrupt assignment.
From: Kumar Gala @ 2009-09-09 20:28 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, Roland Lezuo
In-Reply-To: <20090909182227.GA8215@b07421-ec1.am.freescale.net>
On Sep 9, 2009, at 1:22 PM, Scott Wood wrote:
> On Fri, Sep 04, 2009 at 12:31:25PM +0200, Roland Lezuo wrote:
>> The following patch is needed to correctly assign the IRQs for the
>> gianfar driver on the MPC8313ERDB-revc boards. ERR and TX are swapped
>> as well as the interrupt lines for the two devices.
>
> And it will incorrectly assign them on older revisions of the chip.
>
> We really should have a u-boot fixup based on SVR.
I felt like Kim did this.
- k
^ permalink raw reply
* Re: [PATCH] * mpc8313erdb.dts: Fixed eTSEC interrupt assignment.
From: Kim Phillips @ 2009-09-09 20:35 UTC (permalink / raw)
To: Kumar Gala; +Cc: Scott Wood, linuxppc-dev, Roland Lezuo
In-Reply-To: <F7AA2B23-A019-4E11-993D-AF0F6F1FD50A@kernel.crashing.org>
On Wed, 9 Sep 2009 15:28:01 -0500
Kumar Gala <galak@kernel.crashing.org> wrote:
>
> On Sep 9, 2009, at 1:22 PM, Scott Wood wrote:
>
> > On Fri, Sep 04, 2009 at 12:31:25PM +0200, Roland Lezuo wrote:
> >> The following patch is needed to correctly assign the IRQs for the
> >> gianfar driver on the MPC8313ERDB-revc boards. ERR and TX are swapped
> >> as well as the interrupt lines for the two devices.
> >
> > And it will incorrectly assign them on older revisions of the chip.
> >
> > We really should have a u-boot fixup based on SVR.
definitely.
> I felt like Kim did this.
I never got my hands on a Rev. C board. What's the SVR on it? I think
this is also valid for Rev. B boards, and I don't have one of those
either.
Kim
^ permalink raw reply
* Re: [PATCH] * mpc8313erdb.dts: Fixed eTSEC interrupt assignment.
From: Mark Bishop @ 2009-09-09 20:49 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20090909182227.GA8215@b07421-ec1.am.freescale.net>
Quoting Scott Wood <scottwood@freescale.com>:
> On Fri, Sep 04, 2009 at 12:31:25PM +0200, Roland Lezuo wrote:
>> The following patch is needed to correctly assign the IRQs for the
>> gianfar driver on the MPC8313ERDB-revc boards. ERR and TX are swapped
>> as well as the interrupt lines for the two devices.
>
> And it will incorrectly assign them on older revisions of the chip.
>
> We really should have a u-boot fixup based on SVR.
>
> -Scott
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
>
>
I have both versions of the boards and I use two versions of the .dts
file. Actually, four, two to support the old style uboot .dts that
comes with Freescale's BSP and 2 that support the newer uboot.
^ permalink raw reply
* Removing deprecated drivers from drivers/i2c/chips
From: Wolfram Sang @ 2009-09-09 21:22 UTC (permalink / raw)
To: linux-i2c; +Cc: linuxppc-dev, uclinux-dist-devel, linux-arm-kernel, linux-mips
Hi,
continuing the quest to clean up and ultimately remove the drivers/i2c/chips
directory, this patch series removes three drivers for GPIO-expanders which are
obsoleted and marked as deprecated for more than a year. The newer (and better)
drivers can be found in drivers/gpio.
As it is ensured that the newer drivers cover the same i2c_device_ids, all
platform_devices will still match. Some defconfig updates may be necessary
though, but according to [1] this is left to the arch|platform-maintainers
(also as most defconfigs are quite outdated). For that reason, I put the
relevant arch-mailing-lists to Cc. Comments are welcome.
Regards,
Wolfram
[1] http://lkml.org/lkml/2009/5/7/34
^ permalink raw reply
* [PATCH 1/4] gpio/pcf857x: copy i2c_device_id from old pcf8574-driver
From: Wolfram Sang @ 2009-09-09 21:22 UTC (permalink / raw)
To: linux-i2c
Cc: linux-mips, David Brownell, linuxppc-dev, Jean Delvare,
uclinux-dist-devel, linux-arm-kernel
In-Reply-To: <1252531371-14866-1-git-send-email-w.sang@pengutronix.de>
The deprecated pcf8574 driver is going to be removed. Make sure this
replacement-driver inherits all i2c_device_ids for a smooth transition.
Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
Cc: David Brownell <dbrownell@users.sourceforge.net>
Cc: Jean Delvare <khali@linux-fr.org>
---
drivers/gpio/pcf857x.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/gpio/pcf857x.c b/drivers/gpio/pcf857x.c
index 9525724..3f1ec1e 100644
--- a/drivers/gpio/pcf857x.c
+++ b/drivers/gpio/pcf857x.c
@@ -28,6 +28,7 @@
static const struct i2c_device_id pcf857x_id[] = {
{ "pcf8574", 8 },
+ { "pcf8574a", 8 },
{ "pca8574", 8 },
{ "pca9670", 8 },
{ "pca9672", 8 },
--
1.6.3.3
^ permalink raw reply related
* [PATCH 2/4] i2c/chips: Remove deprecated pcf8575-driver
From: Wolfram Sang @ 2009-09-09 21:22 UTC (permalink / raw)
To: linux-i2c
Cc: linux-mips, Bart Van Assche, linuxppc-dev, Jean Delvare,
uclinux-dist-devel, linux-arm-kernel
In-Reply-To: <1252531371-14866-1-git-send-email-w.sang@pengutronix.de>
The pcf8575-driver in drivers/i2c/chips which just exports its register to
sysfs is superseeded by drivers/gpio/pcf857x.c which properly uses the gpiolib.
As this driver has been deprecated for more than a year, finally remove it.
Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
Cc: Bart Van Assche <bart.vanassche@gmail.com>
Cc: Jean Delvare <khali@linux-fr.org>
---
Documentation/i2c/chips/pcf8575 | 69 --------------
drivers/i2c/chips/Kconfig | 18 ----
drivers/i2c/chips/Makefile | 1 -
drivers/i2c/chips/pcf8575.c | 198 ---------------------------------------
4 files changed, 0 insertions(+), 286 deletions(-)
delete mode 100644 Documentation/i2c/chips/pcf8575
delete mode 100644 drivers/i2c/chips/pcf8575.c
diff --git a/Documentation/i2c/chips/pcf8575 b/Documentation/i2c/chips/pcf8575
deleted file mode 100644
index 40b268e..0000000
--- a/Documentation/i2c/chips/pcf8575
+++ /dev/null
@@ -1,69 +0,0 @@
-About the PCF8575 chip and the pcf8575 kernel driver
-====================================================
-
-The PCF8575 chip is produced by the following manufacturers:
-
- * Philips NXP
- http://www.nxp.com/#/pip/cb=[type=product,path=50807/41735/41850,final=PCF8575_3]|pip=[pip=PCF8575_3][0]
-
- * Texas Instruments
- http://focus.ti.com/docs/prod/folders/print/pcf8575.html
-
-
-Some vendors sell small PCB's with the PCF8575 mounted on it. You can connect
-such a board to a Linux host via e.g. an USB to I2C interface. Examples of
-PCB boards with a PCF8575:
-
- * SFE Breakout Board for PCF8575 I2C Expander by RobotShop
- http://www.robotshop.ca/home/products/robot-parts/electronics/adapters-converters/sfe-pcf8575-i2c-expander-board.html
-
- * Breakout Board for PCF8575 I2C Expander by Spark Fun Electronics
- http://www.sparkfun.com/commerce/product_info.php?products_id=8130
-
-
-Description
------------
-The PCF8575 chip is a 16-bit I/O expander for the I2C bus. Up to eight of
-these chips can be connected to the same I2C bus. You can find this
-chip on some custom designed hardware, but you won't find it on PC
-motherboards.
-
-The PCF8575 chip consists of a 16-bit quasi-bidirectional port and an I2C-bus
-interface. Each of the sixteen I/O's can be independently used as an input or
-an output. To set up an I/O pin as an input, you have to write a 1 to the
-corresponding output.
-
-For more information please see the datasheet.
-
-
-Detection
----------
-
-There is no method known to detect whether a chip on a given I2C address is
-a PCF8575 or whether it is any other I2C device, so you have to pass the I2C
-bus and address of the installed PCF8575 devices explicitly to the driver at
-load time via the force=... parameter.
-
-/sys interface
---------------
-
-For each address on which a PCF8575 chip was found or forced the following
-files will be created under /sys:
-* /sys/bus/i2c/devices/<bus>-<address>/read
-* /sys/bus/i2c/devices/<bus>-<address>/write
-where bus is the I2C bus number (0, 1, ...) and address is the four-digit
-hexadecimal representation of the 7-bit I2C address of the PCF8575
-(0020 .. 0027).
-
-The read file is read-only. Reading it will trigger an I2C read and will hence
-report the current input state for the pins configured as inputs, and the
-current output value for the pins configured as outputs.
-
-The write file is read-write. Writing a value to it will configure all pins
-as output for which the corresponding bit is zero. Reading the write file will
-return the value last written, or -EAGAIN if no value has yet been written to
-the write file.
-
-On module initialization the configuration of the chip is not changed -- the
-chip is left in the state it was already configured in through either power-up
-or through previous I2C write actions.
diff --git a/drivers/i2c/chips/Kconfig b/drivers/i2c/chips/Kconfig
index 02d746c..1b5455e 100644
--- a/drivers/i2c/chips/Kconfig
+++ b/drivers/i2c/chips/Kconfig
@@ -33,24 +33,6 @@ config SENSORS_PCF8574
These devices are hard to detect and rarely found on mainstream
hardware. If unsure, say N.
-config PCF8575
- tristate "Philips PCF8575 (DEPRECATED)"
- default n
- depends on GPIO_PCF857X = "n"
- help
- If you say yes here you get support for Philips PCF8575 chip.
- This chip is a 16-bit I/O expander for the I2C bus. Several other
- chip manufacturers sell equivalent chips, e.g. Texas Instruments.
-
- This driver can also be built as a module. If so, the module
- will be called pcf8575.
-
- This driver is deprecated and will be dropped soon. Use
- drivers/gpio/pcf857x.c instead.
-
- This device is hard to detect and is rarely found on mainstream
- hardware. If unsure, say N.
-
config SENSORS_PCA9539
tristate "Philips PCA9539 16-bit I/O port (DEPRECATED)"
depends on EXPERIMENTAL && GPIO_PCA953X = "n"
diff --git a/drivers/i2c/chips/Makefile b/drivers/i2c/chips/Makefile
index f4680d1..fceb377 100644
--- a/drivers/i2c/chips/Makefile
+++ b/drivers/i2c/chips/Makefile
@@ -13,7 +13,6 @@
obj-$(CONFIG_DS1682) += ds1682.o
obj-$(CONFIG_SENSORS_PCA9539) += pca9539.o
obj-$(CONFIG_SENSORS_PCF8574) += pcf8574.o
-obj-$(CONFIG_PCF8575) += pcf8575.o
obj-$(CONFIG_SENSORS_TSL2550) += tsl2550.o
ifeq ($(CONFIG_I2C_DEBUG_CHIP),y)
diff --git a/drivers/i2c/chips/pcf8575.c b/drivers/i2c/chips/pcf8575.c
deleted file mode 100644
index 07fd7cb..0000000
--- a/drivers/i2c/chips/pcf8575.c
+++ /dev/null
@@ -1,198 +0,0 @@
-/*
- pcf8575.c
-
- About the PCF8575 chip: the PCF8575 is a 16-bit I/O expander for the I2C bus
- produced by a.o. Philips Semiconductors.
-
- Copyright (C) 2006 Michael Hennerich, Analog Devices Inc.
- <hennerich@blackfin.uclinux.org>
- Based on pcf8574.c.
-
- Copyright (c) 2007 Bart Van Assche <bart.vanassche@gmail.com>.
- Ported this driver from ucLinux to the mainstream Linux kernel.
-
- 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.
-*/
-
-#include <linux/module.h>
-#include <linux/init.h>
-#include <linux/i2c.h>
-#include <linux/slab.h> /* kzalloc() */
-#include <linux/sysfs.h> /* sysfs_create_group() */
-
-/* Addresses to scan: none, device can't be detected */
-static const unsigned short normal_i2c[] = { I2C_CLIENT_END };
-
-/* Insmod parameters */
-I2C_CLIENT_INSMOD;
-
-
-/* Each client has this additional data */
-struct pcf8575_data {
- int write; /* last written value, or error code */
-};
-
-/* following are the sysfs callback functions */
-static ssize_t show_read(struct device *dev, struct device_attribute *attr,
- char *buf)
-{
- struct i2c_client *client = to_i2c_client(dev);
- u16 val;
- u8 iopin_state[2];
-
- i2c_master_recv(client, iopin_state, 2);
-
- val = iopin_state[0];
- val |= iopin_state[1] << 8;
-
- return sprintf(buf, "%u\n", val);
-}
-
-static DEVICE_ATTR(read, S_IRUGO, show_read, NULL);
-
-static ssize_t show_write(struct device *dev, struct device_attribute *attr,
- char *buf)
-{
- struct pcf8575_data *data = dev_get_drvdata(dev);
- if (data->write < 0)
- return data->write;
- return sprintf(buf, "%d\n", data->write);
-}
-
-static ssize_t set_write(struct device *dev, struct device_attribute *attr,
- const char *buf, size_t count)
-{
- struct i2c_client *client = to_i2c_client(dev);
- struct pcf8575_data *data = i2c_get_clientdata(client);
- unsigned long val = simple_strtoul(buf, NULL, 10);
- u8 iopin_state[2];
-
- if (val > 0xffff)
- return -EINVAL;
-
- data->write = val;
-
- iopin_state[0] = val & 0xFF;
- iopin_state[1] = val >> 8;
-
- i2c_master_send(client, iopin_state, 2);
-
- return count;
-}
-
-static DEVICE_ATTR(write, S_IWUSR | S_IRUGO, show_write, set_write);
-
-static struct attribute *pcf8575_attributes[] = {
- &dev_attr_read.attr,
- &dev_attr_write.attr,
- NULL
-};
-
-static const struct attribute_group pcf8575_attr_group = {
- .attrs = pcf8575_attributes,
-};
-
-/*
- * Real code
- */
-
-/* Return 0 if detection is successful, -ENODEV otherwise */
-static int pcf8575_detect(struct i2c_client *client, int kind,
- struct i2c_board_info *info)
-{
- struct i2c_adapter *adapter = client->adapter;
-
- if (!i2c_check_functionality(adapter, I2C_FUNC_I2C))
- return -ENODEV;
-
- /* This is the place to detect whether the chip at the specified
- address really is a PCF8575 chip. However, there is no method known
- to detect whether an I2C chip is a PCF8575 or any other I2C chip. */
-
- strlcpy(info->type, "pcf8575", I2C_NAME_SIZE);
-
- return 0;
-}
-
-static int pcf8575_probe(struct i2c_client *client,
- const struct i2c_device_id *id)
-{
- struct pcf8575_data *data;
- int err;
-
- data = kzalloc(sizeof(struct pcf8575_data), GFP_KERNEL);
- if (!data) {
- err = -ENOMEM;
- goto exit;
- }
-
- i2c_set_clientdata(client, data);
- data->write = -EAGAIN;
-
- /* Register sysfs hooks */
- err = sysfs_create_group(&client->dev.kobj, &pcf8575_attr_group);
- if (err)
- goto exit_free;
-
- return 0;
-
-exit_free:
- kfree(data);
-exit:
- return err;
-}
-
-static int pcf8575_remove(struct i2c_client *client)
-{
- sysfs_remove_group(&client->dev.kobj, &pcf8575_attr_group);
- kfree(i2c_get_clientdata(client));
- return 0;
-}
-
-static const struct i2c_device_id pcf8575_id[] = {
- { "pcf8575", 0 },
- { }
-};
-
-static struct i2c_driver pcf8575_driver = {
- .driver = {
- .owner = THIS_MODULE,
- .name = "pcf8575",
- },
- .probe = pcf8575_probe,
- .remove = pcf8575_remove,
- .id_table = pcf8575_id,
-
- .detect = pcf8575_detect,
- .address_data = &addr_data,
-};
-
-static int __init pcf8575_init(void)
-{
- return i2c_add_driver(&pcf8575_driver);
-}
-
-static void __exit pcf8575_exit(void)
-{
- i2c_del_driver(&pcf8575_driver);
-}
-
-MODULE_AUTHOR("Michael Hennerich <hennerich@blackfin.uclinux.org>, "
- "Bart Van Assche <bart.vanassche@gmail.com>");
-MODULE_DESCRIPTION("pcf8575 driver");
-MODULE_LICENSE("GPL");
-
-module_init(pcf8575_init);
-module_exit(pcf8575_exit);
--
1.6.3.3
^ permalink raw reply related
* [PATCH 3/4] i2c/chips: Remove deprecated pca9539-driver
From: Wolfram Sang @ 2009-09-09 21:22 UTC (permalink / raw)
To: linux-i2c
Cc: linux-mips, Ben Gardner, linuxppc-dev, Jean Delvare,
uclinux-dist-devel, linux-arm-kernel
In-Reply-To: <1252531371-14866-1-git-send-email-w.sang@pengutronix.de>
The pca9539-driver in drivers/i2c/chips which just exports its registers to
sysfs is superseeded by drivers/gpio/pca953x.c which properly uses the gpiolib.
As this driver has been deprecated for more than a year, finally remove it.
Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
Cc: Ben Gardner <gardner.ben@gmail.com>
Cc: Jean Delvare <khali@linux-fr.org>
---
Documentation/i2c/chips/pca9539 | 58 ---------------
drivers/i2c/chips/Kconfig | 13 ----
drivers/i2c/chips/Makefile | 1 -
drivers/i2c/chips/pca9539.c | 152 ---------------------------------------
4 files changed, 0 insertions(+), 224 deletions(-)
delete mode 100644 Documentation/i2c/chips/pca9539
delete mode 100644 drivers/i2c/chips/pca9539.c
diff --git a/Documentation/i2c/chips/pca9539 b/Documentation/i2c/chips/pca9539
deleted file mode 100644
index 6aff890..0000000
--- a/Documentation/i2c/chips/pca9539
+++ /dev/null
@@ -1,58 +0,0 @@
-Kernel driver pca9539
-=====================
-
-NOTE: this driver is deprecated and will be dropped soon, use
-drivers/gpio/pca9539.c instead.
-
-Supported chips:
- * Philips PCA9539
- Prefix: 'pca9539'
- Addresses scanned: none
- Datasheet:
- http://www.semiconductors.philips.com/acrobat/datasheets/PCA9539_2.pdf
-
-Author: Ben Gardner <bgardner@wabtec.com>
-
-
-Description
------------
-
-The Philips PCA9539 is a 16 bit low power I/O device.
-All 16 lines can be individually configured as an input or output.
-The input sense can also be inverted.
-The 16 lines are split between two bytes.
-
-
-Detection
----------
-
-The PCA9539 is difficult to detect and not commonly found in PC machines,
-so you have to pass the I2C bus and address of the installed PCA9539
-devices explicitly to the driver at load time via the force=... parameter.
-
-
-Sysfs entries
--------------
-
-Each is a byte that maps to the 8 I/O bits.
-A '0' suffix is for bits 0-7, while '1' is for bits 8-15.
-
-input[01] - read the current value
-output[01] - sets the output value
-direction[01] - direction of each bit: 1=input, 0=output
-invert[01] - toggle the input bit sense
-
-input reads the actual state of the line and is always available.
-The direction defaults to input for all channels.
-
-
-General Remarks
----------------
-
-Note that each output, direction, and invert entry controls 8 lines.
-You should use the read, modify, write sequence.
-For example. to set output bit 0 of 1.
- val=$(cat output0)
- val=$(( $val | 1 ))
- echo $val > output0
-
diff --git a/drivers/i2c/chips/Kconfig b/drivers/i2c/chips/Kconfig
index 1b5455e..8cd1a7f 100644
--- a/drivers/i2c/chips/Kconfig
+++ b/drivers/i2c/chips/Kconfig
@@ -33,19 +33,6 @@ config SENSORS_PCF8574
These devices are hard to detect and rarely found on mainstream
hardware. If unsure, say N.
-config SENSORS_PCA9539
- tristate "Philips PCA9539 16-bit I/O port (DEPRECATED)"
- depends on EXPERIMENTAL && GPIO_PCA953X = "n"
- help
- If you say yes here you get support for the Philips PCA9539
- 16-bit I/O port.
-
- This driver can also be built as a module. If so, the module
- will be called pca9539.
-
- This driver is deprecated and will be dropped soon. Use
- drivers/gpio/pca953x.c instead.
-
config SENSORS_TSL2550
tristate "Taos TSL2550 ambient light sensor"
depends on EXPERIMENTAL
diff --git a/drivers/i2c/chips/Makefile b/drivers/i2c/chips/Makefile
index fceb377..8cd778d 100644
--- a/drivers/i2c/chips/Makefile
+++ b/drivers/i2c/chips/Makefile
@@ -11,7 +11,6 @@
#
obj-$(CONFIG_DS1682) += ds1682.o
-obj-$(CONFIG_SENSORS_PCA9539) += pca9539.o
obj-$(CONFIG_SENSORS_PCF8574) += pcf8574.o
obj-$(CONFIG_SENSORS_TSL2550) += tsl2550.o
diff --git a/drivers/i2c/chips/pca9539.c b/drivers/i2c/chips/pca9539.c
deleted file mode 100644
index 270de4e..0000000
--- a/drivers/i2c/chips/pca9539.c
+++ /dev/null
@@ -1,152 +0,0 @@
-/*
- pca9539.c - 16-bit I/O port with interrupt and reset
-
- Copyright (C) 2005 Ben Gardner <bgardner@wabtec.com>
-
- 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; version 2 of the License.
-*/
-
-#include <linux/module.h>
-#include <linux/init.h>
-#include <linux/slab.h>
-#include <linux/i2c.h>
-#include <linux/hwmon-sysfs.h>
-
-/* Addresses to scan: none, device is not autodetected */
-static const unsigned short normal_i2c[] = { I2C_CLIENT_END };
-
-/* Insmod parameters */
-I2C_CLIENT_INSMOD_1(pca9539);
-
-enum pca9539_cmd
-{
- PCA9539_INPUT_0 = 0,
- PCA9539_INPUT_1 = 1,
- PCA9539_OUTPUT_0 = 2,
- PCA9539_OUTPUT_1 = 3,
- PCA9539_INVERT_0 = 4,
- PCA9539_INVERT_1 = 5,
- PCA9539_DIRECTION_0 = 6,
- PCA9539_DIRECTION_1 = 7,
-};
-
-/* following are the sysfs callback functions */
-static ssize_t pca9539_show(struct device *dev, struct device_attribute *attr,
- char *buf)
-{
- struct sensor_device_attribute *psa = to_sensor_dev_attr(attr);
- struct i2c_client *client = to_i2c_client(dev);
- return sprintf(buf, "%d\n", i2c_smbus_read_byte_data(client,
- psa->index));
-}
-
-static ssize_t pca9539_store(struct device *dev, struct device_attribute *attr,
- const char *buf, size_t count)
-{
- struct sensor_device_attribute *psa = to_sensor_dev_attr(attr);
- struct i2c_client *client = to_i2c_client(dev);
- unsigned long val = simple_strtoul(buf, NULL, 0);
- if (val > 0xff)
- return -EINVAL;
- i2c_smbus_write_byte_data(client, psa->index, val);
- return count;
-}
-
-/* Define the device attributes */
-
-#define PCA9539_ENTRY_RO(name, cmd_idx) \
- static SENSOR_DEVICE_ATTR(name, S_IRUGO, pca9539_show, NULL, cmd_idx)
-
-#define PCA9539_ENTRY_RW(name, cmd_idx) \
- static SENSOR_DEVICE_ATTR(name, S_IRUGO | S_IWUSR, pca9539_show, \
- pca9539_store, cmd_idx)
-
-PCA9539_ENTRY_RO(input0, PCA9539_INPUT_0);
-PCA9539_ENTRY_RO(input1, PCA9539_INPUT_1);
-PCA9539_ENTRY_RW(output0, PCA9539_OUTPUT_0);
-PCA9539_ENTRY_RW(output1, PCA9539_OUTPUT_1);
-PCA9539_ENTRY_RW(invert0, PCA9539_INVERT_0);
-PCA9539_ENTRY_RW(invert1, PCA9539_INVERT_1);
-PCA9539_ENTRY_RW(direction0, PCA9539_DIRECTION_0);
-PCA9539_ENTRY_RW(direction1, PCA9539_DIRECTION_1);
-
-static struct attribute *pca9539_attributes[] = {
- &sensor_dev_attr_input0.dev_attr.attr,
- &sensor_dev_attr_input1.dev_attr.attr,
- &sensor_dev_attr_output0.dev_attr.attr,
- &sensor_dev_attr_output1.dev_attr.attr,
- &sensor_dev_attr_invert0.dev_attr.attr,
- &sensor_dev_attr_invert1.dev_attr.attr,
- &sensor_dev_attr_direction0.dev_attr.attr,
- &sensor_dev_attr_direction1.dev_attr.attr,
- NULL
-};
-
-static struct attribute_group pca9539_defattr_group = {
- .attrs = pca9539_attributes,
-};
-
-/* Return 0 if detection is successful, -ENODEV otherwise */
-static int pca9539_detect(struct i2c_client *client, int kind,
- struct i2c_board_info *info)
-{
- struct i2c_adapter *adapter = client->adapter;
-
- if (!i2c_check_functionality(adapter, I2C_FUNC_SMBUS_BYTE_DATA))
- return -ENODEV;
-
- strlcpy(info->type, "pca9539", I2C_NAME_SIZE);
-
- return 0;
-}
-
-static int pca9539_probe(struct i2c_client *client,
- const struct i2c_device_id *id)
-{
- /* Register sysfs hooks */
- return sysfs_create_group(&client->dev.kobj,
- &pca9539_defattr_group);
-}
-
-static int pca9539_remove(struct i2c_client *client)
-{
- sysfs_remove_group(&client->dev.kobj, &pca9539_defattr_group);
- return 0;
-}
-
-static const struct i2c_device_id pca9539_id[] = {
- { "pca9539", 0 },
- { }
-};
-
-static struct i2c_driver pca9539_driver = {
- .driver = {
- .name = "pca9539",
- },
- .probe = pca9539_probe,
- .remove = pca9539_remove,
- .id_table = pca9539_id,
-
- .detect = pca9539_detect,
- .address_data = &addr_data,
-};
-
-static int __init pca9539_init(void)
-{
- return i2c_add_driver(&pca9539_driver);
-}
-
-static void __exit pca9539_exit(void)
-{
- i2c_del_driver(&pca9539_driver);
-}
-
-MODULE_AUTHOR("Ben Gardner <bgardner@wabtec.com>");
-MODULE_DESCRIPTION("PCA9539 driver");
-MODULE_LICENSE("GPL");
-
-module_init(pca9539_init);
-module_exit(pca9539_exit);
-
--
1.6.3.3
^ permalink raw reply related
* [PATCH 4/4] i2c/chips: Remove deprecated pcf8574-driver
From: Wolfram Sang @ 2009-09-09 21:22 UTC (permalink / raw)
To: linux-i2c
Cc: linux-mips, linuxppc-dev, linux-arm-kernel, Jean Delvare,
uclinux-dist-devel, Aurelien Jarno
In-Reply-To: <1252531371-14866-1-git-send-email-w.sang@pengutronix.de>
The pcf8574-driver in drivers/i2c/chips which just exports its register to
sysfs is superseeded by drivers/gpio/pcf857x.c which properly uses the gpiolib.
As this driver has been deprecated for more than a year, finally remove it.
Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
Cc: Aurelien Jarno <aurelien@aurel32.net>
Cc: Jean Delvare <khali@linux-fr.org>
---
Documentation/i2c/chips/pcf8574 | 65 ------------
drivers/i2c/chips/Kconfig | 17 ---
drivers/i2c/chips/Makefile | 1 -
drivers/i2c/chips/pcf8574.c | 215 ---------------------------------------
4 files changed, 0 insertions(+), 298 deletions(-)
delete mode 100644 Documentation/i2c/chips/pcf8574
delete mode 100644 drivers/i2c/chips/pcf8574.c
diff --git a/Documentation/i2c/chips/pcf8574 b/Documentation/i2c/chips/pcf8574
deleted file mode 100644
index 235815c..0000000
--- a/Documentation/i2c/chips/pcf8574
+++ /dev/null
@@ -1,65 +0,0 @@
-Kernel driver pcf8574
-=====================
-
-Supported chips:
- * Philips PCF8574
- Prefix: 'pcf8574'
- Addresses scanned: none
- Datasheet: Publicly available at the Philips Semiconductors website
- http://www.semiconductors.philips.com/pip/PCF8574P.html
-
- * Philips PCF8574A
- Prefix: 'pcf8574a'
- Addresses scanned: none
- Datasheet: Publicly available at the Philips Semiconductors website
- http://www.semiconductors.philips.com/pip/PCF8574P.html
-
-Authors:
- Frodo Looijaard <frodol@dds.nl>,
- Philip Edelbrock <phil@netroedge.com>,
- Dan Eaton <dan.eaton@rocketlogix.com>,
- Aurelien Jarno <aurelien@aurel32.net>,
- Jean Delvare <khali@linux-fr.org>,
-
-
-Description
------------
-The PCF8574(A) is an 8-bit I/O expander for the I2C bus produced by Philips
-Semiconductors. It is designed to provide a byte I2C interface to up to 16
-separate devices (8 x PCF8574 and 8 x PCF8574A).
-
-This device consists of a quasi-bidirectional port. Each of the eight I/Os
-can be independently used as an input or output. To setup an I/O as an
-input, you have to write a 1 to the corresponding output.
-
-For more informations see the datasheet.
-
-
-Accessing PCF8574(A) via /sys interface
--------------------------------------
-
-The PCF8574(A) is plainly impossible to detect ! Stupid chip.
-So, you have to pass the I2C bus and address of the installed PCF857A
-and PCF8574A devices explicitly to the driver at load time via the
-force=... parameter.
-
-On detection (i.e. insmod, modprobe et al.), directories are being
-created for each detected PCF8574(A):
-
-/sys/bus/i2c/devices/<0>-<1>/
-where <0> is the bus the chip was detected on (e. g. i2c-0)
-and <1> the chip address ([20..27] or [38..3f]):
-
-(example: /sys/bus/i2c/devices/1-0020/)
-
-Inside these directories, there are two files each:
-read and write (and one file with chip name).
-
-The read file is read-only. Reading gives you the current I/O input
-if the corresponding output is set as 1, otherwise the current output
-value, that is to say 0.
-
-The write file is read/write. Writing a value outputs it on the I/O
-port. Reading returns the last written value. As it is not possible
-to read this value from the chip, you need to write at least once to
-this file before you can read back from it.
diff --git a/drivers/i2c/chips/Kconfig b/drivers/i2c/chips/Kconfig
index 8cd1a7f..f9618f4 100644
--- a/drivers/i2c/chips/Kconfig
+++ b/drivers/i2c/chips/Kconfig
@@ -16,23 +16,6 @@ config DS1682
This driver can also be built as a module. If so, the module
will be called ds1682.
-config SENSORS_PCF8574
- tristate "Philips PCF8574 and PCF8574A (DEPRECATED)"
- depends on EXPERIMENTAL && GPIO_PCF857X = "n"
- default n
- help
- If you say yes here you get support for Philips PCF8574 and
- PCF8574A chips. These chips are 8-bit I/O expanders for the I2C bus.
-
- This driver can also be built as a module. If so, the module
- will be called pcf8574.
-
- This driver is deprecated and will be dropped soon. Use
- drivers/gpio/pcf857x.c instead.
-
- These devices are hard to detect and rarely found on mainstream
- hardware. If unsure, say N.
-
config SENSORS_TSL2550
tristate "Taos TSL2550 ambient light sensor"
depends on EXPERIMENTAL
diff --git a/drivers/i2c/chips/Makefile b/drivers/i2c/chips/Makefile
index 8cd778d..749cf36 100644
--- a/drivers/i2c/chips/Makefile
+++ b/drivers/i2c/chips/Makefile
@@ -11,7 +11,6 @@
#
obj-$(CONFIG_DS1682) += ds1682.o
-obj-$(CONFIG_SENSORS_PCF8574) += pcf8574.o
obj-$(CONFIG_SENSORS_TSL2550) += tsl2550.o
ifeq ($(CONFIG_I2C_DEBUG_CHIP),y)
diff --git a/drivers/i2c/chips/pcf8574.c b/drivers/i2c/chips/pcf8574.c
deleted file mode 100644
index 6ec3098..0000000
--- a/drivers/i2c/chips/pcf8574.c
+++ /dev/null
@@ -1,215 +0,0 @@
-/*
- Copyright (c) 2000 Frodo Looijaard <frodol@dds.nl>,
- Philip Edelbrock <phil@netroedge.com>,
- Dan Eaton <dan.eaton@rocketlogix.com>
- Ported to Linux 2.6 by Aurelien Jarno <aurel32@debian.org> with
- the help of Jean Delvare <khali@linux-fr.org>
-
- 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.
-*/
-
-/* A few notes about the PCF8574:
-
-* The PCF8574 is an 8-bit I/O expander for the I2C bus produced by
- Philips Semiconductors. It is designed to provide a byte I2C
- interface to up to 8 separate devices.
-
-* The PCF8574 appears as a very simple SMBus device which can be
- read from or written to with SMBUS byte read/write accesses.
-
- --Dan
-
-*/
-
-#include <linux/module.h>
-#include <linux/init.h>
-#include <linux/slab.h>
-#include <linux/i2c.h>
-
-/* Addresses to scan: none, device can't be detected */
-static const unsigned short normal_i2c[] = { I2C_CLIENT_END };
-
-/* Insmod parameters */
-I2C_CLIENT_INSMOD_2(pcf8574, pcf8574a);
-
-/* Each client has this additional data */
-struct pcf8574_data {
- int write; /* Remember last written value */
-};
-
-static void pcf8574_init_client(struct i2c_client *client);
-
-/* following are the sysfs callback functions */
-static ssize_t show_read(struct device *dev, struct device_attribute *attr, char *buf)
-{
- struct i2c_client *client = to_i2c_client(dev);
- return sprintf(buf, "%u\n", i2c_smbus_read_byte(client));
-}
-
-static DEVICE_ATTR(read, S_IRUGO, show_read, NULL);
-
-static ssize_t show_write(struct device *dev, struct device_attribute *attr, char *buf)
-{
- struct pcf8574_data *data = i2c_get_clientdata(to_i2c_client(dev));
-
- if (data->write < 0)
- return data->write;
-
- return sprintf(buf, "%d\n", data->write);
-}
-
-static ssize_t set_write(struct device *dev, struct device_attribute *attr, const char *buf,
- size_t count)
-{
- struct i2c_client *client = to_i2c_client(dev);
- struct pcf8574_data *data = i2c_get_clientdata(client);
- unsigned long val = simple_strtoul(buf, NULL, 10);
-
- if (val > 0xff)
- return -EINVAL;
-
- data->write = val;
- i2c_smbus_write_byte(client, data->write);
- return count;
-}
-
-static DEVICE_ATTR(write, S_IWUSR | S_IRUGO, show_write, set_write);
-
-static struct attribute *pcf8574_attributes[] = {
- &dev_attr_read.attr,
- &dev_attr_write.attr,
- NULL
-};
-
-static const struct attribute_group pcf8574_attr_group = {
- .attrs = pcf8574_attributes,
-};
-
-/*
- * Real code
- */
-
-/* Return 0 if detection is successful, -ENODEV otherwise */
-static int pcf8574_detect(struct i2c_client *client, int kind,
- struct i2c_board_info *info)
-{
- struct i2c_adapter *adapter = client->adapter;
- const char *client_name;
-
- if (!i2c_check_functionality(adapter, I2C_FUNC_SMBUS_BYTE))
- return -ENODEV;
-
- /* Now, we would do the remaining detection. But the PCF8574 is plainly
- impossible to detect! Stupid chip. */
-
- /* Determine the chip type */
- if (kind <= 0) {
- if (client->addr >= 0x38 && client->addr <= 0x3f)
- kind = pcf8574a;
- else
- kind = pcf8574;
- }
-
- if (kind == pcf8574a)
- client_name = "pcf8574a";
- else
- client_name = "pcf8574";
- strlcpy(info->type, client_name, I2C_NAME_SIZE);
-
- return 0;
-}
-
-static int pcf8574_probe(struct i2c_client *client,
- const struct i2c_device_id *id)
-{
- struct pcf8574_data *data;
- int err;
-
- data = kzalloc(sizeof(struct pcf8574_data), GFP_KERNEL);
- if (!data) {
- err = -ENOMEM;
- goto exit;
- }
-
- i2c_set_clientdata(client, data);
-
- /* Initialize the PCF8574 chip */
- pcf8574_init_client(client);
-
- /* Register sysfs hooks */
- err = sysfs_create_group(&client->dev.kobj, &pcf8574_attr_group);
- if (err)
- goto exit_free;
- return 0;
-
- exit_free:
- kfree(data);
- exit:
- return err;
-}
-
-static int pcf8574_remove(struct i2c_client *client)
-{
- sysfs_remove_group(&client->dev.kobj, &pcf8574_attr_group);
- kfree(i2c_get_clientdata(client));
- return 0;
-}
-
-/* Called when we have found a new PCF8574. */
-static void pcf8574_init_client(struct i2c_client *client)
-{
- struct pcf8574_data *data = i2c_get_clientdata(client);
- data->write = -EAGAIN;
-}
-
-static const struct i2c_device_id pcf8574_id[] = {
- { "pcf8574", 0 },
- { "pcf8574a", 0 },
- { }
-};
-
-static struct i2c_driver pcf8574_driver = {
- .driver = {
- .name = "pcf8574",
- },
- .probe = pcf8574_probe,
- .remove = pcf8574_remove,
- .id_table = pcf8574_id,
-
- .detect = pcf8574_detect,
- .address_data = &addr_data,
-};
-
-static int __init pcf8574_init(void)
-{
- return i2c_add_driver(&pcf8574_driver);
-}
-
-static void __exit pcf8574_exit(void)
-{
- i2c_del_driver(&pcf8574_driver);
-}
-
-
-MODULE_AUTHOR
- ("Frodo Looijaard <frodol@dds.nl>, "
- "Philip Edelbrock <phil@netroedge.com>, "
- "Dan Eaton <dan.eaton@rocketlogix.com> "
- "and Aurelien Jarno <aurelien@aurel32.net>");
-MODULE_DESCRIPTION("PCF8574 driver");
-MODULE_LICENSE("GPL");
-
-module_init(pcf8574_init);
-module_exit(pcf8574_exit);
--
1.6.3.3
^ permalink raw reply related
* Re: [PATCH 3/4] i2c/chips: Remove deprecated pca9539-driver
From: Ben Gardner @ 2009-09-09 23:28 UTC (permalink / raw)
To: Wolfram Sang
Cc: linux-mips, linuxppc-dev, linux-i2c, Jean Delvare,
uclinux-dist-devel, linux-arm-kernel
In-Reply-To: <1252531371-14866-4-git-send-email-w.sang@pengutronix.de>
On Wed, Sep 9, 2009 at 4:22 PM, Wolfram Sang<w.sang@pengutronix.de> wrote:
> The pca9539-driver in drivers/i2c/chips which just exports its registers to
> sysfs is superseeded by drivers/gpio/pca953x.c which properly uses the gpiolib.
> As this driver has been deprecated for more than a year, finally remove it.
>
> Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
> Cc: Ben Gardner <gardner.ben@gmail.com>
> Cc: Jean Delvare <khali@linux-fr.org>
Acked-by: Ben Gardner <gardner.ben@gmail.com>
Thanks for taking care of this.
Ben
^ permalink raw reply
* powerpc/ps3: Workaround for flash memory I/O error
From: Geoff Levand @ 2009-09-09 23:28 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, stable
A workaround for flash memory I/O errors when the PS3 internal
hard disk has not been formatted for OtherOS use.
This error condition mainly effects 'Live CD' users who have not
formatted the PS3's internal hard disk for OtherOS.
Fixes errors similar to these when using the ps3-flash-util
or ps3-boot-game-os programs:
ps3flash read failed 0x2050000
os_area_header_read: read error: os_area_header: Input/output error
main:627: os_area_read_hp error.
ERROR: can't change boot flag
Signed-off-by: Geoff Levand <geoffrey.levand@am.sony.com>
---
drivers/ps3/ps3stor_lib.c | 65 +++++++++++++++++++++++++++++++++++++++++++---
1 file changed, 62 insertions(+), 3 deletions(-)
--- a/drivers/ps3/ps3stor_lib.c
+++ b/drivers/ps3/ps3stor_lib.c
@@ -23,6 +23,65 @@
#include <asm/lv1call.h>
#include <asm/ps3stor.h>
+/*
+ * A workaround for flash memory I/O errors when the internal hard disk
+ * has not been formatted for OtherOS use. Delay disk close until flash
+ * memory is closed.
+ */
+
+static struct ps3_flash_workaround {
+ int flash_open;
+ int disk_open;
+ struct ps3_system_bus_device *disk_sbd;
+} ps3_flash_workaround;
+
+static int ps3stor_open_hv_device(struct ps3_system_bus_device *sbd)
+{
+ int error = ps3_open_hv_device(sbd);
+
+ if (error)
+ return error;
+
+ if (sbd->match_id == PS3_MATCH_ID_STOR_FLASH)
+ ps3_flash_workaround.flash_open = 1;
+
+ if (sbd->match_id == PS3_MATCH_ID_STOR_DISK)
+ ps3_flash_workaround.disk_open = 1;
+
+ return 0;
+}
+
+static int ps3stor_close_hv_device(struct ps3_system_bus_device *sbd)
+{
+ int error;
+
+ if (sbd->match_id == PS3_MATCH_ID_STOR_DISK
+ && ps3_flash_workaround.disk_open
+ && ps3_flash_workaround.flash_open) {
+ ps3_flash_workaround.disk_sbd = sbd;
+ return 0;
+ }
+
+ error = ps3_close_hv_device(sbd);
+
+ if (error)
+ return error;
+
+ if (sbd->match_id == PS3_MATCH_ID_STOR_DISK)
+ ps3_flash_workaround.disk_open = 0;
+
+ if (sbd->match_id == PS3_MATCH_ID_STOR_FLASH) {
+ ps3_flash_workaround.flash_open = 0;
+
+ if (ps3_flash_workaround.disk_sbd) {
+ ps3_close_hv_device(ps3_flash_workaround.disk_sbd);
+ ps3_flash_workaround.disk_open = 0;
+ ps3_flash_workaround.disk_sbd = NULL;
+ }
+ }
+
+ return 0;
+}
static int ps3stor_probe_access(struct ps3_storage_device *dev)
{
@@ -90,7 +149,7 @@ int ps3stor_setup(struct ps3_storage_dev
int error, res, alignment;
enum ps3_dma_page_size page_size;
- error = ps3_open_hv_device(&dev->sbd);
+ error = ps3stor_open_hv_device(&dev->sbd);
if (error) {
dev_err(&dev->sbd.core,
"%s:%u: ps3_open_hv_device failed %d\n", __func__,
@@ -166,7 +225,7 @@ fail_free_irq:
fail_sb_event_receive_port_destroy:
ps3_sb_event_receive_port_destroy(&dev->sbd, dev->irq);
fail_close_device:
- ps3_close_hv_device(&dev->sbd);
+ ps3stor_close_hv_device(&dev->sbd);
fail:
return error;
}
@@ -193,7 +252,7 @@ void ps3stor_teardown(struct ps3_storage
"%s:%u: destroy event receive port failed %d\n",
__func__, __LINE__, error);
- error = ps3_close_hv_device(&dev->sbd);
+ error = ps3stor_close_hv_device(&dev->sbd);
if (error)
dev_err(&dev->sbd.core,
"%s:%u: ps3_close_hv_device failed %d\n", __func__,
^ permalink raw reply
* Re: [Uclinux-dist-devel] Removing deprecated drivers from drivers/i2c/chips
From: Mike Frysinger @ 2009-09-09 23:54 UTC (permalink / raw)
To: Wolfram Sang
Cc: linuxppc-dev, linux-mips, linux-i2c, linux-arm-kernel,
uclinux-dist-devel
In-Reply-To: <1252531371-14866-1-git-send-email-w.sang@pengutronix.de>
On Wed, Sep 9, 2009 at 17:22, Wolfram Sang wrote:
> continuing the quest to clean up and ultimately remove the drivers/i2c/chips
> directory, this patch series removes three drivers for GPIO-expanders which are
> obsoleted and marked as deprecated for more than a year. The newer (and better)
> drivers can be found in drivers/gpio.
>
> As it is ensured that the newer drivers cover the same i2c_device_ids, all
> platform_devices will still match. Some defconfig updates may be necessary
> though, but according to [1] this is left to the arch|platform-maintainers
> (also as most defconfigs are quite outdated). For that reason, I put the
> relevant arch-mailing-lists to Cc. Comments are welcome.
the Blackfin defconfigs refer to an input driver for the PCF8574, not
the I2C client driver
-mike
^ permalink raw reply
* RE: Queries regarding I2C and GPIO driver for Freescale MPC5121e in Linux2.6.24 of BSP: MPC512xADS_20090603-ltib.iso
From: Chen Hongjun-R66092 @ 2009-09-10 0:57 UTC (permalink / raw)
To: Uma Kanta Patro, linuxppc-dev
In-Reply-To: <!&!AAAAAAAAAAAYAAAAAAAAACk7Zq0ADiBFlLw+tPrMt1bCgAAAEAAAAFtTs5+/RRJLtaFyAuWiLDoBAAAAAA==@implantaire.com>
[-- Attachment #1: Type: text/plain, Size: 5424 bytes --]
>From the following error message, I2C controller can't receive ACK from
I2C client, so please make sure that the pins of I2C have been
initialized properly, or you can measure the tx signal and rx signal on
the right pins.
B.R,
Hongjun
________________________________
From: Uma Kanta Patro [mailto:upatro@implantaire.com]
Sent: Wednesday, September 09, 2009 9:13 PM
To: Chen Hongjun-R66092; linuxppc-dev@lists.ozlabs.org
Subject: RE: Queries regarding I2C and GPIO driver for Freescale
MPC5121e in Linux2.6.24 of BSP: MPC512xADS_20090603-ltib.iso
Hi Chen Hongjun-R66092,
Thanks for your response.
Actually for the GPIO driver I am having some success and it is
in progress.
But regarding the I2C chip(client) driver I am running witout
any progress.
Actually I followed the existing driver
$(LINUX)\drivers\rtc\rtc-m41t80.c (for the RTC M41T62 existing on the
ADS5121Rev4.1 board).
I made a legacy style driver with attach_adapter and
detach_client functions defined.
For testing purpose I geve the chip address as 0x68(address of
M41T62 existing on the board). But when I tried ot insert my driver I
get the error message as:
[root@freescale chips]# insmod dis_fpc.ko
[ 177.808848] i2c 0-0068: uevent
[ 498.528032] In dis_fpc_init
[ 498.531851] i2c-core: driver [dis_fpc] registered
[ 498.532446] In dis_fpc_attach_adapter
[ 498.536827] i2c-adapter i2c-0: found normal entry for adapter
0, addr 0x55
[ 498.537730] i2c-adapter i2c-0: master_xfer[0] W, addr=0x55,
len=0
[ 498.538533] Doing write 0 bytes to 0x55 - 1 of 1 messages
[ 498.539770] I2C: No RXAK
[ 498.540970] In dis_fpc_attach_adapter
[ 498.554500] i2c-adapter i2c-1: found normal entry for adapter
1, addr 0x55
[ 498.555166] i2c-adapter i2c-1: master_xfer[0] W, addr=0x55,
len=0
[ 498.555872] Doing write 0 bytes to 0x55 - 1 of 1 messages
[ 498.556785] I2C: MAL
[ 498.557476] In dis_fpc_attach_adapter
[ 498.565733] i2c-adapter i2c-2: found normal entry for adapter
2, addr 0x55
[ 498.566377] i2c-adapter i2c-2: master_xfer[0] W, addr=0x55,
len=0
[ 498.567082] Doing write 0 bytes to 0x55 - 1 of 1 messages
[ 498.568240] I2C: No RXAK
So can you tell me what other places do I need to change the
configurations( like i2c_platform_data definition, linking the chip to
the specific I2C module(0/1/2) with the adapter, configuring the speed
of I2C communication etc).
I would like to get any suggestion on making the I2C chip driver
inpowerpc platform.
Thanks & Regards,
Uma
From: Chen Hongjun-R66092 [mailto:hong-jun.chen@freescale.com]
Sent: Wednesday, September 09, 2009 5:39 AM
To: Uma Kanta Patro; linuxppc-dev@lists.ozlabs.org
Subject: RE: Queries regarding I2C and GPIO driver for Freescale
MPC5121e in Linux2.6.24 of BSP: MPC512xADS_20090603-ltib.iso
One I2C driver has been included in 0603 bsp, you can refer to
it.
It has no specific driver for GPIO, but you can find some
initializing code for GPIO in arch/powerpc/platforms/512x/mpc5125_ads.c.
and mpc512x_pm_test.c.
________________________________
From:
linuxppc-dev-bounces+hong-jun.chen=freescale.com@lists.ozlabs.org
[mailto:linuxppc-dev-bounces+hong-jun.chen=freescale.com@lists.ozlabs.or
g] On Behalf Of Uma Kanta Patro
Sent: Tuesday, September 08, 2009 6:56 PM
To: linuxppc-dev@lists.ozlabs.org
Subject: Queries regarding I2C and GPIO driver for
Freescale MPC5121e in Linux2.6.24 of BSP: MPC512xADS_20090603-ltib.iso
Hi all,
I am a newbie to the powerpc linux
kernel, but I have worked on some drivers in arm architecture. I am
finding powerpc architecture to be fully different than that.
I am working on Freescale MPC5121e with the BSP
MPC512xADS_20090603-ltib.iso running in it on the ADS512101 Rev4.1
development kit.
Can anyone help me in finding some documentation for
understanding and working on the powerpc kernel. Any links to the
powerpc forums will also be appreciable.
-> Currently I am going to develop an I2C client driver
for one slave microcontroller of our project.
I have some knowledge in the I2C client driver
making(legacy style and new style).
I made a basic I2C client driver to probe for the chip
address and for testing I gave it the chip address 0x68(I2C chip address
of the M4T162 RTC, present on the board).
But while inserting my driver I am getting failure
message for the detection of my chip.
So I would like to know what other formalities am I
lagging in my I2C chip driver.
-> Also I am in a need for the GPIO driver for my
controller ot get interrupt on ht estate change. When I searched in the
kernel code I could not find any procedure to do that, also I could not
find out the procedure to access either any GPIO pin macros or any
register to remap with ioremap(). So please guide me in finding the
proper way to do the GPIO accessing and interrupt registration.
Will the ioremap() work on powerpc arch? If yes where
can I find the memory mapping(register definitions) to use for my GPIO
driver making.
Thanks for patience in reading my queries.
Any help is appreciable.
Thanks & Regards,
Uma
[-- Attachment #2: Type: text/html, Size: 14782 bytes --]
^ permalink raw reply
* [PATCH 1/3] phy/marvell: Make non-aneg speed/duplex forcing work for 88E1111 PHYs
From: Anton Vorontsov @ 2009-09-10 2:01 UTC (permalink / raw)
To: David Miller; +Cc: netdev, linuxppc-dev, Andy Fleming, Timur Tabi
According to specs, when auto-negotiation is disabled, Marvell PHYs need
a software reset after changing speed/duplex forcing bits. Otherwise,
the modified bits have no effect.
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
drivers/net/phy/marvell.c | 21 ++++++++++++++++++++-
1 files changed, 20 insertions(+), 1 deletions(-)
diff --git a/drivers/net/phy/marvell.c b/drivers/net/phy/marvell.c
index dd6f54d..6f69b9b 100644
--- a/drivers/net/phy/marvell.c
+++ b/drivers/net/phy/marvell.c
@@ -155,8 +155,27 @@ static int marvell_config_aneg(struct phy_device *phydev)
return err;
err = genphy_config_aneg(phydev);
+ if (err < 0)
+ return err;
- return err;
+ if (phydev->autoneg != AUTONEG_ENABLE) {
+ int bmcr;
+
+ /*
+ * A write to speed/duplex bits (that is performed by
+ * genphy_config_aneg() call above) must be followed by
+ * a software reset. Otherwise, the write has no effect.
+ */
+ bmcr = phy_read(phydev, MII_BMCR);
+ if (bmcr < 0)
+ return bmcr;
+
+ err = phy_write(phydev, MII_BMCR, bmcr | BMCR_RESET);
+ if (err < 0)
+ return err;
+ }
+
+ return 0;
}
static int m88e1121_config_aneg(struct phy_device *phydev)
--
1.6.3.3
^ permalink raw reply related
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