Hi Arjan,
The issue is not on the hardware side, as I disabled all the SPI devices and
tested my device over all SPI0 slave from 0 to 3, but the issue
remains. (the slave select 2 is the one on which max3111 spi to serial
converter is connected, and it works fine... we have probed and found its
okay).
The slave device works and has been tested on a embedded platform.So, no
problem indication there also.
I have also added controller_data something like that is used by max3111.
static struct dw_spi_chip my_slave_device = {
.poll_mode = 1,
.enable_dma = 0,
.type = SPI_FRF_SPI,
};
static void *mrfj_platform_data(void *info)
{
static int dummy;
struct spi_board_info *spi_info = (struct spi_board_info *)info;
spi_info->irq = 0;
spi_info->mode = SPI_MODE_0;
spi_info->controller_data = &my_slave_device;
/* we return a dummy pdata */
return &dummy;
}
But this too didn't help.
I doubt if this has anything to do with Hardware and thats why this mail to
the kernel list.
I have run out of options and any guidance /pointers would really help.
i m not doing any spi_set_drvdata in probe function and doubt if this is
really required. otherwise my protocol driver implementation is similar to
mrst_max3111.c
the only other difference is max3111 is reported by SFI and my device is
not, for which i modified the mrst.c spi device parser function to register
my slave device instead of spi_opt_modem which is not connected on the MRST
CDK board i received
Any... any pointers?
Regards,
Tom
On Sat, Feb 12, 2011 at 10:46 PM, Arjan van de Ven <[email protected]>wrote:
> On 2/12/2011 4:38 AM, Tom wrote:
>
>> The issue is that for the spi_w8r8 call, i get multiple read (multiple
>> * (8 clock cycles/SS toggle))on the SPI bus.
>>
>> Also regarding the spi->irq, is it the responsibility of the protocol
>> driver to register for this irq and handle it or does the spi framework or
>> master driver take care of this ?
>>
>> Any pointers would be really helpful. ( attached is the test code )
>>
>
> Hi,
>
> I suspect that your question isn't really in the real of MeeGo any more,
> but in the realm of hardware support.....
> you'll be better off asking your Intel rep this question so that they can
> get the Intel folks that are supporting your design on the hook
> to do a detailed investigation (with a logic analyzer etc etc etc).
>
> Greetings,
> Arjan van de Ven
>
_______________________________________________
MeeGo-kernel mailing list
[email protected]
http://lists.meego.com/listinfo/meego-kernel
