On Aug 23, 2011, at 3:49 AM, Jiri Slaby wrote:
> On 08/23/2011 09:59 AM, Jiri Slaby wrote:
>> When spi_fsl_espi is chosen to be built as a module, there is a build
>> error because we test only CONFIG_SPI_FSL_ESPI in declaration of
>> struct mpc8xxx_spi in drivers/spi/spi_fsl_lib.h.
>>
>> We nee
On Oct 17, 2010, at 2:44 AM, Artem Bityutskiy wrote:
> On Sat, 2010-10-16 at 19:05 -0600, Grant Likely wrote:
>> On Sat, Oct 16, 2010 at 1:17 PM, Artem Bityutskiy
>> wrote:
>>> On Tue, 2010-10-12 at 18:18 +0800, Mingkai Hu wrote:
Signed-off-by: Mingkai Hu
Acked-by: Grant Likely
On Oct 14, 2010, at 9:12 AM, Grant Likely wrote:
> On Thu, Oct 14, 2010 at 08:55:47AM -0500, Kumar Gala wrote:
>> We get the following when building on ppc64 due to lack of include of
>> :
>
> Is this an immediate problem (merge for .36), or is it a linux-next thing?
>
function
'iounmap'
drivers/spi/spi_fsl_espi.c: In function 'fsl_espi_probe':
drivers/spi/spi_fsl_espi.c:602:2: error: implicit declaration of function
'ioremap'
drivers/spi/spi_fsl_espi.c:602:24: warning: assignment makes pointer from
integer without a cast
Signed-
On Oct 7, 2010, at 9:15 PM, Hu Mingkai-B21284 wrote:
Yes, I agree with David on this. If large transfers don't work,
then it is the SPI master driver that is buggy.
>>>
>>> By the way, does this fix your problem?
>>>
>>> https://patchwork.kernel.org/patch/184752/
>>
>> It shouldn't.
> function
>
> Signed-off-by: Anton Vorontsov
> ---
> drivers/spi/spi_mpc8xxx.c |1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
Acked-by: Kumar Gala
- k
--
Let Crystal Reports handle th
On Aug 18, 2009, at 5:04 PM, Anton Vorontsov wrote:
> When cpm2.h included into spi_mpc8xxx driver, the SPI defines
> in the header conflict with defines in the driver.
>
> We don't need them in the header file, so remove them. Plus
> remove "struct spi", we'll use a better version in the driver.
On Aug 18, 2009, at 5:04 PM, Anton Vorontsov wrote:
> This is needed to avoid ugly #ifdefs in drivers. Also update
> fsl_qe_udc
> driver so that now it doesn't define its own versions that cause build
> breakage when the generic stubs are used.
>
> Signed-off-by: Anton Vorontsov
> ---
> arch/p
On Aug 18, 2009, at 5:04 PM, Anton Vorontsov wrote:
> struct mcc defined in both immap_qe.h and immap_cpm2.h, so they will
> conflic when included in a single file. The mcc struct is easy to deal
> with, since it isn't used in any driver (yet), so let's just rename QE
> version to qe_mcc.
>
> The
On Aug 18, 2009, at 5:04 PM, Anton Vorontsov wrote:
> The bits are generic to CPM devices, so let's move them to the
> common header file, so drivers won't need to privately reintroduce
> another bunch of the same bits (as we can't include cpm2.h header
> together with cpm1.h).
>
> Signed-off-by:
On Jun 19, 2009, at 2:26 AM, Rini van Zetten wrote:
> This patch adds the possibility to have a spi device without a cs.
>
> For example, the dts file should look something like this:
>
> spi-controller {
> gpios = <&pio1 1 0 /* cs0 */
>0 /* cs1, no GPIO */
On Jun 18, 2009, at 8:09 AM, Anton Vorontsov wrote:
> On Thu, Jun 18, 2009 at 08:19:44AM +0200, Rini van Zetten wrote:
>> This patch adds the possibility to have a spi device without a cs.
>>
>> For example, the dts file should look something like this:
>>
>> spi-controller {
>> gpios = <&p
On Jun 18, 2009, at 1:19 AM, Rini van Zetten wrote:
> This patch adds the possibility to have a spi device without a cs.
>
> For example, the dts file should look something like this:
>
> spi-controller {
> gpios = <&pio1 1 0 /* cs0 */
>0 /* cs1, no GPIO */
On Jun 11, 2009, at 4:10 AM, Rini van Zetten wrote:
> This patch adds the possibility to have a spi device without a cs.
>
> For example, the dts file should look something like this:
>
> spi-controller {
> gpios = <&pio1 1 0 /* cs0 */
>0 /* cs1, no GPIO */
On Jan 23, 2009, at 1:49 PM, Anton Vorontsov wrote:
> On Tue, Jan 06, 2009 at 10:28:10PM -0600, Kumar Gala wrote:
>> On Dec 5, 2008, at 2:09 PM, Anton Vorontsov wrote:
>>> Hi all,
>>>
>>> The patch series are used to support SPI via the OF SPI subsystem
>
On Dec 5, 2008, at 2:09 PM, Anton Vorontsov wrote:
> Hi all,
>
> The patch series are used to support SPI via the OF SPI subsystem
> (driver/of/of_spi.c). Now the driver is able to manage its own
> chip selects, and doesn't need any auxiliary support from the
> board files or fsl_soc constructors
On Dec 5, 2008, at 2:10 PM, Anton Vorontsov wrote:
> This is needed to not bother with ugly #ifdefs in the drivers.
>
> Signed-off-by: Anton Vorontsov
> ---
> arch/powerpc/sysdev/fsl_soc.h |5 +
> 1 files changed, 5 insertions(+), 0 deletions(-)
applied to next
- k
On Aug 20, 2008, at 11:46 PM, Kumar Gala wrote:
> Now that arch/ppc is gone we don't need CONFIG_PPC_MERGE anymore
> remove the dead code associated with !CONFIG_PPC_MERGE.
>
> Signed-off-by: Kumar Gala <[EMAIL PROTECTED]>
> ---
> drivers
On Apr 23, 2008, at 3:19 PM, Roel Kluin wrote:
> mpc83xx_spi->irq is unsigned, so the test fails
>
> Signed-off-by: Roel Kluin <[EMAIL PROTECTED]>
you should copy the linux-spi list on such patches.
- k
>
> ---
> diff --git a/drivers/spi/spi_mpc83xx.c b/drivers/spi/spi_mpc83xx.c
> index be15a62
Was wondering if anyone was looking at the cause of this warning in
top of linus's tree (8af03e782cae1e0a0f530ddd22301cdd12cf9dc0)
drivers/spi/Kconfig:156:warning: 'select' used by config symbol
'SPI_PXA2XX' refers to undefined symbol 'PXA_SSP'
I was doing a build of a ppc kernel.
- k
-
On Sep 25, 2007, at 11:58 AM, David Brownell wrote:
- depends on SPI_MASTER && PPC_83xx && EXPERIMENTAL
+ depends on SPI_MASTER && (PPC_83xx || PPC_85xx) && EXPERIMENTAL
>>>
>>> Should that really be just PPC_83xx || QUICC_ENGINE?
>>
>> Well, I thought about that. By now I'm unsure if
On Sep 25, 2007, at 9:35 AM, Anton Vorontsov wrote:
> MPC85xx's QE SPI controller is almost the same comparing to MPC83xx.
> Thus lets use that driver. Tested to work in loopback mode.
>
> Signed-off-by: Anton Vorontsov <[EMAIL PROTECTED]>
> ---
> drivers/spi/Kconfig |2 +-
> 1 files changed
On Aug 2, 2007, at 4:47 PM, David Brownell wrote:
> On Thursday 02 August 2007, Anton Vorontsov wrote:
>> Probably someday mpc83xx_spi->sysclk should be renamed to
>> mpc83xx_spi->spiclk to be less confusing.
>
> Why not "today", with this patch? That would fix some of
> the root cause of this b
On Aug 2, 2007, at 9:26 AM, Anton Vorontsov wrote:
> For MPC8349E input to SPIBRG is SYSCLK, but it's SYSCLK/2 for
> MPC8323E (running in so-called "QE mode").
QE mode or the SPI in QE running in CPU mode?
- k
>
> This fixes clocking issues I've noticed recently.
>
> Probably someday mpc83xx_s
merge these patches? They look OK
> to me, but in this case that doesn't mean much. :)
>
> If I don't hear otherwise, I'll forward all four of these
> patches upstream on Monday.
>
> (Anton, thanks for these updates!)
These all look go
On Jul 26, 2007, at 8:13 AM, Anton Vorontsov wrote:
> Documentation clearly states, that mode should not be changed
> till SPMODE_ENABLE bit set. I've seen hangs w/o this patch.
Out of interest what board/part do you see the hang on?
- k
---
26 matches
Mail list logo
