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

[Marek Vasut <marex@xxxxxxx>]

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 ?

-- 
Best regards,
Marek Vasut
--
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