Re: [PATCH 3/3] ARM: OMAP2+: Add GPMC DT support for Ethernet child nodes

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

 



On Thu, Mar 14, 2013 at 5:37 PM, Javier Martinez Canillas
<martinez.javier@xxxxxxxxx> wrote:
> On Thu, Mar 14, 2013 at 4:48 PM, Jon Hunter <jon-hunter@xxxxxx> wrote:
>> Hi Javier,
>>
>> On 03/14/2013 10:09 AM, Javier Martinez Canillas wrote:
>>> Besides being used to interface with external memory devices,
>>> the General-Purpose Memory Controller can be used to connect
>>> Pseudo-SRAM devices such as ethernet controllers to OMAP2+
>>> processors using the TI GPMC as a data bus.
>>>
>>> This patch allows an ethernet chip to be defined as an GPMC
>>> child device node.
>>>
>>> Signed-off-by: Javier Martinez Canillas <javier.martinez@xxxxxxxxxxxxxxx>
>>> ---
>>>  Documentation/devicetree/bindings/net/gpmc-eth.txt |   90 ++++++++++++++++++++
>>>  arch/arm/mach-omap2/gpmc.c                         |    8 ++
>>>  2 files changed, 98 insertions(+), 0 deletions(-)
>>>  create mode 100644 Documentation/devicetree/bindings/net/gpmc-eth.txt
>>>
>>> diff --git a/Documentation/devicetree/bindings/net/gpmc-eth.txt b/Documentation/devicetree/bindings/net/gpmc-eth.txt
>>> new file mode 100644
>>> index 0000000..c45363c
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/net/gpmc-eth.txt
>>> @@ -0,0 +1,90 @@
>>> +Device tree bindings for Ethernet chip connected to TI GPMC
>>> +
>>> +Besides being used to interface with external memory devices, the
>>> +General-Purpose Memory Controller can be used to connect Pseudo-SRAM devices
>>> +such as ethernet controllers to processors using the TI GPMC as a data bus.
>>> +
>>> +Ethernet controllers connected to TI GPMC are represented as child nodes of
>>> +the GPMC controller with an "ethernet" name.
>>> +
>>> +All timing relevant properties as well as generic GPMC child properties are
>>> +explained in a separate documents. Please refer to
>>> +Documentation/devicetree/bindings/bus/ti-gpmc.txt
>>> +
>>> +Required properties:
>>> +- bank-width:                Address width of the device in bytes. GPMC supports 8-bit
>>> +                     and 16-bit devices and so must be either 1 or 2 bytes.
>>
>> I am wondering if we should use reg-io-width here. The smsc driver is
>> using this to determine the width of the device. And so I am wondering
>> if this could cause problems.
>>
>> Obviously this complicates gpmc_probe_generic_child() a little, but may
>> be would could pass the name of the width property to
>> gpmc_probe_generic_child() as well. What do you think?
>>
>
> Hi Jon,
>
> Well now I'm confused. I thought that both were needed since a
> combination of bank-width 16-bit / reg-io-width 32-bit is also
> possible (in fact that is how I'm testing on my IGEPv2) and we have
> talked about this before [1].
>
> By reading both the OMAP3 TRM and the smsc LAN9221 data-sheet, it
> seems that the reg-io-width is not about the data bus address width
> but the CPU address width. The smsc data-sheet says:
>

Hi Jon,

By the way, here is the smsc LAN9221 data-sheet if you don't have it
and want to take it a look:

http://www.smsc.com/Downloads/SMSC/Downloads_Public/Data_Sheets/9221.pdf

Thanks a lot and best regards,
Javier
--
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