Re: [PATCH] mtd: denali: fix property name for Denali DT binding

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

 




Hi Rob,


2016-02-09 6:37 GMT+09:00 Rob Herring <robh@xxxxxxxxxx>:
> On Mon, Feb 08, 2016 at 05:41:33PM +0900, Masahiro Yamada wrote:
>> Hi Arnd,
>>
>>
>> 2016-02-08 17:29 GMT+09:00 Arnd Bergmann <arnd@xxxxxxxx>:
>> > On Monday 08 February 2016 16:31:42 Masahiro Yamada wrote:
>> >> diff --git a/Documentation/devicetree/bindings/mtd/denali-nand.txt b/Documentation/devicetree/bindings/mtd/denali-nand.txt
>> >> index b04d03a..785b825 100644
>> >> --- a/Documentation/devicetree/bindings/mtd/denali-nand.txt
>> >> +++ b/Documentation/devicetree/bindings/mtd/denali-nand.txt
>> >> @@ -5,7 +5,7 @@ Required properties:
>> >>    - reg : should contain registers location and length for data and reg.
>> >>    - reg-names: Should contain the reg names "nand_data" and "denali_reg"
>> >>    - interrupts : The interrupt number.
>> >> -  - dm-mask : DMA bit mask
>> >> +  - dma-mask : DMA bit mask
>> >>
>> >>  The device tree may optionally contain sub-nodes describing partitions of the
>> >>  address space. See partition.txt for more detail.
>> >>
>> >
>> > It looks like this binding is wrong in multiple ways, and it doesn't seem to
>> > be used in any .dts files. Is this actually being shipped anywhere or
>> > could we try to fix the binding properly?
>> >
>>
>> Looks like it is locally used in Altera's Rocketboard tree now.
>>
>> See this:
>>
>> https://github.com/altera-opensource/linux-socfpga/blob/socfpga-4.3/arch/arm/boot/dts/socfpga.dtsi
>>
>>
>> I hope Dinh can comment on the status.
>
> From the looks of it, this property should be dropped and the driver
> should be updated to not touch dev->dma_mask. The core sets it up
> correctly now.


I am still a newbie as for DMA.
Could you help me to understand what we should do and/or what we should not do
for the DMA mask.


Documentation/DMA-API-HOWTO.txt says as follows:

-------------------->8-----------------------
For correct operation, you must interrogate the kernel in your device
probe routine to see if the DMA controller on the machine can properly
support the DMA addressing limitation your device has.  It is good
style to do this even if your device holds the default setting,
because this shows that you did think about these issues wrt. your
device.
--------------------<8----------------------


>From your statement, low-level drivers should no longer touch dma-mask
(i.e., the quoted paragraph above no longer applies to the latest
driver implementation),
is this correct?



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



[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]
  Powered by Linux