Re: [PATCH 2/2] mtd: m25p80: consider max_transfer_size when reading

[Heiner Kallweit <hkallweit1@xxxxxxxxx>]

Am 07.06.2016 um 00:28 schrieb Marek Vasut:
> On 06/06/2016 11:20 PM, Heiner Kallweit wrote:
>> Am 06.06.2016 um 21:46 schrieb Geert Uytterhoeven:
>>> Hi Heiner,
>>>
>>> On Mon, Jun 6, 2016 at 8:53 PM, Heiner Kallweit <hkallweit1@xxxxxxxxx> wrote:
>>>> Am 06.06.2016 um 19:40 schrieb Mark Brown:
>>>>> On Sat, Jun 04, 2016 at 12:22:37AM +0200, Heiner Kallweit wrote:
>>>>>> Am 06.05.2016 um 14:14 schrieb Mark Brown:
>>>>>>> Yes, it's called the maximum transfer size because it is the
>>>>>>> maximum size of a transfer, not because it's the maximum size of
>>>>>>> a message.
>>>>>
>>>>>> I'd like to come back to this discussion. You said best would be
>>>>>> to fix the chip driver. To do this and calculate an appropriate
>>>>>> value for max_transfer_size the chip driver would have to know that
>>>>>> the spi_device is a spi-nor device.
>>>>>
>>>>> That doesn't make any sense, the controller hardware doesn't
>>>>> magically change based on what is connected to it.
>>>>>
>>>> The issue with fsl-espi is that the controller deactivates CS after
>>>> each physical transfer. And a lot of HW designs use the hardware CS,
>>>> therefore the advise to use a GPIO instead doesn't really help.
>>>
>>> And you can't use pinmux to configure the pin used for hardware CS
>>> to become a GPIO?
>>>
>> Sadly enough, no. Only the complete block of SPI signals can be switched
>> to GPIO mode. But then we'd have to use bitbanging and would loose all
>> features of the integrated SPI controller (FIFO's etc.)
> 
> Just for completeness, which SoC are we talking about here ?
> 
Freescale (now NXP) P1014

--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html