On Fri 08 Apr 16:01 PDT 2016, Timur Tabi wrote:
> Bjorn Andersson wrote:
>
> >It sounds like you're trying to say that the pins used can be are
> >muxed as GPIO or MDIO, in the TLMM.
>
> I'm not 100% sure, but I think that's correct. If you don't want to have
> normal networking, you could conn
Bjorn Andersson wrote:
It sounds like you're trying to say that the pins used can be are
muxed as GPIO or MDIO, in the TLMM.
I'm not 100% sure, but I think that's correct. If you don't want to
have normal networking, you could connect those external pins to some
GPIO device (like an LED or
On Fri, Apr 8, 2016 at 12:06 PM, Timur Tabi wrote:
> Andrew Lunn wrote:
>
>> There are two different things here. One is configuring the pin to be
>> a GPIO. The second is using the GPIO as a GPIO. In this case,
>> bit-banging the MDIO bus.
>>
>> The firmware could be doing the configuration, sett
Vikram Sethi wrote:
On the FSM9900 SOC (which uses device-tree), the two pins that connect to the external
PHY are gpio pins. However, the driver needs to reprogram the pinmux so that those pins
are wired to the Emac controller. That's what the the gpio code in this driver is doing:
it's ju
On 04/08/2016 02:06 PM, Timur Tabi wrote:
> Andrew Lunn wrote:
>
>> There are two different things here. One is configuring the pin to be
>> a GPIO. The second is using the GPIO as a GPIO. In this case,
>> bit-banging the MDIO bus.
>>
>> The firmware could be doing the configuration, setting the pi
Andrew Lunn wrote:
There are two different things here. One is configuring the pin to be
a GPIO. The second is using the GPIO as a GPIO. In this case,
bit-banging the MDIO bus.
The firmware could be doing the configuration, setting the pin as a
GPIO. However, the firmware cannot be doing the MD
On Thu, Apr 07, 2016 at 04:43:47PM -0500, Timur Tabi wrote:
> On my platform, firmware (UEFI) configures all of the GPIOs. I need
> to get confirmation, but it appears that we don't actually make any
> GPIO calls at all. I see code that looks like this:
>
> for (i = 0; (!adpt->no_mdio_gpio
Andrew Lunn wrote:
I'm back to working on this driver, and I need some more help with
how to handle the phy. mdio-gpio.txt doesn't really tell me much.
I'm actually working on an ACPI system and not DT.
I can help you with DT, but not ACPI.
The MDIO bus can be a separate Linux device. Since y
> I'm back to working on this driver, and I need some more help with
> how to handle the phy. mdio-gpio.txt doesn't really tell me much.
> I'm actually working on an ACPI system and not DT.
I can help you with DT, but not ACPI.
The MDIO bus can be a separate Linux device. Since you have GPIO lin
Rob Herring wrote:
>>>+- reg : Offset and length of the register regions for the device
>>>+- reg-names : Register region names referenced in 'reg' above.
>>>+ Required register resource entries are:
>>>+ "base" : EMAC controller base register block.
>>>+ "csr": EMAC wrap
On Fri, Jan 29, 2016 at 2:38 PM, Timur Tabi wrote:
> Rob Herring wrote:
[...]
Isn't this a user enabled feature if the h/w supports it?
>>>
>>>
>>>
>>> Is there a sysfs entry for that? We were planning on having a similar
>>> ACPI
>>> property.
>>
>>
>> It would be in ethtool I think.
>
>
Rob Herring wrote:
The emac is present on a lot of Qualcomm SOCs, and there are only a few
variations of it. It's not really SOC-specific, and the hardware version
can be queried by the driver.
Can the integration bugs be queried, too?
Come on, you know how compatible strings work.
Fine. I
On Fri, Jan 29, 2016 at 12:22 PM, Timur Tabi wrote:
> Gilad is no longer working for Qualcomm, so I'm taking over (as best as I
> can) this driver. Let's just say it's going to be a learning experience.
Lucky you.
> Rob Herring wrote:
>>>
>>> diff --git a/Documentation/devicetree/bindings/net/q
Gilad is no longer working for Qualcomm, so I'm taking over (as best as
I can) this driver. Let's just say it's going to be a learning experience.
Rob Herring wrote:
diff --git a/Documentation/devicetree/bindings/net/qcom-emac.txt
b/Documentation/devicetree/bindings/net/qcom-emac.txt
new file
Gilad Avidov wrote:
diff --git a/drivers/net/ethernet/qualcomm/emac/emac-mac.c
b/drivers/net/ethernet/qualcomm/emac/emac-mac.c
new file mode 100644
index 000..36a7746
--- /dev/null
+++ b/drivers/net/ethernet/qualcomm/emac/emac-mac.c
@@ -0,0 +1,1808 @@
+/* Copyright (c) 2013-2015, The Linux
On Tue, Dec 29, 2015 at 06:48:55PM -0700, Gilad Avidov wrote:
> Add supports for ethernet controller HW on Qualcomm Technologies, Inc. SoC.
> This driver supports the following features:
> 1) Checksum offload.
> 2) Runtime power management support.
> 3) Interrupt coalescing support.
> 4) SGMII phy.
Hi Gilad,
[auto build test WARNING on net/master]
[also build test WARNING on v4.4-rc7 next-20151223]
[if your patch is applied to the wrong git tree, please drop us a note to help
improving the system]
url:
https://github.com/0day-ci/linux/commits/Gilad-Avidov/net-emac-emac-gigabit-ethernet
Hi Gilad,
[auto build test WARNING on net/master]
[also build test WARNING on v4.4-rc7 next-20151223]
[if your patch is applied to the wrong git tree, please drop us a note to help
improving the system]
url:
https://github.com/0day-ci/linux/commits/Gilad-Avidov/net-emac-emac-gigabit-ethernet
18 matches
Mail list logo
