Francois Romieu :
> > +static int sxgbe_platform_probe(struct platform_device *pdev)
> [...]
> > + /* Get the SXGBE common INT information */
> > + priv->irq = irq_of_parse_and_map(node, 0);
> > + if (priv->irq <= 0) {
> > + dev_err(dev, "sxgbe common irq parsing failed\n");
> > +
keystone pcie hardware is based on designware version 3.65. This
doesn't support standard MSI controller and ATU port available
on newer version of the designware hardware. In keystone dw hardware
the application register space implements the legacy and MSI
irq controller registers and has register
This is a RFC to add Keystone pcie driver. I had some earlier discussion on
the pcie mailing about this driver and at that time I didn't have the driver
ported to dw core driver. I now have a driver working with intel's e1000e
ethernet driver and want to review this RFC on this list.
Kestone PCIE
keystone pcie hardware is based on designware hw version 3.65.
There is no support for ATU port and have registers in
application space to configure inbound/outbound access. Also
doesn't support PCI PVM option. So the MSI IRQ registers available
in application space is used to mask/unmask/enable th
Add pcie related options by default for keystone architecture
CC: Jingoo Han
CC: Bjorn Helgaas
CC: Kukjin Kim
CC: Richard Zhu
CC: Shawn Guo
CC: Mohit Kumar
CC: Santosh Shilimkar
Signed-off-by: Murali Karicheri
---
arch/arm/mach-keystone/Kconfig |2 ++
1 file changed, 2 insertions(+)
keystone pcie hardware is based on designware hw version 3.65.
There is no support for ATU port and have registers in
application space to configure inbound/outbound access. Also
doesn't support PCI PVM option. So the MSI IRQ registers available
in application space is used to mask/unmask/enable th
This is a RFC to add Keystone pcie driver. I had some earlier discussion on
the pcie mailing about this driver and at that time I didn't have the driver
ported to dw core driver. I now have a driver working with intel's e1000e
ethernet driver and want to review this RFC on this list.
Kestone PCIE
keystone pcie hardware is based on designware version 3.65. This
doesn't support standard MSI controller and ATU port available
on newer version of the designware hardware. In keystone dw hardware
the application register space implements the legacy and MSI
irq controller registers and has register
Add pcie related options by default for keystone architecture
CC: Jingoo Han
CC: Bjorn Helgaas
CC: Kukjin Kim
CC: Richard Zhu
CC: Shawn Guo
CC: Mohit Kumar
CC: Santosh Shilimkar
Signed-off-by: Murali Karicheri
---
arch/arm/mach-keystone/Kconfig |2 ++
1 file changed, 2 insertions(+)
Quoting Krzysztof Kozlowski (2014-03-21 05:18:17)
> If parent device does not have of_node set the s2mps11_clk_parse_dt()
> returned NULL. This NULL was later passed to of_clk_add_provider() which
> dereferenced it in pr_debug() call.
>
> Signed-off-by: Krzysztof Kozlowski
I've taken both of the
> +static int sxgbe_platform_probe(struct platform_device *pdev)
[...]
> + /* Get the SXGBE common INT information */
> + priv->irq = irq_of_parse_and_map(node, 0);
> + if (priv->irq <= 0) {
> + dev_err(dev, "sxgbe common irq parsing failed\n");
> + irq_dispose_
Sorry I didn't look over this earlier.
On Sat, 2014-03-22 at 21:04 -0700, Byungho An wrote:
[...]
> --- a/drivers/net/ethernet/samsung/sxgbe/sxgbe_common.h
> +++ b/drivers/net/ethernet/samsung/sxgbe/sxgbe_common.h
> @@ -42,8 +42,12 @@ struct sxgbe_mtl_ops;
> #define SXGBE_RX_QUEUES 16
>
> /*
[Adding Linaro lists in cc as there are few people here working on power/thermal
stuff.]
On 24 March 2014 15:30, Lukasz Majewski wrote:
>> On 4 March 2014 15:57, Lukasz Majewski wrote:
> I think, that "LAB" name is with us for some time, so it would be a
> pity to discard it.
It doesn't matter
Hi Viresh,
> On 4 March 2014 15:57, Lukasz Majewski wrote:
> > Despite this patch set is working and applicable on top of 3.14-rc5,
> > please regard it solely as a pure RFC.
>
> Okay, I am trying to do a review here and because you have mentioned
> how different it is from the earlier versions,
On 4 March 2014 15:57, Lukasz Majewski wrote:
> Despite this patch set is working and applicable on top of 3.14-rc5,
> please regard it solely as a pure RFC.
Okay, I am trying to do a review here and because you have mentioned
how different it is from the earlier versions, I am trying with a fres
15 matches
Mail list logo
