Re: [PATCH] mmc: omap_hsmmc: Add support for Erratum 2.1.1.128 in device tree boot

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed 05 Feb 2014 08:10:34 AM CST, Balaji T K wrote:
> On Tuesday 04 February 2014 08:48 PM, Nishanth Menon wrote:
>> On 02/04/2014 06:44 AM, Balaji T K wrote:
>>> On Tuesday 21 January 2014 04:59 AM, Nishanth Menon wrote:
>>>> When device is booted using devicetree, platforms impacted by
>>>> Erratum 2.1.1.128 is not detected easily in the mmc driver. This erratum
>>>> indicates that the module cannot do multi-block transfers.
>>>>
>>>> Handle this by providing a boolean flag to indicate to driver that it is
>>>> working on a hardware with mentioned limitation.
>>>>
>>>> Signed-off-by: Nishanth Menon <nm@xxxxxx>
>>>> ---
>>>>
>>>> This explains the logs I see:
>>>> OMAP3430 LDP (ES2.2):
>>>> 	uImage only boot:  http://slexy.org/raw/s2YrbMAi7c
>>>> 	uImage+dtb concatenated boot: http://slexy.org/raw/s20qVg17T0
>>>>
>>>> With the following flag set, device is now able to consistently boot with
>>>> device tree supported uImage+dtb concat boot.
>>>>
>>>>    .../devicetree/bindings/mmc/ti-omap-hsmmc.txt      |    2 ++
>>>>    drivers/mmc/host/omap_hsmmc.c                      |    3 +++
>>>>    2 files changed, 5 insertions(+)
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
>>>> index 8c8908a..ab36f8b 100644
>>>> --- a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
>>>> +++ b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
>>>> @@ -26,6 +26,8 @@ specifier is required.
>>>>    dma-names: List of DMA request names. These strings correspond
>>>>    1:1 with the DMA specifiers listed in dmas. The string naming is
>>>>    to be "rx" and "tx" for RX and TX DMA requests, respectively.
>>>> +ti,erratum-2.1.1.128: boolean, for OMAP3430/OMAP35xx platforms with broken
>>>> +multiblock reads
>>>
>>> Rather than ti,errata.. specific property, something like
>>> caps no/disable multiblock read is more readable in my opinion, Otherwise
>>
>> Is'nt the better definition to state i have quirk X and allow the
>> driver to do the necessary thing/things needed to handle quirk X? in
>> this case, there is just one thing to do: broken multi_block_read, in
>> the case of other quirks, there might be more than 1 thing to do.. let
>> driver figure that out, dts just states the h/w capabilty or in this
>> case, the quirk capability.
>>
>
> But in this case there is only one. disable multi block read is more readable
> than the errata reference, No strong feelings though.

Considering this might set an precedence for other quirk description, 
I'd like to leave it as it stands.

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




[Index of Archives]     [Linux Arm (vger)]     [ARM Kernel]     [ARM MSM]     [Linux Tegra]     [Linux WPAN Networking]     [Linux Wireless Networking]     [Maemo Users]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux