RE: [RESPIN 1/6] dt-bindings: EXYNOS: Add exynos-srom device tree binding
Hello! >> BTW, you could just combine both patches. I guess you didn't to >> maintain authorship? >OK. Will squash both of these patches, unless Pavel do not any objections. I don't. Kind regards.
RE: [RESPIN 1/6] dt-bindings: EXYNOS: Add exynos-srom device tree binding
Hello! >> BTW, you could just combine both patches. I guess you didn't to >> maintain authorship? >OK. Will squash both of these patches, unless Pavel do not any objections. I don't. Kind regards.
RE: [RESPIN 0/6] Add support for Exynos SROM Controller driver.
Hello! > I applied (with fixes mentioned in my comments) everything and pushed > here so everyone could play with it: > https://git.kernel.org/cgit/linux/kernel/git/krzk/linux.git/log/?h=for-v4.6/drivers-soc- > exynos-srom-2 I see the last patch (adding Ethernet chip to DT) is missing. Is it intentional, so that it goes later? Kind regards, Pavel Fedin Senior Engineer Samsung Electronics Research center Russia
RE: [RESPIN 0/6] Add support for Exynos SROM Controller driver.
Hello! > I applied (with fixes mentioned in my comments) everything and pushed > here so everyone could play with it: > https://git.kernel.org/cgit/linux/kernel/git/krzk/linux.git/log/?h=for-v4.6/drivers-soc- > exynos-srom-2 I see the last patch (adding Ethernet chip to DT) is missing. Is it intentional, so that it goes later? Kind regards, Pavel Fedin Senior Engineer Samsung Electronics Research center Russia
RE: [PATCH 4.3 138/157] ARM/arm64: KVM: test properly for a PTEs uncachedness
Hello! > This patch should not be applied independently without the fix in > mainline: > > 0de58f852875a0f0dcfb120bb8433e4e73c7803b > (ARM/arm64: KVM: correct PTE uncachedness check, 2015-12-03) It's ok, both are queued. Kind regards, Pavel Fedin Senior Engineer Samsung Electronics Research center Russia
RE: [PATCH 4.3 138/157] ARM/arm64: KVM: test properly for a PTEs uncachedness
Hello! > This patch should not be applied independently without the fix in > mainline: > > 0de58f852875a0f0dcfb120bb8433e4e73c7803b > (ARM/arm64: KVM: correct PTE uncachedness check, 2015-12-03) It's ok, both are queued. Kind regards, Pavel Fedin Senior Engineer Samsung Electronics Research center Russia
RE: [PATCH 00/10] KVM PCIe/MSI passthrough on ARM/ARM64
Hello! > x86 isn't problem-free in this space. An x86 VM is going to know that > the 0xfee0 address range is special, it won't be backed by RAM and > won't be a DMA target, thus we'll never attempt to map it for an iova > address. However, if we run a non-x86 VM or a userspace driver, it > doesn't necessarily know that there's anything special about that range > of iovas. I intend to resolve this with an extension to the iommu info > ioctl that describes the available iova space for the iommu. The > interrupt region would simply be excluded. I see now, but i still don't understand how it would work. How can we tell the guest OS that we cannot do DMA to this particular area? Just exclude it from RAM at all? But this means we would have to modify machine's model... I know that this is a bit different story from what we are implementing now. Just curious. Kind regards, Pavel Fedin Senior Engineer Samsung Electronics Research center Russia
RE: [PATCH 00/10] KVM PCIe/MSI passthrough on ARM/ARM64
Hello! > x86 isn't problem-free in this space. An x86 VM is going to know that > the 0xfee0 address range is special, it won't be backed by RAM and > won't be a DMA target, thus we'll never attempt to map it for an iova > address. However, if we run a non-x86 VM or a userspace driver, it > doesn't necessarily know that there's anything special about that range > of iovas. I intend to resolve this with an extension to the iommu info > ioctl that describes the available iova space for the iommu. The > interrupt region would simply be excluded. I see now, but i still don't understand how it would work. How can we tell the guest OS that we cannot do DMA to this particular area? Just exclude it from RAM at all? But this means we would have to modify machine's model... I know that this is a bit different story from what we are implementing now. Just curious. Kind regards, Pavel Fedin Senior Engineer Samsung Electronics Research center Russia
RE: [PATCH 00/10] KVM PCIe/MSI passthrough on ARM/ARM64
Hello! I'd like just to clarify some things for myself and better wrap my head around it... > On x86 all accesses to the 1MB PA region [FEE0_h - FEF0_000h] are directed > as interrupt messages: accesses to this special PA window directly target the > APIC configuration space and not DRAM, meaning the downstream IOMMU is > bypassed. So, this is effectively the same as always having hardwired 1:1 mappings on all IOMMUs, isn't it ? If so, then we can't we just do the same, just by forcing similar 1:1 mapping? This is what i tried to do in my patchset. All of you are talking about a situation which arises when we are emulating different machine with different physical addresses layout. And e. g. if our host has MSI at 0xABADCAFE, our target could have valid RAM at the same location, and we need to handle it somehow, therefore we have to move our MSI window out of target's RAM. But how does this work on a PC then? What if our host is PC, and we want to emulate some ARM board, which has RAM at FE00 ? Or does it mean that PC architecture is flawed and can reliably handle PCI passthrough only for itself ? Kind regards, Pavel Fedin Senior Engineer Samsung Electronics Research center Russia
RE: [PATCH 00/10] KVM PCIe/MSI passthrough on ARM/ARM64
Hello! I'd like just to clarify some things for myself and better wrap my head around it... > On x86 all accesses to the 1MB PA region [FEE0_h - FEF0_000h] are directed > as interrupt messages: accesses to this special PA window directly target the > APIC configuration space and not DRAM, meaning the downstream IOMMU is > bypassed. So, this is effectively the same as always having hardwired 1:1 mappings on all IOMMUs, isn't it ? If so, then we can't we just do the same, just by forcing similar 1:1 mapping? This is what i tried to do in my patchset. All of you are talking about a situation which arises when we are emulating different machine with different physical addresses layout. And e. g. if our host has MSI at 0xABADCAFE, our target could have valid RAM at the same location, and we need to handle it somehow, therefore we have to move our MSI window out of target's RAM. But how does this work on a PC then? What if our host is PC, and we want to emulate some ARM board, which has RAM at FE00 ? Or does it mean that PC architecture is flawed and can reliably handle PCI passthrough only for itself ? Kind regards, Pavel Fedin Senior Engineer Samsung Electronics Research center Russia
RE: [PATCH v9 0/4] Exynos SROMc configuration and Ethernet support for SMDK5410
Hello!
> 4. This branch is not pushed to linux-next. I will sort it out if my
> previous pull requests get in. I will be out of office for Christmas so
> depending on the timing of {arm-soc,Christmas,Kukjin} this may or may
> not go into v4.5 (yay...).
>
> 5. If it does not get into v4.5, I will rebase it and proceed further
> for v4.6.
>
> If you have any questions, please let me know.
Thank you very much. No, i don't have any questions, i'm glad that my work is
picked up and not lost, i'm just keeping an eye on it
until it goes to stable.
P.S. Not related to these sets directly, just to note... When i was writing
the doc for SROMc bindings, i noticed that we have two
directories for Exynos in Documentation/devicetree/bindings/arm:
1. Documentation/devicetree/bindings/arm/exynos
2. Documentation/devicetree/bindings/arm/Samsung
In (1) we have only a single old file, shouldn't this be cleaned up and
shouldn't this file be moved to (2)?
Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH v9 0/4] Exynos SROMc configuration and Ethernet support for SMDK5410
Hello!
> 4. This branch is not pushed to linux-next. I will sort it out if my
> previous pull requests get in. I will be out of office for Christmas so
> depending on the timing of {arm-soc,Christmas,Kukjin} this may or may
> not go into v4.5 (yay...).
>
> 5. If it does not get into v4.5, I will rebase it and proceed further
> for v4.6.
>
> If you have any questions, please let me know.
Thank you very much. No, i don't have any questions, i'm glad that my work is
picked up and not lost, i'm just keeping an eye on it
until it goes to stable.
P.S. Not related to these sets directly, just to note... When i was writing
the doc for SROMc bindings, i noticed that we have two
directories for Exynos in Documentation/devicetree/bindings/arm:
1. Documentation/devicetree/bindings/arm/exynos
2. Documentation/devicetree/bindings/arm/Samsung
In (1) we have only a single old file, shouldn't this be cleaned up and
shouldn't this file be moved to (2)?
Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 4.3 23/71] net: thunder: Check for driver data in nicvf_remove()
Hello! > stable patches should always match what is in Linus's tree, so I'm not > going to change the commit messages, sorry. Ok, no problem, i just wanted to suggest it to make more sense, because this msg alone doesn't explain anything. But, well, i understand that administrative rules always have priority. So let it just be this way. Kind regards, Pavel Fedin Expert Engineer Samsung Electronics Research center Russia -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 4.3 23/71] net: thunder: Check for driver data in nicvf_remove()
Hello! > stable patches should always match what is in Linus's tree, so I'm not > going to change the commit messages, sorry. Ok, no problem, i just wanted to suggest it to make more sense, because this msg alone doesn't explain anything. But, well, i understand that administrative rules always have priority. So let it just be this way. Kind regards, Pavel Fedin Expert Engineer Samsung Electronics Research center Russia -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [RESEND PATCH v5 0/8] Add support for Exynos SROM Controller driver
Hello! > THIS IS A RESEND OF ONCE MERGED INTO kgene/for-next AND LOST PATCHES > > Series v5 got merged in kgene/for-next but due to last moment change before > pull > these patches were not accepted during 4.3 merge window.After that > kgene/for-next > got rebased over 4.4-rc1 these patches got dropped into another branch and > till > date not included to for-next. I will not strictly require it because i'd like to move on with this somehow, and if this gets merged, i'm fine with it, but if you happen to send v6, may be you should include this small bit: http://www.spinics.net/lists/linux-samsung-soc/msg49008.html ? Kind regards, Pavel Fedin Expert Engineer Samsung Electronics Research center Russia -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 4.3 23/71] net: thunder: Check for driver data in nicvf_remove()
Hello!
It's good to apply this to stable, however IMHO commit message should be
changed. Actually, this was fix for a fix, so in theory
5883d9c6d7e680bcdc7a8a9ed2509cd10dd98206 and
7750130d93decff06120df0d8ea024ff8a038a21 should have been squashed together.
You can
take a commit message from 5883d9c6d7e680bcdc7a8a9ed2509cd10dd98206, it better
explains what was actually done and why.
There's also a clean patch:
https://www.mail-archive.com/netdev@vger.kernel.org/msg87010.html, which was
not applied because v1 was
already applied and David doesn't revert commits.
Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia
> -Original Message-
> From: Greg Kroah-Hartman [mailto:gre...@linuxfoundation.org]
> Sent: Saturday, December 12, 2015 11:06 PM
> To: linux-kernel@vger.kernel.org
> Cc: Greg Kroah-Hartman; sta...@vger.kernel.org; Pavel Fedin; David S. Miller
> Subject: [PATCH 4.3 23/71] net: thunder: Check for driver data in
> nicvf_remove()
>
> 4.3-stable review patch. If anyone has any objections, please let me know.
>
> ------
>
> From: Pavel Fedin
>
> [ Upstream commit 7750130d93decff06120df0d8ea024ff8a038a21 ]
>
> In some cases the crash is caused by nicvf_remove() being called from
> outside. For example, if we try to feed the device to vfio after the
> probe has failed for some reason. So, move the check to better place.
>
> Signed-off-by: Pavel Fedin
> Signed-off-by: David S. Miller
> Signed-off-by: Greg Kroah-Hartman
> ---
> drivers/net/ethernet/cavium/thunder/nicvf_main.c | 10 --
> 1 file changed, 8 insertions(+), 2 deletions(-)
>
> --- a/drivers/net/ethernet/cavium/thunder/nicvf_main.c
> +++ b/drivers/net/ethernet/cavium/thunder/nicvf_main.c
> @@ -1583,8 +1583,14 @@ err_disable_device:
> static void nicvf_remove(struct pci_dev *pdev)
> {
> struct net_device *netdev = pci_get_drvdata(pdev);
> - struct nicvf *nic = netdev_priv(netdev);
> - struct net_device *pnetdev = nic->pnicvf->netdev;
> + struct nicvf *nic;
> + struct net_device *pnetdev;
> +
> + if (!netdev)
> + return;
> +
> + nic = netdev_priv(netdev);
> + pnetdev = nic->pnicvf->netdev;
>
> /* Check if this Qset is assigned to different VF.
>* If yes, clean primary and all secondary Qsets.
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [RESEND PATCH v5 0/8] Add support for Exynos SROM Controller driver
Hello! > THIS IS A RESEND OF ONCE MERGED INTO kgene/for-next AND LOST PATCHES > > Series v5 got merged in kgene/for-next but due to last moment change before > pull > these patches were not accepted during 4.3 merge window.After that > kgene/for-next > got rebased over 4.4-rc1 these patches got dropped into another branch and > till > date not included to for-next. I will not strictly require it because i'd like to move on with this somehow, and if this gets merged, i'm fine with it, but if you happen to send v6, may be you should include this small bit: http://www.spinics.net/lists/linux-samsung-soc/msg49008.html ? Kind regards, Pavel Fedin Expert Engineer Samsung Electronics Research center Russia -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 4.3 23/71] net: thunder: Check for driver data in nicvf_remove()
Hello!
It's good to apply this to stable, however IMHO commit message should be
changed. Actually, this was fix for a fix, so in theory
5883d9c6d7e680bcdc7a8a9ed2509cd10dd98206 and
7750130d93decff06120df0d8ea024ff8a038a21 should have been squashed together.
You can
take a commit message from 5883d9c6d7e680bcdc7a8a9ed2509cd10dd98206, it better
explains what was actually done and why.
There's also a clean patch:
https://www.mail-archive.com/netdev@vger.kernel.org/msg87010.html, which was
not applied because v1 was
already applied and David doesn't revert commits.
Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia
> -Original Message-
> From: Greg Kroah-Hartman [mailto:gre...@linuxfoundation.org]
> Sent: Saturday, December 12, 2015 11:06 PM
> To: linux-kernel@vger.kernel.org
> Cc: Greg Kroah-Hartman; sta...@vger.kernel.org; Pavel Fedin; David S. Miller
> Subject: [PATCH 4.3 23/71] net: thunder: Check for driver data in
> nicvf_remove()
>
> 4.3-stable review patch. If anyone has any objections, please let me know.
>
> ------
>
> From: Pavel Fedin <p.fe...@samsung.com>
>
> [ Upstream commit 7750130d93decff06120df0d8ea024ff8a038a21 ]
>
> In some cases the crash is caused by nicvf_remove() being called from
> outside. For example, if we try to feed the device to vfio after the
> probe has failed for some reason. So, move the check to better place.
>
> Signed-off-by: Pavel Fedin <p.fe...@samsung.com>
> Signed-off-by: David S. Miller <da...@davemloft.net>
> Signed-off-by: Greg Kroah-Hartman <gre...@linuxfoundation.org>
> ---
> drivers/net/ethernet/cavium/thunder/nicvf_main.c | 10 --
> 1 file changed, 8 insertions(+), 2 deletions(-)
>
> --- a/drivers/net/ethernet/cavium/thunder/nicvf_main.c
> +++ b/drivers/net/ethernet/cavium/thunder/nicvf_main.c
> @@ -1583,8 +1583,14 @@ err_disable_device:
> static void nicvf_remove(struct pci_dev *pdev)
> {
> struct net_device *netdev = pci_get_drvdata(pdev);
> - struct nicvf *nic = netdev_priv(netdev);
> - struct net_device *pnetdev = nic->pnicvf->netdev;
> + struct nicvf *nic;
> + struct net_device *pnetdev;
> +
> + if (!netdev)
> + return;
> +
> + nic = netdev_priv(netdev);
> + pnetdev = nic->pnicvf->netdev;
>
> /* Check if this Qset is assigned to different VF.
>* If yes, clean primary and all secondary Qsets.
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH v2 0/2] net: thunderx: Support for pass-2 hw features
All series: Reviewed-by: Pavel Fedin Kind regards, Pavel Fedin Expert Engineer Samsung Electronics Research center Russia -Original Message- From: netdev-ow...@vger.kernel.org [mailto:netdev-ow...@vger.kernel.org] On Behalf Of Sunil Goutham Sent: Thursday, December 10, 2015 10:55 AM To: net...@vger.kernel.org Cc: linux-kernel@vger.kernel.org; linux-arm-ker...@lists.infradead.org; p.fe...@samsung.com; sunil.gout...@caviumnetworks.com; Sunil Goutham Subject: [PATCH v2 0/2] net: thunderx: Support for pass-2 hw features From: Sunil Goutham This patch set adds support for new features added in pass-2 revision of hardware like TSO and count based interrupt coalescing. Changes from v1: - Addressed comments received regarding boolean bit field changes by excluding them from this patch. Will submit a seperate patch along with cleanup of unsed field. - Got rid of new macro 'VNIC_NAPI_WEIGHT' introduced in count threshold interrupt patch. Sunil Goutham (2): net: thunderx: HW TSO support for pass-2 hardware net: thunderx: Enable CQE count threshold interrupt drivers/net/ethernet/cavium/thunder/nic.h |6 drivers/net/ethernet/cavium/thunder/nic_main.c | 11 ++- drivers/net/ethernet/cavium/thunder/nicvf_main.c | 15 - drivers/net/ethernet/cavium/thunder/nicvf_queues.c | 22 ++ drivers/net/ethernet/cavium/thunder/nicvf_queues.h |2 +- drivers/net/ethernet/cavium/thunder/q_struct.h | 30 ++- 6 files changed, 55 insertions(+), 31 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH v2 0/2] net: thunderx: Support for pass-2 hw features
All series: Reviewed-by: Pavel Fedin <p.fe...@samsung.com> Kind regards, Pavel Fedin Expert Engineer Samsung Electronics Research center Russia -Original Message- From: netdev-ow...@vger.kernel.org [mailto:netdev-ow...@vger.kernel.org] On Behalf Of Sunil Goutham Sent: Thursday, December 10, 2015 10:55 AM To: net...@vger.kernel.org Cc: linux-kernel@vger.kernel.org; linux-arm-ker...@lists.infradead.org; p.fe...@samsung.com; sunil.gout...@caviumnetworks.com; Sunil Goutham Subject: [PATCH v2 0/2] net: thunderx: Support for pass-2 hw features From: Sunil Goutham <sgout...@cavium.com> This patch set adds support for new features added in pass-2 revision of hardware like TSO and count based interrupt coalescing. Changes from v1: - Addressed comments received regarding boolean bit field changes by excluding them from this patch. Will submit a seperate patch along with cleanup of unsed field. - Got rid of new macro 'VNIC_NAPI_WEIGHT' introduced in count threshold interrupt patch. Sunil Goutham (2): net: thunderx: HW TSO support for pass-2 hardware net: thunderx: Enable CQE count threshold interrupt drivers/net/ethernet/cavium/thunder/nic.h |6 drivers/net/ethernet/cavium/thunder/nic_main.c | 11 ++- drivers/net/ethernet/cavium/thunder/nicvf_main.c | 15 - drivers/net/ethernet/cavium/thunder/nicvf_queues.c | 22 ++ drivers/net/ethernet/cavium/thunder/nicvf_queues.h |2 +- drivers/net/ethernet/cavium/thunder/q_struct.h | 30 ++- 6 files changed, 55 insertions(+), 31 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 2/2] net: thunderx: Enable CQE count threshold interrupt
Hello! > -Original Message- > From: netdev-ow...@vger.kernel.org [mailto:netdev-ow...@vger.kernel.org] On > Behalf Of Sunil > Goutham > Sent: Wednesday, December 09, 2015 2:38 PM > To: net...@vger.kernel.org > Cc: linux-kernel@vger.kernel.org; linux-arm-ker...@lists.infradead.org; > p.fe...@samsung.com; > sunil.gout...@caviumnetworks.com; Sunil Goutham > Subject: [PATCH 2/2] net: thunderx: Enable CQE count threshold interrupt > > From: Sunil Goutham > > This feature is introduced in pass-2 chip and with this CQ interrupt > coalescing will work based on both timer and count. > > Signed-off-by: Sunil Goutham > --- > drivers/net/ethernet/cavium/thunder/nic.h |2 ++ > drivers/net/ethernet/cavium/thunder/nicvf_main.c |2 +- > drivers/net/ethernet/cavium/thunder/nicvf_queues.c |5 - > drivers/net/ethernet/cavium/thunder/nicvf_queues.h |3 ++- > 4 files changed, 9 insertions(+), 3 deletions(-) > > diff --git a/drivers/net/ethernet/cavium/thunder/nic.h > b/drivers/net/ethernet/cavium/thunder/nic.h > index 02571f4..e782856 100644 > --- a/drivers/net/ethernet/cavium/thunder/nic.h > +++ b/drivers/net/ethernet/cavium/thunder/nic.h > @@ -34,6 +34,8 @@ > /* NIC priv flags */ > #define NIC_SRIOV_ENABLED BIT(0) > > +#define VNIC_NAPI_WEIGHTNAPI_POLL_WEIGHT > + > /* Min/Max packet size */ > #define NIC_HW_MIN_FRS 64 > #define NIC_HW_MAX_FRS 9200 /* 9216 max packet > including FCS */ > diff --git a/drivers/net/ethernet/cavium/thunder/nicvf_main.c > b/drivers/net/ethernet/cavium/thunder/nicvf_main.c > index c24cb2a..e06a7f8 100644 > --- a/drivers/net/ethernet/cavium/thunder/nicvf_main.c > +++ b/drivers/net/ethernet/cavium/thunder/nicvf_main.c > @@ -1155,7 +1155,7 @@ int nicvf_open(struct net_device *netdev) > cq_poll->cq_idx = qidx; > cq_poll->nicvf = nic; > netif_napi_add(netdev, _poll->napi, nicvf_poll, > -NAPI_POLL_WEIGHT); > +VNIC_NAPI_WEIGHT); What's the sense in introducing another constant which is aliased to the previous one? Making LOC bigger? > napi_enable(_poll->napi); > nic->napi[qidx] = cq_poll; > } > diff --git a/drivers/net/ethernet/cavium/thunder/nicvf_queues.c > b/drivers/net/ethernet/cavium/thunder/nicvf_queues.c > index b11fc09..4e9709e 100644 > --- a/drivers/net/ethernet/cavium/thunder/nicvf_queues.c > +++ b/drivers/net/ethernet/cavium/thunder/nicvf_queues.c > @@ -299,7 +299,10 @@ static int nicvf_init_cmp_queue(struct nicvf *nic, > return err; > > cq->desc = cq->dmem.base; > - cq->thresh = CMP_QUEUE_CQE_THRESH; > + if (!pass1_silicon(nic->pdev)) > + cq->thresh = CMP_QUEUE_CQE_THRESH; > + else > + cq->thresh = 0; IMHO "cq->thresh = pass1_silicon(nic->pdev) ? CMP_QUEUE_CQE_THRESH : 0" looks less bulky. > nic->cq_coalesce_usecs = (CMP_QUEUE_TIMER_THRESH * 0.05) - 1; > > return 0; > diff --git a/drivers/net/ethernet/cavium/thunder/nicvf_queues.h > b/drivers/net/ethernet/cavium/thunder/nicvf_queues.h > index a4f6667..0fae6ad 100644 > --- a/drivers/net/ethernet/cavium/thunder/nicvf_queues.h > +++ b/drivers/net/ethernet/cavium/thunder/nicvf_queues.h > @@ -10,6 +10,7 @@ > #define NICVF_QUEUES_H > > #include > +#include "nic.h" > #include "q_struct.h" > > #define MAX_QUEUE_SET128 > @@ -75,7 +76,7 @@ > */ > #define CMP_QSIZECMP_QUEUE_SIZE2 > #define CMP_QUEUE_LEN(1ULL << (CMP_QSIZE + 10)) > -#define CMP_QUEUE_CQE_THRESH 0 > +#define CMP_QUEUE_CQE_THRESH (VNIC_NAPI_WEIGHT / 2) > #define CMP_QUEUE_TIMER_THRESH 80 /* ~2usec */ > > #define RBDR_SIZERBDR_SIZE0 > -- > 1.7.1 Kind regards, Pavel Fedin Expert Engineer Samsung Electronics Research center Russia -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 1/2] net: thunderx: HW TSO support for pass-2 hardware
skb, skb->len);
>
> /* Add SQ gather subdescs */
> qentry = nicvf_get_nxt_sqentry(sq, qentry);
> diff --git a/drivers/net/ethernet/cavium/thunder/q_struct.h
> b/drivers/net/ethernet/cavium/thunder/q_struct.h
> index 3c1de97..9e6d987 100644
> --- a/drivers/net/ethernet/cavium/thunder/q_struct.h
> +++ b/drivers/net/ethernet/cavium/thunder/q_struct.h
> @@ -545,25 +545,28 @@ struct sq_hdr_subdesc {
> u64subdesc_cnt:8;
> u64csum_l4:2;
> u64csum_l3:1;
> - u64rsvd0:5;
> + u64csum_inner_l4:2;
> + u64csum_inner_l3:1;
> + u64rsvd0:2;
> u64l4_offset:8;
> u64l3_offset:8;
> u64rsvd1:4;
> u64tot_len:20; /* W0 */
>
> - u64tso_sdc_cont:8;
> - u64tso_sdc_first:8;
> - u64tso_l4_offset:8;
> - u64tso_flags_last:12;
> - u64tso_flags_first:12;
> - u64rsvd2:2;
> + u64rsvd2:24;
> + u64inner_l4_offset:8;
> + u64inner_l3_offset:8;
> + u64tso_start:8;
> + u64 rsvd3:2;
> u64tso_max_paysize:14; /* W1 */
> #elif defined(__LITTLE_ENDIAN_BITFIELD)
> u64tot_len:20;
> u64rsvd1:4;
> u64l3_offset:8;
> u64l4_offset:8;
> - u64rsvd0:5;
> + u64rsvd0:2;
> + u64csum_inner_l3:1;
> + u64csum_inner_l4:2;
> u64csum_l3:1;
> u64csum_l4:2;
> u64subdesc_cnt:8;
> @@ -574,12 +577,11 @@ struct sq_hdr_subdesc {
> u64subdesc_type:4; /* W0 */
>
> u64tso_max_paysize:14;
> - u64rsvd2:2;
> - u64tso_flags_first:12;
> - u64tso_flags_last:12;
> - u64tso_l4_offset:8;
> - u64tso_sdc_first:8;
> - u64tso_sdc_cont:8; /* W1 */
> + u64rsvd3:2;
> + u64tso_start:8;
> + u64inner_l3_offset:8;
> + u64inner_l4_offset:8;
> + u64rsvd2:24; /* W1 */
> #endif
> };
>
> --
> 1.7.1
>
Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 2/2] net: thunderx: Enable CQE count threshold interrupt
Hello! > -Original Message- > From: netdev-ow...@vger.kernel.org [mailto:netdev-ow...@vger.kernel.org] On > Behalf Of Sunil > Goutham > Sent: Wednesday, December 09, 2015 2:38 PM > To: net...@vger.kernel.org > Cc: linux-kernel@vger.kernel.org; linux-arm-ker...@lists.infradead.org; > p.fe...@samsung.com; > sunil.gout...@caviumnetworks.com; Sunil Goutham > Subject: [PATCH 2/2] net: thunderx: Enable CQE count threshold interrupt > > From: Sunil Goutham <sgout...@cavium.com> > > This feature is introduced in pass-2 chip and with this CQ interrupt > coalescing will work based on both timer and count. > > Signed-off-by: Sunil Goutham <sgout...@cavium.com> > --- > drivers/net/ethernet/cavium/thunder/nic.h |2 ++ > drivers/net/ethernet/cavium/thunder/nicvf_main.c |2 +- > drivers/net/ethernet/cavium/thunder/nicvf_queues.c |5 - > drivers/net/ethernet/cavium/thunder/nicvf_queues.h |3 ++- > 4 files changed, 9 insertions(+), 3 deletions(-) > > diff --git a/drivers/net/ethernet/cavium/thunder/nic.h > b/drivers/net/ethernet/cavium/thunder/nic.h > index 02571f4..e782856 100644 > --- a/drivers/net/ethernet/cavium/thunder/nic.h > +++ b/drivers/net/ethernet/cavium/thunder/nic.h > @@ -34,6 +34,8 @@ > /* NIC priv flags */ > #define NIC_SRIOV_ENABLED BIT(0) > > +#define VNIC_NAPI_WEIGHTNAPI_POLL_WEIGHT > + > /* Min/Max packet size */ > #define NIC_HW_MIN_FRS 64 > #define NIC_HW_MAX_FRS 9200 /* 9216 max packet > including FCS */ > diff --git a/drivers/net/ethernet/cavium/thunder/nicvf_main.c > b/drivers/net/ethernet/cavium/thunder/nicvf_main.c > index c24cb2a..e06a7f8 100644 > --- a/drivers/net/ethernet/cavium/thunder/nicvf_main.c > +++ b/drivers/net/ethernet/cavium/thunder/nicvf_main.c > @@ -1155,7 +1155,7 @@ int nicvf_open(struct net_device *netdev) > cq_poll->cq_idx = qidx; > cq_poll->nicvf = nic; > netif_napi_add(netdev, _poll->napi, nicvf_poll, > -NAPI_POLL_WEIGHT); > +VNIC_NAPI_WEIGHT); What's the sense in introducing another constant which is aliased to the previous one? Making LOC bigger? > napi_enable(_poll->napi); > nic->napi[qidx] = cq_poll; > } > diff --git a/drivers/net/ethernet/cavium/thunder/nicvf_queues.c > b/drivers/net/ethernet/cavium/thunder/nicvf_queues.c > index b11fc09..4e9709e 100644 > --- a/drivers/net/ethernet/cavium/thunder/nicvf_queues.c > +++ b/drivers/net/ethernet/cavium/thunder/nicvf_queues.c > @@ -299,7 +299,10 @@ static int nicvf_init_cmp_queue(struct nicvf *nic, > return err; > > cq->desc = cq->dmem.base; > - cq->thresh = CMP_QUEUE_CQE_THRESH; > + if (!pass1_silicon(nic->pdev)) > + cq->thresh = CMP_QUEUE_CQE_THRESH; > + else > + cq->thresh = 0; IMHO "cq->thresh = pass1_silicon(nic->pdev) ? CMP_QUEUE_CQE_THRESH : 0" looks less bulky. > nic->cq_coalesce_usecs = (CMP_QUEUE_TIMER_THRESH * 0.05) - 1; > > return 0; > diff --git a/drivers/net/ethernet/cavium/thunder/nicvf_queues.h > b/drivers/net/ethernet/cavium/thunder/nicvf_queues.h > index a4f6667..0fae6ad 100644 > --- a/drivers/net/ethernet/cavium/thunder/nicvf_queues.h > +++ b/drivers/net/ethernet/cavium/thunder/nicvf_queues.h > @@ -10,6 +10,7 @@ > #define NICVF_QUEUES_H > > #include > +#include "nic.h" > #include "q_struct.h" > > #define MAX_QUEUE_SET128 > @@ -75,7 +76,7 @@ > */ > #define CMP_QSIZECMP_QUEUE_SIZE2 > #define CMP_QUEUE_LEN(1ULL << (CMP_QSIZE + 10)) > -#define CMP_QUEUE_CQE_THRESH 0 > +#define CMP_QUEUE_CQE_THRESH (VNIC_NAPI_WEIGHT / 2) > #define CMP_QUEUE_TIMER_THRESH 80 /* ~2usec */ > > #define RBDR_SIZERBDR_SIZE0 > -- > 1.7.1 Kind regards, Pavel Fedin Expert Engineer Samsung Electronics Research center Russia -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 1/2] net: thunderx: HW TSO support for pass-2 hardware
dd_hdr_subdesc(nic, sq, qentry, subdesc_cnt - 1,
> + skb, skb->len);
>
> /* Add SQ gather subdescs */
> qentry = nicvf_get_nxt_sqentry(sq, qentry);
> diff --git a/drivers/net/ethernet/cavium/thunder/q_struct.h
> b/drivers/net/ethernet/cavium/thunder/q_struct.h
> index 3c1de97..9e6d987 100644
> --- a/drivers/net/ethernet/cavium/thunder/q_struct.h
> +++ b/drivers/net/ethernet/cavium/thunder/q_struct.h
> @@ -545,25 +545,28 @@ struct sq_hdr_subdesc {
> u64subdesc_cnt:8;
> u64csum_l4:2;
> u64csum_l3:1;
> - u64rsvd0:5;
> + u64csum_inner_l4:2;
> + u64csum_inner_l3:1;
> + u64rsvd0:2;
> u64l4_offset:8;
> u64l3_offset:8;
> u64rsvd1:4;
> u64tot_len:20; /* W0 */
>
> - u64tso_sdc_cont:8;
> - u64tso_sdc_first:8;
> - u64tso_l4_offset:8;
> - u64tso_flags_last:12;
> - u64tso_flags_first:12;
> - u64rsvd2:2;
> + u64rsvd2:24;
> + u64inner_l4_offset:8;
> + u64inner_l3_offset:8;
> + u64tso_start:8;
> + u64 rsvd3:2;
> u64tso_max_paysize:14; /* W1 */
> #elif defined(__LITTLE_ENDIAN_BITFIELD)
> u64tot_len:20;
> u64rsvd1:4;
> u64l3_offset:8;
> u64l4_offset:8;
> - u64rsvd0:5;
> + u64rsvd0:2;
> + u64csum_inner_l3:1;
> + u64csum_inner_l4:2;
> u64csum_l3:1;
> u64csum_l4:2;
> u64subdesc_cnt:8;
> @@ -574,12 +577,11 @@ struct sq_hdr_subdesc {
> u64subdesc_type:4; /* W0 */
>
> u64tso_max_paysize:14;
> - u64rsvd2:2;
> - u64tso_flags_first:12;
> - u64tso_flags_last:12;
> - u64tso_l4_offset:8;
> - u64tso_sdc_first:8;
> - u64tso_sdc_cont:8; /* W1 */
> + u64rsvd3:2;
> + u64tso_start:8;
> + u64inner_l3_offset:8;
> + u64inner_l4_offset:8;
> + u64rsvd2:24; /* W1 */
> #endif
> };
>
> --
> 1.7.1
>
Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 0/2] net: thunderx: Miscellaneous cleanups
Tested-by: Pavel Fedin Kind regards, Pavel Fedin Expert Engineer Samsung Electronics Research center Russia > -Original Message- > From: netdev-ow...@vger.kernel.org [mailto:netdev-ow...@vger.kernel.org] On > Behalf Of Sunil > Goutham > Sent: Monday, December 07, 2015 8:01 AM > To: net...@vger.kernel.org > Cc: linux-kernel@vger.kernel.org; linux-arm-ker...@lists.infradead.org; > p.fe...@samsung.com; > sunil.gout...@caviumnetworks.com; Sunil Goutham > Subject: [PATCH 0/2] net: thunderx: Miscellaneous cleanups > > From: Sunil Goutham > > This patch series contains contains couple of cleanup patches. > > Sunil Goutham (1): > net, thunderx: Remove unnecessary rcv buffer start address management > > Yury Norov (1): > net: thunderx: nicvf_queues: nivc_*_intr: remove duplication > > drivers/net/ethernet/cavium/thunder/nicvf_queues.c | 189 > +--- > drivers/net/ethernet/cavium/thunder/nicvf_queues.h | 10 +- > 2 files changed, 51 insertions(+), 148 deletions(-) > > -- > To unsubscribe from this list: send the line "unsubscribe netdev" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 0/2] net: thunderx: Miscellaneous cleanups
Tested-by: Pavel Fedin <p.fe...@samsung.com> Kind regards, Pavel Fedin Expert Engineer Samsung Electronics Research center Russia > -Original Message- > From: netdev-ow...@vger.kernel.org [mailto:netdev-ow...@vger.kernel.org] On > Behalf Of Sunil > Goutham > Sent: Monday, December 07, 2015 8:01 AM > To: net...@vger.kernel.org > Cc: linux-kernel@vger.kernel.org; linux-arm-ker...@lists.infradead.org; > p.fe...@samsung.com; > sunil.gout...@caviumnetworks.com; Sunil Goutham > Subject: [PATCH 0/2] net: thunderx: Miscellaneous cleanups > > From: Sunil Goutham <sgout...@cavium.com> > > This patch series contains contains couple of cleanup patches. > > Sunil Goutham (1): > net, thunderx: Remove unnecessary rcv buffer start address management > > Yury Norov (1): > net: thunderx: nicvf_queues: nivc_*_intr: remove duplication > > drivers/net/ethernet/cavium/thunder/nicvf_queues.c | 189 > +--- > drivers/net/ethernet/cavium/thunder/nicvf_queues.h | 10 +- > 2 files changed, 51 insertions(+), 148 deletions(-) > > -- > To unsubscribe from this list: send the line "unsubscribe netdev" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 3/6] net: thunderx: Increase transmit queue length
Hello! > >After getting it working in guest i tried to apply it to host. With total of > >128 virtual > functions (= 128 interfaces) it does not work at all. > > Even after bumping cma region size to insane value of 2GB more than half of > > interfaces still > failed to allocate queues. > > And after setting cma=3G i could not mount my rootfs. > > Here what you are saying is half of the interfaces were initialized > succesfully and rest didn't. After setting cma=2G. With default setting of 16M none of them initialized. > So this issue is not something which is introduced by this patch. Before this patch all my interfaces were working. I would say the problem with your patch is that it introduces memory requirements which cannot be satisfied by the platform. It's combination of several factors which stops the thing from working, not a single factor. Using dma_alloc_coherent() is not all wrong by itself, of course. Perhaps you did some tricks with your configuration, which make it working. Then, i guess, you should have at least described them in commit message of your patch. Or describe all dependencies in KConfig of your driver, which is better. Or, if the platform needs some very special defconfig, add it to arch/arm64/configs (however, i guess, the goal of ARM64 Linux is to run on all possible hardware, so this would not be good from maintainers' POV). Sorry, but this is all i can say. In previous messages i have already suggested several ways to solve the problem (too lazy to quite here, 4 IIRC), or you can suggest your own one and let us test it, or you can even stick to "It works for me, i am the only right guy in the world, and i don't care if it doesn't work for you" position and let David decide who of us is right (and he already did that once). Basically, here is what i did: i took kernel 4.2, added ThunderX PCI drivers to it (they were posted but NAKed those days back, there's some lazy progress on them currently), added necessary errata patches (also posted on lists, all merged into 4.4), took defconfig, adjusted it according to my needs, and this is what i'm running on my board and this is what i'm using for development. If you point me at what i'm doing wrong way, i'll be glad to accept this. I'm over. Kind regards, Pavel Fedin Expert Engineer Samsung Electronics Research center Russia -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 3/6] net: thunderx: Increase transmit queue length
Hello! > > So, i see several possible ways to solve this: > > > > 1. Introduce some mechanism which would allow the driver to tell the kernel > > that it needs > > coherent pool of large size. Can be problematic because the driver can be a > > module, and pool > > allocation happens early. > > 2. Can we use some other method for allocating queues, which would not > > require such a huge > > coherent pool? > > 3. The driver could check value of atomic_pool_size and adjust own memory > > requirements > > accordingly. This indeed looks like a quick hack, but would at least make > > things running > > quickly. > > I have also noticed that CONFIG_DMA_CMA is turned off in my kernel. I guess > it was a leftover > from old defconfig, because i carry over my .config from version to version. > I enabled it and > rebuilt the kernel, but in order to get the driver working with this patch i > had to also add > cma=32M option to kernel arguments. With default of 16M the allocation still > fails. > Should we add Kconfig dependencies? After getting it working in guest i tried to apply it to host. With total of 128 virtual functions (= 128 interfaces) it does not work at all. Even after bumping cma region size to insane value of 2GB more than half of interfaces still failed to allocate queues. And after setting cma=3G i could not mount my rootfs. So, absolute NAK, unfortunately. Kind regards, Pavel Fedin Expert Engineer Samsung Electronics Research center Russia -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH v2 4/5] net: thunderx: Switchon carrier only upon interface link up
Hello again! > Subject: RE: [PATCH v2 4/5] net: thunderx: Switchon carrier only upon > interface link up > > Just a reminder, we have issue with this one too, which is not addressed yet. I have examined the problem thoroughly and discovered that it is a problem with experimental BGX driver patches on my 4.2 host kernel build. It fails to send NIC_MBOX_MSG_BGX_LINK_CHANGE, so nothing works. I have retested this series on top of 4.3 running on ThunderX. It has good BGX driver and everything works fine. Therefore, the whole series can be safely applied and... Tested-by: Pavel Fedin Kind regards, Pavel Fedin Expert Engineer Samsung Electronics Research center Russia -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH v2 4/5] net: thunderx: Switchon carrier only upon interface link up
Just a reminder, we have issue with this one too, which is not addressed yet.
Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia
> -Original Message-
> From: netdev-ow...@vger.kernel.org [mailto:netdev-ow...@vger.kernel.org] On
> Behalf Of Sunil
> Goutham
> Sent: Wednesday, December 02, 2015 1:06 PM
> To: net...@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
> sunil.gout...@caviumnetworks.com; Sunil Goutham
> Subject: [PATCH v2 4/5] net: thunderx: Switchon carrier only upon interface
> link up
>
> From: Sunil Goutham
>
> Call netif_carrier_on() only if interface's link is up. Switching this on
> upon IFF_UP by default, is causing issues with ethernet channel bonding
> in LACP mode. Initial NETDEV_CHANGE notification was being skipped.
>
> Also fixed some issues with link/speed/duplex reporting via ethtool.
>
> Signed-off-by: Sunil Goutham
> ---
> .../net/ethernet/cavium/thunder/nicvf_ethtool.c| 16 +++-
> drivers/net/ethernet/cavium/thunder/nicvf_main.c |4 +---
> drivers/net/ethernet/cavium/thunder/thunder_bgx.c |2 ++
> 3 files changed, 18 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/net/ethernet/cavium/thunder/nicvf_ethtool.c
> b/drivers/net/ethernet/cavium/thunder/nicvf_ethtool.c
> index af54c10..a12b2e3 100644
> --- a/drivers/net/ethernet/cavium/thunder/nicvf_ethtool.c
> +++ b/drivers/net/ethernet/cavium/thunder/nicvf_ethtool.c
> @@ -112,6 +112,13 @@ static int nicvf_get_settings(struct net_device *netdev,
>
> cmd->supported = 0;
> cmd->transceiver = XCVR_EXTERNAL;
> +
> + if (!nic->link_up) {
> + cmd->duplex = DUPLEX_UNKNOWN;
> + ethtool_cmd_speed_set(cmd, SPEED_UNKNOWN);
> + return 0;
> + }
> +
> if (nic->speed <= 1000) {
> cmd->port = PORT_MII;
> cmd->autoneg = AUTONEG_ENABLE;
> @@ -125,6 +132,13 @@ static int nicvf_get_settings(struct net_device *netdev,
> return 0;
> }
>
> +static u32 nicvf_get_link(struct net_device *netdev)
> +{
> + struct nicvf *nic = netdev_priv(netdev);
> +
> + return nic->link_up;
> +}
> +
> static void nicvf_get_drvinfo(struct net_device *netdev,
> struct ethtool_drvinfo *info)
> {
> @@ -660,7 +674,7 @@ static int nicvf_set_channels(struct net_device *dev,
>
> static const struct ethtool_ops nicvf_ethtool_ops = {
> .get_settings = nicvf_get_settings,
> - .get_link = ethtool_op_get_link,
> + .get_link = nicvf_get_link,
> .get_drvinfo= nicvf_get_drvinfo,
> .get_msglevel = nicvf_get_msglevel,
> .set_msglevel = nicvf_set_msglevel,
> diff --git a/drivers/net/ethernet/cavium/thunder/nicvf_main.c
> b/drivers/net/ethernet/cavium/thunder/nicvf_main.c
> index 7f709cb..dde8dc7 100644
> --- a/drivers/net/ethernet/cavium/thunder/nicvf_main.c
> +++ b/drivers/net/ethernet/cavium/thunder/nicvf_main.c
> @@ -1057,6 +1057,7 @@ int nicvf_stop(struct net_device *netdev)
>
> netif_carrier_off(netdev);
> netif_tx_stop_all_queues(nic->netdev);
> + nic->link_up = false;
>
> /* Teardown secondary qsets first */
> if (!nic->sqs_mode) {
> @@ -1211,9 +1212,6 @@ int nicvf_open(struct net_device *netdev)
> nic->drv_stats.txq_stop = 0;
> nic->drv_stats.txq_wake = 0;
>
> - netif_carrier_on(netdev);
> - netif_tx_start_all_queues(netdev);
> -
> return 0;
> cleanup:
> nicvf_disable_intr(nic, NICVF_INTR_MBOX, 0);
> diff --git a/drivers/net/ethernet/cavium/thunder/thunder_bgx.c
> b/drivers/net/ethernet/cavium/thunder/thunder_bgx.c
> index 6534b73..d77e41a 100644
> --- a/drivers/net/ethernet/cavium/thunder/thunder_bgx.c
> +++ b/drivers/net/ethernet/cavium/thunder/thunder_bgx.c
> @@ -612,6 +612,8 @@ static void bgx_poll_for_link(struct work_struct *work)
> lmac->last_duplex = 1;
> } else {
> lmac->link_up = 0;
> + lmac->last_speed = SPEED_UNKNOWN;
> + lmac->last_duplex = DUPLEX_UNKNOWN;
> }
>
> if (lmac->last_link != lmac->link_up) {
> --
> 1.7.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 3/6] net: thunderx: Increase transmit queue length
Hello! > > Probably you might have to set "coherent_pool" size in bootargs to a > > higher value. > > Can you please check. > > I have tried to do this. I was able to enlarge the pool up to 4MB, and still > got allocation > failures. At 8MB pool preallocation stops working: > --- cut --- > Call trace: > [] __alloc_pages_nodemask+0x4f4/0x7d4 > [] atomic_pool_init+0x60/0x1a4 > [] arm64_dma_init+0x20/0x28 > [] do_one_initcall+0x8c/0x1a4 > [] kernel_init_freeable+0x154/0x1f4 > [] kernel_init+0x10/0xd8 > DMA: failed to allocate 8192 KiB pool for atomic coherent allocation > --- cut --- > and i get even worse faults in the driver. > > I know that it is possible to allocate larger pools by setting > CONFIG_FORCE_MAX_ZONEORDER, > but: > a) This is done on per-platform basis. For ThunderX we used to have a patch > (http://www.spinics.net/lists/arm-kernel/msg415457.html), which never made it > upstream, > because vGIC fixes stopped requiring it at some point. And also we may want > to use the nicvf > driver not only on actual hardware, but also inside virtual machine in KVM. > So do we need to > set CONFIG_FORCE_MAX_ZONEORDER for virt too? And what if at some point qemu > emulates not only > "virt", but some other machine (let's say AMD X-Gene), and we run it on > ThunderX and want to > use nicvf with this model? > b) IMHO it's not good to have a driver which simply does not work without > some obscure option > in boot arguments. > > So, i see several possible ways to solve this: > > 1. Introduce some mechanism which would allow the driver to tell the kernel > that it needs > coherent pool of large size. Can be problematic because the driver can be a > module, and pool > allocation happens early. > 2. Can we use some other method for allocating queues, which would not > require such a huge > coherent pool? > 3. The driver could check value of atomic_pool_size and adjust own memory > requirements > accordingly. This indeed looks like a quick hack, but would at least make > things running > quickly. I have also noticed that CONFIG_DMA_CMA is turned off in my kernel. I guess it was a leftover from old defconfig, because i carry over my .config from version to version. I enabled it and rebuilt the kernel, but in order to get the driver working with this patch i had to also add cma=32M option to kernel arguments. With default of 16M the allocation still fails. Should we add Kconfig dependencies? Kind regards, Pavel Fedin Expert Engineer Samsung Electronics Research center Russia -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 3/6] net: thunderx: Increase transmit queue length
Hello! > Probably you might have to set "coherent_pool" size in bootargs to a > higher value. > Can you please check. I have tried to do this. I was able to enlarge the pool up to 4MB, and still got allocation failures. At 8MB pool preallocation stops working: --- cut --- Call trace: [] __alloc_pages_nodemask+0x4f4/0x7d4 [] atomic_pool_init+0x60/0x1a4 [] arm64_dma_init+0x20/0x28 [] do_one_initcall+0x8c/0x1a4 [] kernel_init_freeable+0x154/0x1f4 [] kernel_init+0x10/0xd8 DMA: failed to allocate 8192 KiB pool for atomic coherent allocation --- cut --- and i get even worse faults in the driver. I know that it is possible to allocate larger pools by setting CONFIG_FORCE_MAX_ZONEORDER, but: a) This is done on per-platform basis. For ThunderX we used to have a patch (http://www.spinics.net/lists/arm-kernel/msg415457.html), which never made it upstream, because vGIC fixes stopped requiring it at some point. And also we may want to use the nicvf driver not only on actual hardware, but also inside virtual machine in KVM. So do we need to set CONFIG_FORCE_MAX_ZONEORDER for virt too? And what if at some point qemu emulates not only "virt", but some other machine (let's say AMD X-Gene), and we run it on ThunderX and want to use nicvf with this model? b) IMHO it's not good to have a driver which simply does not work without some obscure option in boot arguments. So, i see several possible ways to solve this: 1. Introduce some mechanism which would allow the driver to tell the kernel that it needs coherent pool of large size. Can be problematic because the driver can be a module, and pool allocation happens early. 2. Can we use some other method for allocating queues, which would not require such a huge coherent pool? 3. The driver could check value of atomic_pool_size and adjust own memory requirements accordingly. This indeed looks like a quick hack, but would at least make things running quickly. Kind regards, Pavel Fedin Expert Engineer Samsung Electronics Research center Russia -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 3/6] net: thunderx: Increase transmit queue length
Hello! > > swiotlb: coherent allocation failed for device 0002:01:08.4 size=4198400 > > CPU: 2 PID: 3655 Comm: NetworkManager Tainted: GW O4.2.6+ #201 > > Hardware name: Cavium ThunderX CN88XX > > Are you sure 4.2.6 kernel is suitable for backporting this patch aimed > for linux-4.5 ? Why not? It's just a networking driver. And, i also have the same problem on 4.3 running as KVM guest with VFIO. Kind regards, Pavel Fedin Expert Engineer Samsung Electronics Research center Russia -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 3/6] net: thunderx: Increase transmit queue length
Hello! > Probably you might have to set "coherent_pool" size in bootargs to a > higher value. > Can you please check. I have tried to do this. I was able to enlarge the pool up to 4MB, and still got allocation failures. At 8MB pool preallocation stops working: --- cut --- Call trace: [] __alloc_pages_nodemask+0x4f4/0x7d4 [] atomic_pool_init+0x60/0x1a4 [] arm64_dma_init+0x20/0x28 [] do_one_initcall+0x8c/0x1a4 [] kernel_init_freeable+0x154/0x1f4 [] kernel_init+0x10/0xd8 DMA: failed to allocate 8192 KiB pool for atomic coherent allocation --- cut --- and i get even worse faults in the driver. I know that it is possible to allocate larger pools by setting CONFIG_FORCE_MAX_ZONEORDER, but: a) This is done on per-platform basis. For ThunderX we used to have a patch (http://www.spinics.net/lists/arm-kernel/msg415457.html), which never made it upstream, because vGIC fixes stopped requiring it at some point. And also we may want to use the nicvf driver not only on actual hardware, but also inside virtual machine in KVM. So do we need to set CONFIG_FORCE_MAX_ZONEORDER for virt too? And what if at some point qemu emulates not only "virt", but some other machine (let's say AMD X-Gene), and we run it on ThunderX and want to use nicvf with this model? b) IMHO it's not good to have a driver which simply does not work without some obscure option in boot arguments. So, i see several possible ways to solve this: 1. Introduce some mechanism which would allow the driver to tell the kernel that it needs coherent pool of large size. Can be problematic because the driver can be a module, and pool allocation happens early. 2. Can we use some other method for allocating queues, which would not require such a huge coherent pool? 3. The driver could check value of atomic_pool_size and adjust own memory requirements accordingly. This indeed looks like a quick hack, but would at least make things running quickly. Kind regards, Pavel Fedin Expert Engineer Samsung Electronics Research center Russia -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 3/6] net: thunderx: Increase transmit queue length
Hello! > > Probably you might have to set "coherent_pool" size in bootargs to a > > higher value. > > Can you please check. > > I have tried to do this. I was able to enlarge the pool up to 4MB, and still > got allocation > failures. At 8MB pool preallocation stops working: > --- cut --- > Call trace: > [] __alloc_pages_nodemask+0x4f4/0x7d4 > [] atomic_pool_init+0x60/0x1a4 > [] arm64_dma_init+0x20/0x28 > [] do_one_initcall+0x8c/0x1a4 > [] kernel_init_freeable+0x154/0x1f4 > [] kernel_init+0x10/0xd8 > DMA: failed to allocate 8192 KiB pool for atomic coherent allocation > --- cut --- > and i get even worse faults in the driver. > > I know that it is possible to allocate larger pools by setting > CONFIG_FORCE_MAX_ZONEORDER, > but: > a) This is done on per-platform basis. For ThunderX we used to have a patch > (http://www.spinics.net/lists/arm-kernel/msg415457.html), which never made it > upstream, > because vGIC fixes stopped requiring it at some point. And also we may want > to use the nicvf > driver not only on actual hardware, but also inside virtual machine in KVM. > So do we need to > set CONFIG_FORCE_MAX_ZONEORDER for virt too? And what if at some point qemu > emulates not only > "virt", but some other machine (let's say AMD X-Gene), and we run it on > ThunderX and want to > use nicvf with this model? > b) IMHO it's not good to have a driver which simply does not work without > some obscure option > in boot arguments. > > So, i see several possible ways to solve this: > > 1. Introduce some mechanism which would allow the driver to tell the kernel > that it needs > coherent pool of large size. Can be problematic because the driver can be a > module, and pool > allocation happens early. > 2. Can we use some other method for allocating queues, which would not > require such a huge > coherent pool? > 3. The driver could check value of atomic_pool_size and adjust own memory > requirements > accordingly. This indeed looks like a quick hack, but would at least make > things running > quickly. I have also noticed that CONFIG_DMA_CMA is turned off in my kernel. I guess it was a leftover from old defconfig, because i carry over my .config from version to version. I enabled it and rebuilt the kernel, but in order to get the driver working with this patch i had to also add cma=32M option to kernel arguments. With default of 16M the allocation still fails. Should we add Kconfig dependencies? Kind regards, Pavel Fedin Expert Engineer Samsung Electronics Research center Russia -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH v2 4/5] net: thunderx: Switchon carrier only upon interface link up
Just a reminder, we have issue with this one too, which is not addressed yet.
Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia
> -Original Message-
> From: netdev-ow...@vger.kernel.org [mailto:netdev-ow...@vger.kernel.org] On
> Behalf Of Sunil
> Goutham
> Sent: Wednesday, December 02, 2015 1:06 PM
> To: net...@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
> sunil.gout...@caviumnetworks.com; Sunil Goutham
> Subject: [PATCH v2 4/5] net: thunderx: Switchon carrier only upon interface
> link up
>
> From: Sunil Goutham <sgout...@cavium.com>
>
> Call netif_carrier_on() only if interface's link is up. Switching this on
> upon IFF_UP by default, is causing issues with ethernet channel bonding
> in LACP mode. Initial NETDEV_CHANGE notification was being skipped.
>
> Also fixed some issues with link/speed/duplex reporting via ethtool.
>
> Signed-off-by: Sunil Goutham <sgout...@cavium.com>
> ---
> .../net/ethernet/cavium/thunder/nicvf_ethtool.c| 16 +++-
> drivers/net/ethernet/cavium/thunder/nicvf_main.c |4 +---
> drivers/net/ethernet/cavium/thunder/thunder_bgx.c |2 ++
> 3 files changed, 18 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/net/ethernet/cavium/thunder/nicvf_ethtool.c
> b/drivers/net/ethernet/cavium/thunder/nicvf_ethtool.c
> index af54c10..a12b2e3 100644
> --- a/drivers/net/ethernet/cavium/thunder/nicvf_ethtool.c
> +++ b/drivers/net/ethernet/cavium/thunder/nicvf_ethtool.c
> @@ -112,6 +112,13 @@ static int nicvf_get_settings(struct net_device *netdev,
>
> cmd->supported = 0;
> cmd->transceiver = XCVR_EXTERNAL;
> +
> + if (!nic->link_up) {
> + cmd->duplex = DUPLEX_UNKNOWN;
> + ethtool_cmd_speed_set(cmd, SPEED_UNKNOWN);
> + return 0;
> + }
> +
> if (nic->speed <= 1000) {
> cmd->port = PORT_MII;
> cmd->autoneg = AUTONEG_ENABLE;
> @@ -125,6 +132,13 @@ static int nicvf_get_settings(struct net_device *netdev,
> return 0;
> }
>
> +static u32 nicvf_get_link(struct net_device *netdev)
> +{
> + struct nicvf *nic = netdev_priv(netdev);
> +
> + return nic->link_up;
> +}
> +
> static void nicvf_get_drvinfo(struct net_device *netdev,
> struct ethtool_drvinfo *info)
> {
> @@ -660,7 +674,7 @@ static int nicvf_set_channels(struct net_device *dev,
>
> static const struct ethtool_ops nicvf_ethtool_ops = {
> .get_settings = nicvf_get_settings,
> - .get_link = ethtool_op_get_link,
> + .get_link = nicvf_get_link,
> .get_drvinfo= nicvf_get_drvinfo,
> .get_msglevel = nicvf_get_msglevel,
> .set_msglevel = nicvf_set_msglevel,
> diff --git a/drivers/net/ethernet/cavium/thunder/nicvf_main.c
> b/drivers/net/ethernet/cavium/thunder/nicvf_main.c
> index 7f709cb..dde8dc7 100644
> --- a/drivers/net/ethernet/cavium/thunder/nicvf_main.c
> +++ b/drivers/net/ethernet/cavium/thunder/nicvf_main.c
> @@ -1057,6 +1057,7 @@ int nicvf_stop(struct net_device *netdev)
>
> netif_carrier_off(netdev);
> netif_tx_stop_all_queues(nic->netdev);
> + nic->link_up = false;
>
> /* Teardown secondary qsets first */
> if (!nic->sqs_mode) {
> @@ -1211,9 +1212,6 @@ int nicvf_open(struct net_device *netdev)
> nic->drv_stats.txq_stop = 0;
> nic->drv_stats.txq_wake = 0;
>
> - netif_carrier_on(netdev);
> - netif_tx_start_all_queues(netdev);
> -
> return 0;
> cleanup:
> nicvf_disable_intr(nic, NICVF_INTR_MBOX, 0);
> diff --git a/drivers/net/ethernet/cavium/thunder/thunder_bgx.c
> b/drivers/net/ethernet/cavium/thunder/thunder_bgx.c
> index 6534b73..d77e41a 100644
> --- a/drivers/net/ethernet/cavium/thunder/thunder_bgx.c
> +++ b/drivers/net/ethernet/cavium/thunder/thunder_bgx.c
> @@ -612,6 +612,8 @@ static void bgx_poll_for_link(struct work_struct *work)
> lmac->last_duplex = 1;
> } else {
> lmac->link_up = 0;
> + lmac->last_speed = SPEED_UNKNOWN;
> + lmac->last_duplex = DUPLEX_UNKNOWN;
> }
>
> if (lmac->last_link != lmac->link_up) {
> --
> 1.7.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 3/6] net: thunderx: Increase transmit queue length
Hello! > > swiotlb: coherent allocation failed for device 0002:01:08.4 size=4198400 > > CPU: 2 PID: 3655 Comm: NetworkManager Tainted: GW O4.2.6+ #201 > > Hardware name: Cavium ThunderX CN88XX > > Are you sure 4.2.6 kernel is suitable for backporting this patch aimed > for linux-4.5 ? Why not? It's just a networking driver. And, i also have the same problem on 4.3 running as KVM guest with VFIO. Kind regards, Pavel Fedin Expert Engineer Samsung Electronics Research center Russia -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 3/6] net: thunderx: Increase transmit queue length
Hello! > > So, i see several possible ways to solve this: > > > > 1. Introduce some mechanism which would allow the driver to tell the kernel > > that it needs > > coherent pool of large size. Can be problematic because the driver can be a > > module, and pool > > allocation happens early. > > 2. Can we use some other method for allocating queues, which would not > > require such a huge > > coherent pool? > > 3. The driver could check value of atomic_pool_size and adjust own memory > > requirements > > accordingly. This indeed looks like a quick hack, but would at least make > > things running > > quickly. > > I have also noticed that CONFIG_DMA_CMA is turned off in my kernel. I guess > it was a leftover > from old defconfig, because i carry over my .config from version to version. > I enabled it and > rebuilt the kernel, but in order to get the driver working with this patch i > had to also add > cma=32M option to kernel arguments. With default of 16M the allocation still > fails. > Should we add Kconfig dependencies? After getting it working in guest i tried to apply it to host. With total of 128 virtual functions (= 128 interfaces) it does not work at all. Even after bumping cma region size to insane value of 2GB more than half of interfaces still failed to allocate queues. And after setting cma=3G i could not mount my rootfs. So, absolute NAK, unfortunately. Kind regards, Pavel Fedin Expert Engineer Samsung Electronics Research center Russia -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH v2 4/5] net: thunderx: Switchon carrier only upon interface link up
Hello again! > Subject: RE: [PATCH v2 4/5] net: thunderx: Switchon carrier only upon > interface link up > > Just a reminder, we have issue with this one too, which is not addressed yet. I have examined the problem thoroughly and discovered that it is a problem with experimental BGX driver patches on my 4.2 host kernel build. It fails to send NIC_MBOX_MSG_BGX_LINK_CHANGE, so nothing works. I have retested this series on top of 4.3 running on ThunderX. It has good BGX driver and everything works fine. Therefore, the whole series can be safely applied and... Tested-by: Pavel Fedin <p.fe...@samsung.com> Kind regards, Pavel Fedin Expert Engineer Samsung Electronics Research center Russia -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 3/6] net: thunderx: Increase transmit queue length
Hello! > >After getting it working in guest i tried to apply it to host. With total of > >128 virtual > functions (= 128 interfaces) it does not work at all. > > Even after bumping cma region size to insane value of 2GB more than half of > > interfaces still > failed to allocate queues. > > And after setting cma=3G i could not mount my rootfs. > > Here what you are saying is half of the interfaces were initialized > succesfully and rest didn't. After setting cma=2G. With default setting of 16M none of them initialized. > So this issue is not something which is introduced by this patch. Before this patch all my interfaces were working. I would say the problem with your patch is that it introduces memory requirements which cannot be satisfied by the platform. It's combination of several factors which stops the thing from working, not a single factor. Using dma_alloc_coherent() is not all wrong by itself, of course. Perhaps you did some tricks with your configuration, which make it working. Then, i guess, you should have at least described them in commit message of your patch. Or describe all dependencies in KConfig of your driver, which is better. Or, if the platform needs some very special defconfig, add it to arch/arm64/configs (however, i guess, the goal of ARM64 Linux is to run on all possible hardware, so this would not be good from maintainers' POV). Sorry, but this is all i can say. In previous messages i have already suggested several ways to solve the problem (too lazy to quite here, 4 IIRC), or you can suggest your own one and let us test it, or you can even stick to "It works for me, i am the only right guy in the world, and i don't care if it doesn't work for you" position and let David decide who of us is right (and he already did that once). Basically, here is what i did: i took kernel 4.2, added ThunderX PCI drivers to it (they were posted but NAKed those days back, there's some lazy progress on them currently), added necessary errata patches (also posted on lists, all merged into 4.4), took defconfig, adjusted it according to my needs, and this is what i'm running on my board and this is what i'm using for development. If you point me at what i'm doing wrong way, i'll be glad to accept this. I'm over. Kind regards, Pavel Fedin Expert Engineer Samsung Electronics Research center Russia -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 5/6] net: thunderx: Switchon carrier only upon interface link up
Hello!
This one causes the network to stop working on Fedora 21. Probably has to do
with NetworkManager, which sees something unexpected.
IP address is never set up and connection is never activated, despite it has UP
flag.
Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia
> -Original Message-
> From: netdev-ow...@vger.kernel.org [mailto:netdev-ow...@vger.kernel.org] On
> Behalf Of Sunil
> Goutham
> Sent: Tuesday, December 01, 2015 12:14 PM
> To: net...@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
> sunil.gout...@caviumnetworks.com; Sunil Goutham
> Subject: [PATCH 5/6] net: thunderx: Switchon carrier only upon interface link
> up
>
> From: Sunil Goutham
>
> Call netif_carrier_on() only if interface's link is up. Switching this on
> upon IFF_UP by default, is causing issues with ethernet channel bonding
> in LACP mode. Initial NETDEV_CHANGE notification was being skipped.
>
> Also fixed some issues with link/speed/duplex reporting via ethtool.
>
> Signed-off-by: Sunil Goutham
> ---
> .../net/ethernet/cavium/thunder/nicvf_ethtool.c| 16 +++-
> drivers/net/ethernet/cavium/thunder/nicvf_main.c |4 +---
> drivers/net/ethernet/cavium/thunder/thunder_bgx.c |2 ++
> 3 files changed, 18 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/net/ethernet/cavium/thunder/nicvf_ethtool.c
> b/drivers/net/ethernet/cavium/thunder/nicvf_ethtool.c
> index af54c10..a12b2e3 100644
> --- a/drivers/net/ethernet/cavium/thunder/nicvf_ethtool.c
> +++ b/drivers/net/ethernet/cavium/thunder/nicvf_ethtool.c
> @@ -112,6 +112,13 @@ static int nicvf_get_settings(struct net_device *netdev,
>
> cmd->supported = 0;
> cmd->transceiver = XCVR_EXTERNAL;
> +
> + if (!nic->link_up) {
> + cmd->duplex = DUPLEX_UNKNOWN;
> + ethtool_cmd_speed_set(cmd, SPEED_UNKNOWN);
> + return 0;
> + }
> +
> if (nic->speed <= 1000) {
> cmd->port = PORT_MII;
> cmd->autoneg = AUTONEG_ENABLE;
> @@ -125,6 +132,13 @@ static int nicvf_get_settings(struct net_device *netdev,
> return 0;
> }
>
> +static u32 nicvf_get_link(struct net_device *netdev)
> +{
> + struct nicvf *nic = netdev_priv(netdev);
> +
> + return nic->link_up;
> +}
> +
> static void nicvf_get_drvinfo(struct net_device *netdev,
> struct ethtool_drvinfo *info)
> {
> @@ -660,7 +674,7 @@ static int nicvf_set_channels(struct net_device *dev,
>
> static const struct ethtool_ops nicvf_ethtool_ops = {
> .get_settings = nicvf_get_settings,
> - .get_link = ethtool_op_get_link,
> + .get_link = nicvf_get_link,
> .get_drvinfo= nicvf_get_drvinfo,
> .get_msglevel = nicvf_get_msglevel,
> .set_msglevel = nicvf_set_msglevel,
> diff --git a/drivers/net/ethernet/cavium/thunder/nicvf_main.c
> b/drivers/net/ethernet/cavium/thunder/nicvf_main.c
> index 7f709cb..dde8dc7 100644
> --- a/drivers/net/ethernet/cavium/thunder/nicvf_main.c
> +++ b/drivers/net/ethernet/cavium/thunder/nicvf_main.c
> @@ -1057,6 +1057,7 @@ int nicvf_stop(struct net_device *netdev)
>
> netif_carrier_off(netdev);
> netif_tx_stop_all_queues(nic->netdev);
> + nic->link_up = false;
>
> /* Teardown secondary qsets first */
> if (!nic->sqs_mode) {
> @@ -1211,9 +1212,6 @@ int nicvf_open(struct net_device *netdev)
> nic->drv_stats.txq_stop = 0;
> nic->drv_stats.txq_wake = 0;
>
> - netif_carrier_on(netdev);
> - netif_tx_start_all_queues(netdev);
> -
> return 0;
> cleanup:
> nicvf_disable_intr(nic, NICVF_INTR_MBOX, 0);
> diff --git a/drivers/net/ethernet/cavium/thunder/thunder_bgx.c
> b/drivers/net/ethernet/cavium/thunder/thunder_bgx.c
> index 2076ac3..d9f27ad 100644
> --- a/drivers/net/ethernet/cavium/thunder/thunder_bgx.c
> +++ b/drivers/net/ethernet/cavium/thunder/thunder_bgx.c
> @@ -612,6 +612,8 @@ static void bgx_poll_for_link(struct work_struct *work)
> lmac->last_duplex = 1;
> } else {
> lmac->link_up = 0;
> + lmac->last_speed = SPEED_UNKNOWN;
> + lmac->last_duplex = DUPLEX_UNKNOWN;
> }
>
> if (lmac->last_link != lmac->link_up) {
> --
> 1.7.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 3/6] net: thunderx: Increase transmit queue length
Hello! This one breaks networking on my machine: --- cut --- swiotlb: coherent allocation failed for device 0002:01:08.4 size=4198400 CPU: 2 PID: 3655 Comm: NetworkManager Tainted: GW O4.2.6+ #201 Hardware name: Cavium ThunderX CN88XX board (DT) Call trace: [] dump_backtrace+0x0/0x124 [] show_stack+0x14/0x1c [] dump_stack+0x88/0xc8 [] swiotlb_alloc_coherent+0x150/0x168 [] __dma_alloc+0x58/0x1e8 [] nicvf_alloc_q_desc_mem.isra.14+0xc0/0xdc [] nicvf_config_data_transfer+0x448/0x728 [] nicvf_open+0x184/0x994 [] __dev_open+0xb4/0x120 [] __dev_change_flags+0x8c/0x150 [] dev_change_flags+0x20/0x5c [] do_setlink+0x27c/0x8e0 [] rtnl_newlink+0x4b4/0x6c4 [] rtnetlink_rcv_msg+0x90/0x22c [] netlink_rcv_skb+0xd8/0x100 [] rtnetlink_rcv+0x30/0x40 [] netlink_unicast+0x158/0x1f8 [] netlink_sendmsg+0x324/0x380 [] sock_sendmsg+0x18/0x58 [] ___sys_sendmsg+0x254/0x264 [] __sys_sendmsg+0x40/0x84 [] SyS_sendmsg+0x10/0x20 thunder-nicvf 0002:01:08.4 enP2p1s8f4: Failed to alloc/config VF's QSet resources --- cut --- And none of interfaces work after this. Reverting this patch helps. Kind regards, Pavel Fedin Expert Engineer Samsung Electronics Research center Russia > -Original Message- > From: netdev-ow...@vger.kernel.org [mailto:netdev-ow...@vger.kernel.org] On > Behalf Of Sunil > Goutham > Sent: Tuesday, December 01, 2015 12:14 PM > To: net...@vger.kernel.org > Cc: linux-kernel@vger.kernel.org; linux-arm-ker...@lists.infradead.org; > sunil.gout...@caviumnetworks.com; Sunil Goutham > Subject: [PATCH 3/6] net: thunderx: Increase transmit queue length > > From: Sunil Goutham > > Under high transmit rates and with TSO enabled observing fluctuations > in TX performance. Seen especially with iperf3 application. > > Since TSO is taken care at driver level, with 64KB of TSO packets > and when window size is also high the rate at which CPU fills in > transmit descriptors is much higher than what HW is able to process. > Each 64KB TSO packet occupies gets segmented to ~43 1500 byte MTU packets > and occupies ~130 descriptors. Hence increasing transmit queue size. > > Signed-off-by: Sunil Goutham > --- > drivers/net/ethernet/cavium/thunder/nicvf_queues.h |4 ++-- > 1 files changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/net/ethernet/cavium/thunder/nicvf_queues.h > b/drivers/net/ethernet/cavium/thunder/nicvf_queues.h > index fb4957d..b1e93a9 100644 > --- a/drivers/net/ethernet/cavium/thunder/nicvf_queues.h > +++ b/drivers/net/ethernet/cavium/thunder/nicvf_queues.h > @@ -62,7 +62,7 @@ > #define SND_QUEUE_CNT8 > #define CMP_QUEUE_CNT8 /* Max of RCV and SND qcount */ > > -#define SND_QSIZESND_QUEUE_SIZE2 > +#define SND_QSIZESND_QUEUE_SIZE3 > #define SND_QUEUE_LEN(1ULL << (SND_QSIZE + 10)) > #define MAX_SND_QUEUE_LEN(1ULL << (SND_QUEUE_SIZE6 + 10)) > #define SND_QUEUE_THRESH 2ULL > @@ -73,7 +73,7 @@ > /* Keep CQ and SQ sizes same, if timestamping > * is enabled this equation will change. > */ > -#define CMP_QSIZECMP_QUEUE_SIZE2 > +#define CMP_QSIZECMP_QUEUE_SIZE3 > #define CMP_QUEUE_LEN(1ULL << (CMP_QSIZE + 10)) > #define CMP_QUEUE_CQE_THRESH 0 > #define CMP_QUEUE_TIMER_THRESH 220 /* 10usec */ > -- > 1.7.1 > > -- > To unsubscribe from this list: send the line "unsubscribe netdev" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 5/6] net: thunderx: Switchon carrier only upon interface link up
Hello!
This one causes the network to stop working on Fedora 21. Probably has to do
with NetworkManager, which sees something unexpected.
IP address is never set up and connection is never activated, despite it has UP
flag.
Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia
> -Original Message-
> From: netdev-ow...@vger.kernel.org [mailto:netdev-ow...@vger.kernel.org] On
> Behalf Of Sunil
> Goutham
> Sent: Tuesday, December 01, 2015 12:14 PM
> To: net...@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
> sunil.gout...@caviumnetworks.com; Sunil Goutham
> Subject: [PATCH 5/6] net: thunderx: Switchon carrier only upon interface link
> up
>
> From: Sunil Goutham <sgout...@cavium.com>
>
> Call netif_carrier_on() only if interface's link is up. Switching this on
> upon IFF_UP by default, is causing issues with ethernet channel bonding
> in LACP mode. Initial NETDEV_CHANGE notification was being skipped.
>
> Also fixed some issues with link/speed/duplex reporting via ethtool.
>
> Signed-off-by: Sunil Goutham <sgout...@cavium.com>
> ---
> .../net/ethernet/cavium/thunder/nicvf_ethtool.c| 16 +++-
> drivers/net/ethernet/cavium/thunder/nicvf_main.c |4 +---
> drivers/net/ethernet/cavium/thunder/thunder_bgx.c |2 ++
> 3 files changed, 18 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/net/ethernet/cavium/thunder/nicvf_ethtool.c
> b/drivers/net/ethernet/cavium/thunder/nicvf_ethtool.c
> index af54c10..a12b2e3 100644
> --- a/drivers/net/ethernet/cavium/thunder/nicvf_ethtool.c
> +++ b/drivers/net/ethernet/cavium/thunder/nicvf_ethtool.c
> @@ -112,6 +112,13 @@ static int nicvf_get_settings(struct net_device *netdev,
>
> cmd->supported = 0;
> cmd->transceiver = XCVR_EXTERNAL;
> +
> + if (!nic->link_up) {
> + cmd->duplex = DUPLEX_UNKNOWN;
> + ethtool_cmd_speed_set(cmd, SPEED_UNKNOWN);
> + return 0;
> + }
> +
> if (nic->speed <= 1000) {
> cmd->port = PORT_MII;
> cmd->autoneg = AUTONEG_ENABLE;
> @@ -125,6 +132,13 @@ static int nicvf_get_settings(struct net_device *netdev,
> return 0;
> }
>
> +static u32 nicvf_get_link(struct net_device *netdev)
> +{
> + struct nicvf *nic = netdev_priv(netdev);
> +
> + return nic->link_up;
> +}
> +
> static void nicvf_get_drvinfo(struct net_device *netdev,
> struct ethtool_drvinfo *info)
> {
> @@ -660,7 +674,7 @@ static int nicvf_set_channels(struct net_device *dev,
>
> static const struct ethtool_ops nicvf_ethtool_ops = {
> .get_settings = nicvf_get_settings,
> - .get_link = ethtool_op_get_link,
> + .get_link = nicvf_get_link,
> .get_drvinfo= nicvf_get_drvinfo,
> .get_msglevel = nicvf_get_msglevel,
> .set_msglevel = nicvf_set_msglevel,
> diff --git a/drivers/net/ethernet/cavium/thunder/nicvf_main.c
> b/drivers/net/ethernet/cavium/thunder/nicvf_main.c
> index 7f709cb..dde8dc7 100644
> --- a/drivers/net/ethernet/cavium/thunder/nicvf_main.c
> +++ b/drivers/net/ethernet/cavium/thunder/nicvf_main.c
> @@ -1057,6 +1057,7 @@ int nicvf_stop(struct net_device *netdev)
>
> netif_carrier_off(netdev);
> netif_tx_stop_all_queues(nic->netdev);
> + nic->link_up = false;
>
> /* Teardown secondary qsets first */
> if (!nic->sqs_mode) {
> @@ -1211,9 +1212,6 @@ int nicvf_open(struct net_device *netdev)
> nic->drv_stats.txq_stop = 0;
> nic->drv_stats.txq_wake = 0;
>
> - netif_carrier_on(netdev);
> - netif_tx_start_all_queues(netdev);
> -
> return 0;
> cleanup:
> nicvf_disable_intr(nic, NICVF_INTR_MBOX, 0);
> diff --git a/drivers/net/ethernet/cavium/thunder/thunder_bgx.c
> b/drivers/net/ethernet/cavium/thunder/thunder_bgx.c
> index 2076ac3..d9f27ad 100644
> --- a/drivers/net/ethernet/cavium/thunder/thunder_bgx.c
> +++ b/drivers/net/ethernet/cavium/thunder/thunder_bgx.c
> @@ -612,6 +612,8 @@ static void bgx_poll_for_link(struct work_struct *work)
> lmac->last_duplex = 1;
> } else {
> lmac->link_up = 0;
> + lmac->last_speed = SPEED_UNKNOWN;
> + lmac->last_duplex = DUPLEX_UNKNOWN;
> }
>
> if (lmac->last_link != lmac->link_up) {
> --
> 1.7.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 3/6] net: thunderx: Increase transmit queue length
Hello! This one breaks networking on my machine: --- cut --- swiotlb: coherent allocation failed for device 0002:01:08.4 size=4198400 CPU: 2 PID: 3655 Comm: NetworkManager Tainted: GW O4.2.6+ #201 Hardware name: Cavium ThunderX CN88XX board (DT) Call trace: [] dump_backtrace+0x0/0x124 [] show_stack+0x14/0x1c [] dump_stack+0x88/0xc8 [] swiotlb_alloc_coherent+0x150/0x168 [] __dma_alloc+0x58/0x1e8 [] nicvf_alloc_q_desc_mem.isra.14+0xc0/0xdc [] nicvf_config_data_transfer+0x448/0x728 [] nicvf_open+0x184/0x994 [] __dev_open+0xb4/0x120 [] __dev_change_flags+0x8c/0x150 [] dev_change_flags+0x20/0x5c [] do_setlink+0x27c/0x8e0 [] rtnl_newlink+0x4b4/0x6c4 [] rtnetlink_rcv_msg+0x90/0x22c [] netlink_rcv_skb+0xd8/0x100 [] rtnetlink_rcv+0x30/0x40 [] netlink_unicast+0x158/0x1f8 [] netlink_sendmsg+0x324/0x380 [] sock_sendmsg+0x18/0x58 [] ___sys_sendmsg+0x254/0x264 [] __sys_sendmsg+0x40/0x84 [] SyS_sendmsg+0x10/0x20 thunder-nicvf 0002:01:08.4 enP2p1s8f4: Failed to alloc/config VF's QSet resources --- cut --- And none of interfaces work after this. Reverting this patch helps. Kind regards, Pavel Fedin Expert Engineer Samsung Electronics Research center Russia > -Original Message- > From: netdev-ow...@vger.kernel.org [mailto:netdev-ow...@vger.kernel.org] On > Behalf Of Sunil > Goutham > Sent: Tuesday, December 01, 2015 12:14 PM > To: net...@vger.kernel.org > Cc: linux-kernel@vger.kernel.org; linux-arm-ker...@lists.infradead.org; > sunil.gout...@caviumnetworks.com; Sunil Goutham > Subject: [PATCH 3/6] net: thunderx: Increase transmit queue length > > From: Sunil Goutham <sgout...@cavium.com> > > Under high transmit rates and with TSO enabled observing fluctuations > in TX performance. Seen especially with iperf3 application. > > Since TSO is taken care at driver level, with 64KB of TSO packets > and when window size is also high the rate at which CPU fills in > transmit descriptors is much higher than what HW is able to process. > Each 64KB TSO packet occupies gets segmented to ~43 1500 byte MTU packets > and occupies ~130 descriptors. Hence increasing transmit queue size. > > Signed-off-by: Sunil Goutham <sgout...@cavium.com> > --- > drivers/net/ethernet/cavium/thunder/nicvf_queues.h |4 ++-- > 1 files changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/net/ethernet/cavium/thunder/nicvf_queues.h > b/drivers/net/ethernet/cavium/thunder/nicvf_queues.h > index fb4957d..b1e93a9 100644 > --- a/drivers/net/ethernet/cavium/thunder/nicvf_queues.h > +++ b/drivers/net/ethernet/cavium/thunder/nicvf_queues.h > @@ -62,7 +62,7 @@ > #define SND_QUEUE_CNT8 > #define CMP_QUEUE_CNT8 /* Max of RCV and SND qcount */ > > -#define SND_QSIZESND_QUEUE_SIZE2 > +#define SND_QSIZESND_QUEUE_SIZE3 > #define SND_QUEUE_LEN(1ULL << (SND_QSIZE + 10)) > #define MAX_SND_QUEUE_LEN(1ULL << (SND_QUEUE_SIZE6 + 10)) > #define SND_QUEUE_THRESH 2ULL > @@ -73,7 +73,7 @@ > /* Keep CQ and SQ sizes same, if timestamping > * is enabled this equation will change. > */ > -#define CMP_QSIZECMP_QUEUE_SIZE2 > +#define CMP_QSIZECMP_QUEUE_SIZE3 > #define CMP_QUEUE_LEN(1ULL << (CMP_QSIZE + 10)) > #define CMP_QUEUE_CQE_THRESH 0 > #define CMP_QUEUE_TIMER_THRESH 220 /* 10usec */ > -- > 1.7.1 > > -- > To unsubscribe from this list: send the line "unsubscribe netdev" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v9 3/4] drivers: exynos-srom: Add support for bank configuration
Implement handling properties in subnodes and adding child devices to the
system. Child devices will not be added if configuration fails.
Since the driver now does more than suspend-resume support, dependency on
CONFIG_PM is removed.
Signed-off-by: Pavel Fedin
Reviewed-by: Krzysztof Kozlowski
---
arch/arm/mach-exynos/Kconfig | 2 +-
drivers/soc/samsung/Kconfig | 2 +-
drivers/soc/samsung/exynos-srom.c | 61 +--
3 files changed, 61 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig
index 83c85f5..c22dc42 100644
--- a/arch/arm/mach-exynos/Kconfig
+++ b/arch/arm/mach-exynos/Kconfig
@@ -16,7 +16,7 @@ menuconfig ARCH_EXYNOS
select ARM_GIC
select COMMON_CLK_SAMSUNG
select EXYNOS_THERMAL
- select EXYNOS_SROM if PM
+ select EXYNOS_SROM
select HAVE_ARM_SCU if SMP
select HAVE_S3C2410_I2C if I2C
select HAVE_S3C2410_WATCHDOG if WATCHDOG
diff --git a/drivers/soc/samsung/Kconfig b/drivers/soc/samsung/Kconfig
index 2833b5b..ea4bc2a 100644
--- a/drivers/soc/samsung/Kconfig
+++ b/drivers/soc/samsung/Kconfig
@@ -8,6 +8,6 @@ config SOC_SAMSUNG
config EXYNOS_SROM
bool
- depends on ARM && ARCH_EXYNOS && PM
+ depends on ARM && ARCH_EXYNOS
endmenu
diff --git a/drivers/soc/samsung/exynos-srom.c
b/drivers/soc/samsung/exynos-srom.c
index 57a232d..a4cf547 100644
--- a/drivers/soc/samsung/exynos-srom.c
+++ b/drivers/soc/samsung/exynos-srom.c
@@ -14,6 +14,7 @@
#include
#include
#include
+#include
#include
#include
@@ -67,11 +68,51 @@ static struct exynos_srom_reg_dump
*exynos_srom_alloc_reg_dump(
return rd;
}
+static int exynos_srom_configure_bank(struct exynos_srom *srom,
+ struct device_node *np)
+{
+ u32 bank, width, pmc;
+ u32 timing[6];
+ u32 cs, bw;
+
+ if (of_property_read_u32(np, "reg", ))
+ return -EINVAL;
+ if (of_property_read_u32(np, "reg-io-width", ))
+ width = 1;
+ if (of_property_read_u32(np, "samsung,srom-page-mode", ))
+ pmc = 0;
+ if (of_property_read_u32_array(np, "samsung,srom-timing", timing,
+ ARRAY_SIZE(timing)))
+ return -EINVAL;
+
+ bank *= 4; /* Convert bank into shift/offset */
+
+ cs = 1 << EXYNOS_SROM_BW__BYTEENABLE__SHIFT;
+ if (width == 2)
+ cs |= 1 << EXYNOS_SROM_BW__DATAWIDTH__SHIFT;
+
+ bw = __raw_readl(srom->reg_base + EXYNOS_SROM_BW);
+ bw = (bw & ~(EXYNOS_SROM_BW__CS_MASK << bank)) | (cs << bank);
+ __raw_writel(bw, srom->reg_base + EXYNOS_SROM_BW);
+
+ __raw_writel((pmc << EXYNOS_SROM_BCX__PMC__SHIFT) |
+ (timing[0] << EXYNOS_SROM_BCX__TACP__SHIFT) |
+ (timing[1] << EXYNOS_SROM_BCX__TCAH__SHIFT) |
+ (timing[2] << EXYNOS_SROM_BCX__TCOH__SHIFT) |
+ (timing[3] << EXYNOS_SROM_BCX__TACC__SHIFT) |
+ (timing[4] << EXYNOS_SROM_BCX__TCOS__SHIFT) |
+ (timing[5] << EXYNOS_SROM_BCX__TACS__SHIFT),
+ srom->reg_base + EXYNOS_SROM_BC0 + bank);
+
+ return 0;
+}
+
static int exynos_srom_probe(struct platform_device *pdev)
{
- struct device_node *np;
+ struct device_node *np, *child;
struct exynos_srom *srom;
struct device *dev = >dev;
+ bool bad_bank_config = false;
np = dev->of_node;
if (!np) {
@@ -100,7 +141,23 @@ static int exynos_srom_probe(struct platform_device *pdev)
return -ENOMEM;
}
- return 0;
+ for_each_child_of_node(np, child) {
+ if (exynos_srom_configure_bank(srom, child)) {
+ dev_err(dev,
+ "Could not decode bank configuration for %s\n",
+ child->name);
+ bad_bank_config = true;
+ }
+ }
+
+ /*
+* If any bank failed to configure, we still provide suspend/resume,
+* but do not probe child devices
+*/
+ if (bad_bank_config)
+ return 0;
+
+ return of_platform_populate(np, NULL, NULL, dev);
}
static int exynos_srom_remove(struct platform_device *pdev)
--
2.4.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v9 2/4] ARM: dts: Add SROMc to Exynos 5410
This machine uses own SoC device tree file, add missing part.
Signed-off-by: Pavel Fedin
Reviewed-by: Krzysztof Kozlowski
---
arch/arm/boot/dts/exynos5410.dtsi | 5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5410.dtsi
b/arch/arm/boot/dts/exynos5410.dtsi
index 4603356..e2b58f8 100644
--- a/arch/arm/boot/dts/exynos5410.dtsi
+++ b/arch/arm/boot/dts/exynos5410.dtsi
@@ -101,6 +101,11 @@
reg = <0x1000 0x100>;
};
+ sromc: sromc@1225 {
+ compatible = "samsung,exynos-srom";
+ reg = <0x1225 0x14>;
+ };
+
pmu_system_controller: system-controller@1004 {
compatible = "samsung,exynos5410-pmu", "syscon";
reg = <0x1004 0x5000>;
--
2.4.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v9 4/4] ARM: dts: Add Ethernet chip to SMDK5410
The chip is smsc9115, connected via SROMc bank 3. Additionally, some GPIO
initialization is required.
Signed-off-by: Pavel Fedin
Reviewed-by: Krzysztof Kozlowski
---
arch/arm/boot/dts/exynos5410-smdk5410.dts | 41 +++
arch/arm/boot/dts/exynos5410.dtsi | 6 +
2 files changed, 47 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5410-smdk5410.dts
b/arch/arm/boot/dts/exynos5410-smdk5410.dts
index cebeaab..a731fbe 100644
--- a/arch/arm/boot/dts/exynos5410-smdk5410.dts
+++ b/arch/arm/boot/dts/exynos5410-smdk5410.dts
@@ -11,6 +11,7 @@
/dts-v1/;
#include "exynos5410.dtsi"
+#include
/ {
model = "Samsung SMDK5410 board based on EXYNOS5410";
compatible = "samsung,smdk5410", "samsung,exynos5410",
"samsung,exynos5";
@@ -61,6 +62,46 @@
disable-wp;
};
+_0 {
+ srom_ctl: srom-ctl {
+ samsung,pins = "gpy0-3", "gpy0-4", "gpy0-5",
+ "gpy1-0", "gpy1-1", "gpy1-2", "gpy1-3";
+ samsung,pin-function = <2>;
+ samsung,pin-drv = <0>;
+ };
+
+ srom_ebi: srom-ebi {
+ samsung,pins = "gpy3-0", "gpy3-1", "gpy3-2", "gpy3-3",
+ "gpy3-4", "gpy3-5", "gpy3-6", "gpy3-7",
+ "gpy5-0", "gpy5-1", "gpy5-2", "gpy5-3",
+ "gpy5-4", "gpy5-5", "gpy5-6", "gpy5-7",
+ "gpy6-0", "gpy6-1", "gpy6-2", "gpy6-3",
+ "gpy6-4", "gpy6-5", "gpy6-6", "gpy6-7";
+ samsung,pin-function = <2>;
+ samsung,pin-pud = <3>;
+ samsung,pin-drv = <0>;
+ };
+};
+
+ {
+ pinctrl-names = "default";
+ pinctrl-0 = <_ctl>, <_ebi>;
+
+ ethernet@3,0 {
+ compatible = "smsc,lan9115";
+ reg = <3 0 0x1>;
+ phy-mode = "mii";
+ interrupt-parent = <>;
+ interrupts = <5 IRQ_TYPE_LEVEL_LOW>;
+ reg-io-width = <2>;
+ smsc,irq-push-pull;
+ smsc,force-internal-phy;
+
+ samsung,srom-page-mode = <1>;
+ samsung,srom-timing = <9 12 1 9 1 1>;
+ };
+};
+
{
status = "okay";
};
diff --git a/arch/arm/boot/dts/exynos5410.dtsi
b/arch/arm/boot/dts/exynos5410.dtsi
index e2b58f8..9cfb814 100644
--- a/arch/arm/boot/dts/exynos5410.dtsi
+++ b/arch/arm/boot/dts/exynos5410.dtsi
@@ -104,6 +104,12 @@
sromc: sromc@1225 {
compatible = "samsung,exynos-srom";
reg = <0x1225 0x14>;
+ #address-cells = <2>;
+ #size-cells = <1>;
+ ranges = <0 0 0x0400 0x2
+ 1 0 0x0500 0x2
+ 2 0 0x0600 0x2
+ 3 0 0x0700 0x2>;
};
pmu_system_controller: system-controller@1004 {
--
2.4.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v9 1/4] Documentation: dt-bindings: Describe SROMc configuration
Add documentation for new subnode properties, allowing bank configuration.
Based on u-boot implementation, but heavily reworked.
Also, fix size of SROMc mapping in the example.
Signed-off-by: Pavel Fedin
Reviewed-by: Krzysztof Kozlowski
Acked-by: Rob Herring
---
.../bindings/arm/samsung/exynos-srom.txt | 73 +-
1 file changed, 71 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/arm/samsung/exynos-srom.txt
b/Documentation/devicetree/bindings/arm/samsung/exynos-srom.txt
index 33886d5..e5c18df 100644
--- a/Documentation/devicetree/bindings/arm/samsung/exynos-srom.txt
+++ b/Documentation/devicetree/bindings/arm/samsung/exynos-srom.txt
@@ -5,8 +5,77 @@ Required properties:
- reg: offset and length of the register set
-Example:
+Optional properties:
+The SROM controller can be used to attach external peripherals. In this case
+extra properties, describing the bus behind it, should be specified as below:
+
+- #address-cells: Must be set to 2 to allow device address translation.
+ Address is specified as (bank#, offset).
+
+- #size-cells: Must be set to 1 to allow device size passing
+
+- ranges: Must be set up to reflect the memory layout with four integer values
+ per bank:
+0
+
+Sub-nodes:
+The actual device nodes should be added as subnodes to the SROMc node. These
+subnodes, except regular device specification, should contain the following
+properties, describing configuration of the relevant SROM bank:
+
+Required properties:
+- reg: bank number, base address (relative to start of the bank) and size of
+ the memory mapped for the device. Note that base address will be
+ typically 0 as this is the start of the bank.
+
+- samsung,srom-timing : array of 6 integers, specifying bank timings in the
+following order: Tacp, Tcah, Tcoh, Tacc, Tcos, Tacs.
+Each value is specified in cycles and has the following
+meaning and valid range:
+Tacp : Page mode access cycle at Page mode (0 - 15)
+Tcah : Address holding time after CSn (0 - 15)
+Tcoh : Chip selection hold on OEn (0 - 15)
+Tacc : Access cycle (0 - 31, the actual time is N + 1)
+Tcos : Chip selection set-up before OEn (0 - 15)
+Tacs : Address set-up before CSn (0 - 15)
+
+Optional properties:
+- reg-io-width : data width in bytes (1 or 2). If omitted, default of 1 is
used.
+
+- samsung,srom-page-mode : page mode configuration for the bank:
+ 0 - normal (one data)
+ 1 - four data
+ If omitted, default of 0 is used.
+
+Example: basic definition, no banks are configured
+ sromc@1257 {
+ compatible = "samsung,exynos-srom";
+ reg = <0x1257 0x14>;
+ };
+
+Example: SROMc with SMSC911x ethernet chip on bank 3
sromc@1257 {
+ #address-cells = <2>;
+ #size-cells = <1>;
+ ranges = <0 0 0x0400 0x2 // Bank0
+ 1 0 0x0500 0x2 // Bank1
+ 2 0 0x0600 0x2 // Bank2
+ 3 0 0x0700 0x2>; // Bank3
+
compatible = "samsung,exynos-srom";
- reg = <0x1257 0x10>;
+ reg = <0x1257 0x14>;
+
+ ethernet@3,0 {
+ compatible = "smsc,lan9115";
+ reg = <3 0 0x1>; // Bank 3, offset = 0
+ phy-mode = "mii";
+ interrupt-parent = <>;
+ interrupts = <5 8>;
+ reg-io-width = <2>;
+ smsc,irq-push-pull;
+ smsc,force-internal-phy;
+
+ samsung,srom-page-mode = <1>;
+ samsung,srom-timing = <9 12 1 9 1 1>;
+ };
};
--
2.4.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v9 0/4] Exynos SROMc configuration and Ethernet support for SMDK5410
This patch extends Exynos SROM controller driver with ability to configure
controller outputs and enables SMSC9115 Ethernet chip on SMDK5410 board,
which is connected via SROMc bank #3.
With this patchset, support for the whole existing SMDK range can be added.
Actually, only bank number is different.
This patchset also depends on Exynos 5410 pinctrl support, introduced by
patches 0003 and 0004 from this set:
[PATCH v4 0/5] ARM: EXYNOS: ODROID-XU DT and LEDs
http://lists.infradead.org/pipermail/linux-arm-kernel/2015-March/330862.html
Pinctrl support is necessary in order to correctly configure
multifunctional pins of the Exynos chip.
v8 => v9:
- Fixed node suffix in ethernet chip DT node (@3,0 instead of @3)
v7 => v8:
- More fixes to documentation
v6 => v7:
- Fixed stupid error in Tacc description in the documentation
v5 => v6:
- Even more improvements to the documentation, fixed some errors and typos.
- Separated adding bus ranges from generic SROMc support
- Some stuff renamed for even better code readability
- Stylistic cleanups in the DTS (everything in alphabetic order, use named
constant name for interrupt config byte)
v4 => v5:
- Some cosmetic changes in the dtsi ("compatible" goes first)
- Use correctly specified ranges for the SROMc node
- Reuse existing properties where possible ("reg" for bank# and
"reg-io-width" for data width)
- Separated page-mode property from timings array
- More improvements to the documentation
v3 => v4:
- Devices are now added as subnodes, with additional properties. This allows
to cleary specify dependency. If configuration fails, error will be reported
and child devices will not be probed.
- These additional properties now have "samsung,srom-XXX" format
- Fixed code style, now better understood.
v2 => v3:
- Fixed up SROMc region size in the device tree
- Reordered patches, documentation goes first now
v1 => v2:
- Fixed some typos and bad labels in device tree
- Improved documentation
Pavel Fedin (4):
Documentation: dt-bindings: Describe SROMc configuration
ARM: dts: Add SROMc to Exynos 5410
drivers: exynos-srom: Add support for bank configuration
ARM: dts: Add Ethernet chip to SMDK5410
.../bindings/arm/samsung/exynos-srom.txt | 73 +-
arch/arm/boot/dts/exynos5410-smdk5410.dts | 41
arch/arm/boot/dts/exynos5410.dtsi | 11
arch/arm/mach-exynos/Kconfig | 2 +-
drivers/soc/samsung/Kconfig| 2 +-
drivers/soc/samsung/exynos-srom.c | 61 +-
6 files changed, 184 insertions(+), 6 deletions(-)
--
2.4.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v9 2/4] ARM: dts: Add SROMc to Exynos 5410
This machine uses own SoC device tree file, add missing part.
Signed-off-by: Pavel Fedin <p.fe...@samsung.com>
Reviewed-by: Krzysztof Kozlowski <k.kozlow...@samsung.com>
---
arch/arm/boot/dts/exynos5410.dtsi | 5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5410.dtsi
b/arch/arm/boot/dts/exynos5410.dtsi
index 4603356..e2b58f8 100644
--- a/arch/arm/boot/dts/exynos5410.dtsi
+++ b/arch/arm/boot/dts/exynos5410.dtsi
@@ -101,6 +101,11 @@
reg = <0x1000 0x100>;
};
+ sromc: sromc@1225 {
+ compatible = "samsung,exynos-srom";
+ reg = <0x1225 0x14>;
+ };
+
pmu_system_controller: system-controller@1004 {
compatible = "samsung,exynos5410-pmu", "syscon";
reg = <0x1004 0x5000>;
--
2.4.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v9 3/4] drivers: exynos-srom: Add support for bank configuration
Implement handling properties in subnodes and adding child devices to the
system. Child devices will not be added if configuration fails.
Since the driver now does more than suspend-resume support, dependency on
CONFIG_PM is removed.
Signed-off-by: Pavel Fedin <p.fe...@samsung.com>
Reviewed-by: Krzysztof Kozlowski <k.kozlow...@samsung.com>
---
arch/arm/mach-exynos/Kconfig | 2 +-
drivers/soc/samsung/Kconfig | 2 +-
drivers/soc/samsung/exynos-srom.c | 61 +--
3 files changed, 61 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig
index 83c85f5..c22dc42 100644
--- a/arch/arm/mach-exynos/Kconfig
+++ b/arch/arm/mach-exynos/Kconfig
@@ -16,7 +16,7 @@ menuconfig ARCH_EXYNOS
select ARM_GIC
select COMMON_CLK_SAMSUNG
select EXYNOS_THERMAL
- select EXYNOS_SROM if PM
+ select EXYNOS_SROM
select HAVE_ARM_SCU if SMP
select HAVE_S3C2410_I2C if I2C
select HAVE_S3C2410_WATCHDOG if WATCHDOG
diff --git a/drivers/soc/samsung/Kconfig b/drivers/soc/samsung/Kconfig
index 2833b5b..ea4bc2a 100644
--- a/drivers/soc/samsung/Kconfig
+++ b/drivers/soc/samsung/Kconfig
@@ -8,6 +8,6 @@ config SOC_SAMSUNG
config EXYNOS_SROM
bool
- depends on ARM && ARCH_EXYNOS && PM
+ depends on ARM && ARCH_EXYNOS
endmenu
diff --git a/drivers/soc/samsung/exynos-srom.c
b/drivers/soc/samsung/exynos-srom.c
index 57a232d..a4cf547 100644
--- a/drivers/soc/samsung/exynos-srom.c
+++ b/drivers/soc/samsung/exynos-srom.c
@@ -14,6 +14,7 @@
#include
#include
#include
+#include
#include
#include
@@ -67,11 +68,51 @@ static struct exynos_srom_reg_dump
*exynos_srom_alloc_reg_dump(
return rd;
}
+static int exynos_srom_configure_bank(struct exynos_srom *srom,
+ struct device_node *np)
+{
+ u32 bank, width, pmc;
+ u32 timing[6];
+ u32 cs, bw;
+
+ if (of_property_read_u32(np, "reg", ))
+ return -EINVAL;
+ if (of_property_read_u32(np, "reg-io-width", ))
+ width = 1;
+ if (of_property_read_u32(np, "samsung,srom-page-mode", ))
+ pmc = 0;
+ if (of_property_read_u32_array(np, "samsung,srom-timing", timing,
+ ARRAY_SIZE(timing)))
+ return -EINVAL;
+
+ bank *= 4; /* Convert bank into shift/offset */
+
+ cs = 1 << EXYNOS_SROM_BW__BYTEENABLE__SHIFT;
+ if (width == 2)
+ cs |= 1 << EXYNOS_SROM_BW__DATAWIDTH__SHIFT;
+
+ bw = __raw_readl(srom->reg_base + EXYNOS_SROM_BW);
+ bw = (bw & ~(EXYNOS_SROM_BW__CS_MASK << bank)) | (cs << bank);
+ __raw_writel(bw, srom->reg_base + EXYNOS_SROM_BW);
+
+ __raw_writel((pmc << EXYNOS_SROM_BCX__PMC__SHIFT) |
+ (timing[0] << EXYNOS_SROM_BCX__TACP__SHIFT) |
+ (timing[1] << EXYNOS_SROM_BCX__TCAH__SHIFT) |
+ (timing[2] << EXYNOS_SROM_BCX__TCOH__SHIFT) |
+ (timing[3] << EXYNOS_SROM_BCX__TACC__SHIFT) |
+ (timing[4] << EXYNOS_SROM_BCX__TCOS__SHIFT) |
+ (timing[5] << EXYNOS_SROM_BCX__TACS__SHIFT),
+ srom->reg_base + EXYNOS_SROM_BC0 + bank);
+
+ return 0;
+}
+
static int exynos_srom_probe(struct platform_device *pdev)
{
- struct device_node *np;
+ struct device_node *np, *child;
struct exynos_srom *srom;
struct device *dev = >dev;
+ bool bad_bank_config = false;
np = dev->of_node;
if (!np) {
@@ -100,7 +141,23 @@ static int exynos_srom_probe(struct platform_device *pdev)
return -ENOMEM;
}
- return 0;
+ for_each_child_of_node(np, child) {
+ if (exynos_srom_configure_bank(srom, child)) {
+ dev_err(dev,
+ "Could not decode bank configuration for %s\n",
+ child->name);
+ bad_bank_config = true;
+ }
+ }
+
+ /*
+* If any bank failed to configure, we still provide suspend/resume,
+* but do not probe child devices
+*/
+ if (bad_bank_config)
+ return 0;
+
+ return of_platform_populate(np, NULL, NULL, dev);
}
static int exynos_srom_remove(struct platform_device *pdev)
--
2.4.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v9 4/4] ARM: dts: Add Ethernet chip to SMDK5410
The chip is smsc9115, connected via SROMc bank 3. Additionally, some GPIO
initialization is required.
Signed-off-by: Pavel Fedin <p.fe...@samsung.com>
Reviewed-by: Krzysztof Kozlowski <k.kozlow...@samsung.com>
---
arch/arm/boot/dts/exynos5410-smdk5410.dts | 41 +++
arch/arm/boot/dts/exynos5410.dtsi | 6 +
2 files changed, 47 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5410-smdk5410.dts
b/arch/arm/boot/dts/exynos5410-smdk5410.dts
index cebeaab..a731fbe 100644
--- a/arch/arm/boot/dts/exynos5410-smdk5410.dts
+++ b/arch/arm/boot/dts/exynos5410-smdk5410.dts
@@ -11,6 +11,7 @@
/dts-v1/;
#include "exynos5410.dtsi"
+#include
/ {
model = "Samsung SMDK5410 board based on EXYNOS5410";
compatible = "samsung,smdk5410", "samsung,exynos5410",
"samsung,exynos5";
@@ -61,6 +62,46 @@
disable-wp;
};
+_0 {
+ srom_ctl: srom-ctl {
+ samsung,pins = "gpy0-3", "gpy0-4", "gpy0-5",
+ "gpy1-0", "gpy1-1", "gpy1-2", "gpy1-3";
+ samsung,pin-function = <2>;
+ samsung,pin-drv = <0>;
+ };
+
+ srom_ebi: srom-ebi {
+ samsung,pins = "gpy3-0", "gpy3-1", "gpy3-2", "gpy3-3",
+ "gpy3-4", "gpy3-5", "gpy3-6", "gpy3-7",
+ "gpy5-0", "gpy5-1", "gpy5-2", "gpy5-3",
+ "gpy5-4", "gpy5-5", "gpy5-6", "gpy5-7",
+ "gpy6-0", "gpy6-1", "gpy6-2", "gpy6-3",
+ "gpy6-4", "gpy6-5", "gpy6-6", "gpy6-7";
+ samsung,pin-function = <2>;
+ samsung,pin-pud = <3>;
+ samsung,pin-drv = <0>;
+ };
+};
+
+ {
+ pinctrl-names = "default";
+ pinctrl-0 = <_ctl>, <_ebi>;
+
+ ethernet@3,0 {
+ compatible = "smsc,lan9115";
+ reg = <3 0 0x1>;
+ phy-mode = "mii";
+ interrupt-parent = <>;
+ interrupts = <5 IRQ_TYPE_LEVEL_LOW>;
+ reg-io-width = <2>;
+ smsc,irq-push-pull;
+ smsc,force-internal-phy;
+
+ samsung,srom-page-mode = <1>;
+ samsung,srom-timing = <9 12 1 9 1 1>;
+ };
+};
+
{
status = "okay";
};
diff --git a/arch/arm/boot/dts/exynos5410.dtsi
b/arch/arm/boot/dts/exynos5410.dtsi
index e2b58f8..9cfb814 100644
--- a/arch/arm/boot/dts/exynos5410.dtsi
+++ b/arch/arm/boot/dts/exynos5410.dtsi
@@ -104,6 +104,12 @@
sromc: sromc@1225 {
compatible = "samsung,exynos-srom";
reg = <0x1225 0x14>;
+ #address-cells = <2>;
+ #size-cells = <1>;
+ ranges = <0 0 0x0400 0x2
+ 1 0 0x0500 0x2
+ 2 0 0x0600 0x2
+ 3 0 0x0700 0x2>;
};
pmu_system_controller: system-controller@1004 {
--
2.4.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v9 1/4] Documentation: dt-bindings: Describe SROMc configuration
Add documentation for new subnode properties, allowing bank configuration.
Based on u-boot implementation, but heavily reworked.
Also, fix size of SROMc mapping in the example.
Signed-off-by: Pavel Fedin <p.fe...@samsung.com>
Reviewed-by: Krzysztof Kozlowski <k.kozlow...@samsung.com>
Acked-by: Rob Herring <r...@kernel.org>
---
.../bindings/arm/samsung/exynos-srom.txt | 73 +-
1 file changed, 71 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/arm/samsung/exynos-srom.txt
b/Documentation/devicetree/bindings/arm/samsung/exynos-srom.txt
index 33886d5..e5c18df 100644
--- a/Documentation/devicetree/bindings/arm/samsung/exynos-srom.txt
+++ b/Documentation/devicetree/bindings/arm/samsung/exynos-srom.txt
@@ -5,8 +5,77 @@ Required properties:
- reg: offset and length of the register set
-Example:
+Optional properties:
+The SROM controller can be used to attach external peripherals. In this case
+extra properties, describing the bus behind it, should be specified as below:
+
+- #address-cells: Must be set to 2 to allow device address translation.
+ Address is specified as (bank#, offset).
+
+- #size-cells: Must be set to 1 to allow device size passing
+
+- ranges: Must be set up to reflect the memory layout with four integer values
+ per bank:
+0
+
+Sub-nodes:
+The actual device nodes should be added as subnodes to the SROMc node. These
+subnodes, except regular device specification, should contain the following
+properties, describing configuration of the relevant SROM bank:
+
+Required properties:
+- reg: bank number, base address (relative to start of the bank) and size of
+ the memory mapped for the device. Note that base address will be
+ typically 0 as this is the start of the bank.
+
+- samsung,srom-timing : array of 6 integers, specifying bank timings in the
+following order: Tacp, Tcah, Tcoh, Tacc, Tcos, Tacs.
+Each value is specified in cycles and has the following
+meaning and valid range:
+Tacp : Page mode access cycle at Page mode (0 - 15)
+Tcah : Address holding time after CSn (0 - 15)
+Tcoh : Chip selection hold on OEn (0 - 15)
+Tacc : Access cycle (0 - 31, the actual time is N + 1)
+Tcos : Chip selection set-up before OEn (0 - 15)
+Tacs : Address set-up before CSn (0 - 15)
+
+Optional properties:
+- reg-io-width : data width in bytes (1 or 2). If omitted, default of 1 is
used.
+
+- samsung,srom-page-mode : page mode configuration for the bank:
+ 0 - normal (one data)
+ 1 - four data
+ If omitted, default of 0 is used.
+
+Example: basic definition, no banks are configured
+ sromc@1257 {
+ compatible = "samsung,exynos-srom";
+ reg = <0x1257 0x14>;
+ };
+
+Example: SROMc with SMSC911x ethernet chip on bank 3
sromc@1257 {
+ #address-cells = <2>;
+ #size-cells = <1>;
+ ranges = <0 0 0x0400 0x2 // Bank0
+ 1 0 0x0500 0x2 // Bank1
+ 2 0 0x0600 0x2 // Bank2
+ 3 0 0x0700 0x2>; // Bank3
+
compatible = "samsung,exynos-srom";
- reg = <0x1257 0x10>;
+ reg = <0x1257 0x14>;
+
+ ethernet@3,0 {
+ compatible = "smsc,lan9115";
+ reg = <3 0 0x1>; // Bank 3, offset = 0
+ phy-mode = "mii";
+ interrupt-parent = <>;
+ interrupts = <5 8>;
+ reg-io-width = <2>;
+ smsc,irq-push-pull;
+ smsc,force-internal-phy;
+
+ samsung,srom-page-mode = <1>;
+ samsung,srom-timing = <9 12 1 9 1 1>;
+ };
};
--
2.4.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v9 0/4] Exynos SROMc configuration and Ethernet support for SMDK5410
This patch extends Exynos SROM controller driver with ability to configure
controller outputs and enables SMSC9115 Ethernet chip on SMDK5410 board,
which is connected via SROMc bank #3.
With this patchset, support for the whole existing SMDK range can be added.
Actually, only bank number is different.
This patchset also depends on Exynos 5410 pinctrl support, introduced by
patches 0003 and 0004 from this set:
[PATCH v4 0/5] ARM: EXYNOS: ODROID-XU DT and LEDs
http://lists.infradead.org/pipermail/linux-arm-kernel/2015-March/330862.html
Pinctrl support is necessary in order to correctly configure
multifunctional pins of the Exynos chip.
v8 => v9:
- Fixed node suffix in ethernet chip DT node (@3,0 instead of @3)
v7 => v8:
- More fixes to documentation
v6 => v7:
- Fixed stupid error in Tacc description in the documentation
v5 => v6:
- Even more improvements to the documentation, fixed some errors and typos.
- Separated adding bus ranges from generic SROMc support
- Some stuff renamed for even better code readability
- Stylistic cleanups in the DTS (everything in alphabetic order, use named
constant name for interrupt config byte)
v4 => v5:
- Some cosmetic changes in the dtsi ("compatible" goes first)
- Use correctly specified ranges for the SROMc node
- Reuse existing properties where possible ("reg" for bank# and
"reg-io-width" for data width)
- Separated page-mode property from timings array
- More improvements to the documentation
v3 => v4:
- Devices are now added as subnodes, with additional properties. This allows
to cleary specify dependency. If configuration fails, error will be reported
and child devices will not be probed.
- These additional properties now have "samsung,srom-XXX" format
- Fixed code style, now better understood.
v2 => v3:
- Fixed up SROMc region size in the device tree
- Reordered patches, documentation goes first now
v1 => v2:
- Fixed some typos and bad labels in device tree
- Improved documentation
Pavel Fedin (4):
Documentation: dt-bindings: Describe SROMc configuration
ARM: dts: Add SROMc to Exynos 5410
drivers: exynos-srom: Add support for bank configuration
ARM: dts: Add Ethernet chip to SMDK5410
.../bindings/arm/samsung/exynos-srom.txt | 73 +-
arch/arm/boot/dts/exynos5410-smdk5410.dts | 41
arch/arm/boot/dts/exynos5410.dtsi | 11
arch/arm/mach-exynos/Kconfig | 2 +-
drivers/soc/samsung/Kconfig| 2 +-
drivers/soc/samsung/exynos-srom.c | 61 +-
6 files changed, 184 insertions(+), 6 deletions(-)
--
2.4.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH RESEND] net: smsc911x: Reset PHY during initialization
On certain hardware after software reboot the chip may get stuck and fail
to reinitialize during reset. This can be fixed by ensuring that PHY is
reset too.
Old PHY resetting method required operational MDIO interface, therefore
the chip should have been already set up. In order to be able to function
during probe, it is changed to use PMT_CTRL register.
The problem could be observed on SMDK5410 board.
Signed-off-by: Pavel Fedin
---
drivers/net/ethernet/smsc/smsc911x.c | 17 ++---
1 file changed, 6 insertions(+), 11 deletions(-)
diff --git a/drivers/net/ethernet/smsc/smsc911x.c
b/drivers/net/ethernet/smsc/smsc911x.c
index c860c90..219a99b 100644
--- a/drivers/net/ethernet/smsc/smsc911x.c
+++ b/drivers/net/ethernet/smsc/smsc911x.c
@@ -809,22 +809,17 @@ static int smsc911x_phy_check_loopbackpkt(struct
smsc911x_data *pdata)
static int smsc911x_phy_reset(struct smsc911x_data *pdata)
{
- struct phy_device *phy_dev = pdata->phy_dev;
unsigned int temp;
unsigned int i = 10;
- BUG_ON(!phy_dev);
- BUG_ON(!phy_dev->bus);
-
- SMSC_TRACE(pdata, hw, "Performing PHY BCR Reset");
- smsc911x_mii_write(phy_dev->bus, phy_dev->addr, MII_BMCR, BMCR_RESET);
+ temp = smsc911x_reg_read(pdata, PMT_CTRL);
+ smsc911x_reg_write(pdata, PMT_CTRL, temp | PMT_CTRL_PHY_RST_);
do {
msleep(1);
- temp = smsc911x_mii_read(phy_dev->bus, phy_dev->addr,
- MII_BMCR);
- } while ((i--) && (temp & BMCR_RESET));
+ temp = smsc911x_reg_read(pdata, PMT_CTRL);
+ } while ((i--) && (temp & PMT_CTRL_PHY_RST_));
- if (temp & BMCR_RESET) {
+ if (unlikely(temp & PMT_CTRL_PHY_RST_)) {
SMSC_WARN(pdata, hw, "PHY reset failed to complete");
return -EIO;
}
@@ -2296,7 +2291,7 @@ static int smsc911x_init(struct net_device *dev)
}
/* Reset the LAN911x */
- if (smsc911x_soft_reset(pdata))
+ if (smsc911x_phy_reset(pdata) || smsc911x_soft_reset(pdata))
return -ENODEV;
dev->flags |= IFF_MULTICAST;
--
2.4.4
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v8 1/4] Documentation: dt-bindings: Describe SROMc configuration
Add documentation for new subnode properties, allowing bank configuration.
Based on u-boot implementation, but heavily reworked.
Also, fix size of SROMc mapping in the example.
Signed-off-by: Pavel Fedin
Reviewed-by: Krzysztof Kozlowski
---
.../bindings/arm/samsung/exynos-srom.txt | 73 +-
1 file changed, 71 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/arm/samsung/exynos-srom.txt
b/Documentation/devicetree/bindings/arm/samsung/exynos-srom.txt
index 33886d5..07c8507 100644
--- a/Documentation/devicetree/bindings/arm/samsung/exynos-srom.txt
+++ b/Documentation/devicetree/bindings/arm/samsung/exynos-srom.txt
@@ -5,8 +5,77 @@ Required properties:
- reg: offset and length of the register set
-Example:
+Optional properties:
+The SROM controller can be used to attach external peripherals. In this case
+extra properties, describing the bus behind it, should be specified as below:
+
+- #address-cells: Must be set to 2 to allow device address translation.
+ Address is specified as (bank#, offset).
+
+- #size-cells: Must be set to 1 to allow device size passing
+
+- ranges: Must be set up to reflect the memory layout with four integer values
+ per bank:
+0
+
+Sub-nodes:
+The actual device nodes should be added as subnodes to the SROMc node. These
+subnodes, except regular device specification, should contain the following
+properties, describing configuration of the relevant SROM bank:
+
+Required properties:
+- reg: bank number, base address (relative to start of the bank) and size of
+ the memory mapped for the device. Note that base address will be
+ typically 0 as this is the start of the bank.
+
+- samsung,srom-timing : array of 6 integers, specifying bank timings in the
+following order: Tacp, Tcah, Tcoh, Tacc, Tcos, Tacs.
+Each value is specified in cycles and has the following
+meaning and valid range:
+Tacp : Page mode access cycle at Page mode (0 - 15)
+Tcah : Address holding time after CSn (0 - 15)
+Tcoh : Chip selection hold on OEn (0 - 15)
+Tacc : Access cycle (0 - 31, the actual time is N + 1)
+Tcos : Chip selection set-up before OEn (0 - 15)
+Tacs : Address set-up before CSn (0 - 15)
+
+Optional properties:
+- reg-io-width : data width in bytes (1 or 2). If omitted, default of 1 is
used.
+
+- samsung,srom-page-mode : page mode configuration for the bank:
+ 0 - normal (one data)
+ 1 - four data
+ If omitted, default of 0 is used.
+
+Example: basic definition, no banks are configured
+ sromc@1257 {
+ compatible = "samsung,exynos-srom";
+ reg = <0x1257 0x14>;
+ };
+
+Example: SROMc with SMSC911x ethernet chip on bank 3
sromc@1257 {
+ #address-cells = <2>;
+ #size-cells = <1>;
+ ranges = <0 0 0x0400 0x2 // Bank0
+ 1 0 0x0500 0x2 // Bank1
+ 2 0 0x0600 0x2 // Bank2
+ 3 0 0x0700 0x2>; // Bank3
+
compatible = "samsung,exynos-srom";
- reg = <0x1257 0x10>;
+ reg = <0x1257 0x14>;
+
+ ethernet@3 {
+ compatible = "smsc,lan9115";
+ reg = <3 0 0x1>; // Bank 3, offset = 0
+ phy-mode = "mii";
+ interrupt-parent = <>;
+ interrupts = <5 8>;
+ reg-io-width = <2>;
+ smsc,irq-push-pull;
+ smsc,force-internal-phy;
+
+ samsung,srom-page-mode = <1>;
+ samsung,srom-timing = <9 12 1 9 1 1>;
+ };
};
--
2.4.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v8 3/4] drivers: exynos-srom: Add support for bank configuration
Implement handling properties in subnodes and adding child devices to the
system. Child devices will not be added if configuration fails.
Since the driver now does more than suspend-resume support, dependency on
CONFIG_PM is removed.
Signed-off-by: Pavel Fedin
Reviewed-by: Krzysztof Kozlowski
---
arch/arm/mach-exynos/Kconfig | 2 +-
drivers/soc/samsung/Kconfig | 2 +-
drivers/soc/samsung/exynos-srom.c | 61 +--
3 files changed, 61 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig
index 83c85f5..c22dc42 100644
--- a/arch/arm/mach-exynos/Kconfig
+++ b/arch/arm/mach-exynos/Kconfig
@@ -16,7 +16,7 @@ menuconfig ARCH_EXYNOS
select ARM_GIC
select COMMON_CLK_SAMSUNG
select EXYNOS_THERMAL
- select EXYNOS_SROM if PM
+ select EXYNOS_SROM
select HAVE_ARM_SCU if SMP
select HAVE_S3C2410_I2C if I2C
select HAVE_S3C2410_WATCHDOG if WATCHDOG
diff --git a/drivers/soc/samsung/Kconfig b/drivers/soc/samsung/Kconfig
index 2833b5b..ea4bc2a 100644
--- a/drivers/soc/samsung/Kconfig
+++ b/drivers/soc/samsung/Kconfig
@@ -8,6 +8,6 @@ config SOC_SAMSUNG
config EXYNOS_SROM
bool
- depends on ARM && ARCH_EXYNOS && PM
+ depends on ARM && ARCH_EXYNOS
endmenu
diff --git a/drivers/soc/samsung/exynos-srom.c
b/drivers/soc/samsung/exynos-srom.c
index 57a232d..a4cf547 100644
--- a/drivers/soc/samsung/exynos-srom.c
+++ b/drivers/soc/samsung/exynos-srom.c
@@ -14,6 +14,7 @@
#include
#include
#include
+#include
#include
#include
@@ -67,11 +68,51 @@ static struct exynos_srom_reg_dump
*exynos_srom_alloc_reg_dump(
return rd;
}
+static int exynos_srom_configure_bank(struct exynos_srom *srom,
+ struct device_node *np)
+{
+ u32 bank, width, pmc;
+ u32 timing[6];
+ u32 cs, bw;
+
+ if (of_property_read_u32(np, "reg", ))
+ return -EINVAL;
+ if (of_property_read_u32(np, "reg-io-width", ))
+ width = 1;
+ if (of_property_read_u32(np, "samsung,srom-page-mode", ))
+ pmc = 0;
+ if (of_property_read_u32_array(np, "samsung,srom-timing", timing,
+ ARRAY_SIZE(timing)))
+ return -EINVAL;
+
+ bank *= 4; /* Convert bank into shift/offset */
+
+ cs = 1 << EXYNOS_SROM_BW__BYTEENABLE__SHIFT;
+ if (width == 2)
+ cs |= 1 << EXYNOS_SROM_BW__DATAWIDTH__SHIFT;
+
+ bw = __raw_readl(srom->reg_base + EXYNOS_SROM_BW);
+ bw = (bw & ~(EXYNOS_SROM_BW__CS_MASK << bank)) | (cs << bank);
+ __raw_writel(bw, srom->reg_base + EXYNOS_SROM_BW);
+
+ __raw_writel((pmc << EXYNOS_SROM_BCX__PMC__SHIFT) |
+ (timing[0] << EXYNOS_SROM_BCX__TACP__SHIFT) |
+ (timing[1] << EXYNOS_SROM_BCX__TCAH__SHIFT) |
+ (timing[2] << EXYNOS_SROM_BCX__TCOH__SHIFT) |
+ (timing[3] << EXYNOS_SROM_BCX__TACC__SHIFT) |
+ (timing[4] << EXYNOS_SROM_BCX__TCOS__SHIFT) |
+ (timing[5] << EXYNOS_SROM_BCX__TACS__SHIFT),
+ srom->reg_base + EXYNOS_SROM_BC0 + bank);
+
+ return 0;
+}
+
static int exynos_srom_probe(struct platform_device *pdev)
{
- struct device_node *np;
+ struct device_node *np, *child;
struct exynos_srom *srom;
struct device *dev = >dev;
+ bool bad_bank_config = false;
np = dev->of_node;
if (!np) {
@@ -100,7 +141,23 @@ static int exynos_srom_probe(struct platform_device *pdev)
return -ENOMEM;
}
- return 0;
+ for_each_child_of_node(np, child) {
+ if (exynos_srom_configure_bank(srom, child)) {
+ dev_err(dev,
+ "Could not decode bank configuration for %s\n",
+ child->name);
+ bad_bank_config = true;
+ }
+ }
+
+ /*
+* If any bank failed to configure, we still provide suspend/resume,
+* but do not probe child devices
+*/
+ if (bad_bank_config)
+ return 0;
+
+ return of_platform_populate(np, NULL, NULL, dev);
}
static int exynos_srom_remove(struct platform_device *pdev)
--
2.4.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v8 2/4] ARM: dts: Add SROMc to Exynos 5410
This machine uses own SoC device tree file, add missing part.
Signed-off-by: Pavel Fedin
Reviewed-by: Krzysztof Kozlowski
---
arch/arm/boot/dts/exynos5410.dtsi | 5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5410.dtsi
b/arch/arm/boot/dts/exynos5410.dtsi
index 4603356..e2b58f8 100644
--- a/arch/arm/boot/dts/exynos5410.dtsi
+++ b/arch/arm/boot/dts/exynos5410.dtsi
@@ -101,6 +101,11 @@
reg = <0x1000 0x100>;
};
+ sromc: sromc@1225 {
+ compatible = "samsung,exynos-srom";
+ reg = <0x1225 0x14>;
+ };
+
pmu_system_controller: system-controller@1004 {
compatible = "samsung,exynos5410-pmu", "syscon";
reg = <0x1004 0x5000>;
--
2.4.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v8 4/4] ARM: dts: Add Ethernet chip to SMDK5410
The chip is smsc9115, connected via SROMc bank 3. Additionally, some GPIO
initialization is required.
Signed-off-by: Pavel Fedin
Reviewed-by: Krzysztof Kozlowski
---
arch/arm/boot/dts/exynos5410-smdk5410.dts | 41 +++
arch/arm/boot/dts/exynos5410.dtsi | 6 +
2 files changed, 47 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5410-smdk5410.dts
b/arch/arm/boot/dts/exynos5410-smdk5410.dts
index cebeaab..373abf7 100644
--- a/arch/arm/boot/dts/exynos5410-smdk5410.dts
+++ b/arch/arm/boot/dts/exynos5410-smdk5410.dts
@@ -11,6 +11,7 @@
/dts-v1/;
#include "exynos5410.dtsi"
+#include
/ {
model = "Samsung SMDK5410 board based on EXYNOS5410";
compatible = "samsung,smdk5410", "samsung,exynos5410",
"samsung,exynos5";
@@ -61,6 +62,46 @@
disable-wp;
};
+_0 {
+ srom_ctl: srom-ctl {
+ samsung,pins = "gpy0-3", "gpy0-4", "gpy0-5",
+ "gpy1-0", "gpy1-1", "gpy1-2", "gpy1-3";
+ samsung,pin-function = <2>;
+ samsung,pin-drv = <0>;
+ };
+
+ srom_ebi: srom-ebi {
+ samsung,pins = "gpy3-0", "gpy3-1", "gpy3-2", "gpy3-3",
+ "gpy3-4", "gpy3-5", "gpy3-6", "gpy3-7",
+ "gpy5-0", "gpy5-1", "gpy5-2", "gpy5-3",
+ "gpy5-4", "gpy5-5", "gpy5-6", "gpy5-7",
+ "gpy6-0", "gpy6-1", "gpy6-2", "gpy6-3",
+ "gpy6-4", "gpy6-5", "gpy6-6", "gpy6-7";
+ samsung,pin-function = <2>;
+ samsung,pin-pud = <3>;
+ samsung,pin-drv = <0>;
+ };
+};
+
+ {
+ pinctrl-names = "default";
+ pinctrl-0 = <_ctl>, <_ebi>;
+
+ ethernet@3 {
+ compatible = "smsc,lan9115";
+ reg = <3 0 0x1>;
+ phy-mode = "mii";
+ interrupt-parent = <>;
+ interrupts = <5 IRQ_TYPE_LEVEL_LOW>;
+ reg-io-width = <2>;
+ smsc,irq-push-pull;
+ smsc,force-internal-phy;
+
+ samsung,srom-page-mode = <1>;
+ samsung,srom-timing = <9 12 1 9 1 1>;
+ };
+};
+
{
status = "okay";
};
diff --git a/arch/arm/boot/dts/exynos5410.dtsi
b/arch/arm/boot/dts/exynos5410.dtsi
index e2b58f8..9cfb814 100644
--- a/arch/arm/boot/dts/exynos5410.dtsi
+++ b/arch/arm/boot/dts/exynos5410.dtsi
@@ -104,6 +104,12 @@
sromc: sromc@1225 {
compatible = "samsung,exynos-srom";
reg = <0x1225 0x14>;
+ #address-cells = <2>;
+ #size-cells = <1>;
+ ranges = <0 0 0x0400 0x2
+ 1 0 0x0500 0x2
+ 2 0 0x0600 0x2
+ 3 0 0x0700 0x2>;
};
pmu_system_controller: system-controller@1004 {
--
2.4.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v8 0/4] Exynos SROMc configuration and Ethernet support for SMDK5410
This patch extends Exynos SROM controller driver with ability to configure
controller outputs and enables SMSC9115 Ethernet chip on SMDK5410 board,
which is connected via SROMc bank #3.
With this patchset, support for the whole existing SMDK range can be added.
Actually, only bank number is different.
This patchset also depends on Exynos 5410 pinctrl support, introduced by
patches 0003 and 0004 from this set:
[PATCH v4 0/5] ARM: EXYNOS: ODROID-XU DT and LEDs
http://lists.infradead.org/pipermail/linux-arm-kernel/2015-March/330862.html
Pinctrl support is necessary in order to correctly configure
multifunctional pins of the Exynos chip.
v7 => v8:
- More fixes to documentation
v6 => v7:
- Fixed stupid error in Tacc description in the documentation
v5 => v6:
- Even more improvements to the documentation, fixed some errors and typos.
- Separated adding bus ranges from generic SROMc support
- Some stuff renamed for even better code readability
- Stylistic cleanups in the DTS (everything in alphabetic order, use named
constant name for interrupt config byte)
v4 => v5:
- Some cosmetic changes in the dtsi ("compatible" goes first)
- Use correctly specified ranges for the SROMc node
- Reuse existing properties where possible ("reg" for bank# and
"reg-io-width" for data width)
- Separated page-mode property from timings array
- More improvements to the documentation
v3 => v4:
- Devices are now added as subnodes, with additional properties. This allows
to cleary specify dependency. If configuration fails, error will be reported
and child devices will not be probed.
- These additional properties now have "samsung,srom-XXX" format
- Fixed code style, now better understood.
v2 => v3:
- Fixed up SROMc region size in the device tree
- Reordered patches, documentation goes first now
v1 => v2:
- Fixed some typos and bad labels in device tree
- Improved documentation
Pavel Fedin (4):
Documentation: dt-bindings: Describe SROMc configuration
ARM: dts: Add SROMc to Exynos 5410
drivers: exynos-srom: Add support for bank configuration
ARM: dts: Add Ethernet chip to SMDK5410
.../bindings/arm/samsung/exynos-srom.txt | 73 +-
arch/arm/boot/dts/exynos5410-smdk5410.dts | 41
arch/arm/boot/dts/exynos5410.dtsi | 11
arch/arm/mach-exynos/Kconfig | 2 +-
drivers/soc/samsung/Kconfig| 2 +-
drivers/soc/samsung/exynos-srom.c | 61 +-
6 files changed, 184 insertions(+), 6 deletions(-)
--
2.4.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH RESEND] net: smsc911x: Reset PHY during initialization
On certain hardware after software reboot the chip may get stuck and fail
to reinitialize during reset. This can be fixed by ensuring that PHY is
reset too.
Old PHY resetting method required operational MDIO interface, therefore
the chip should have been already set up. In order to be able to function
during probe, it is changed to use PMT_CTRL register.
The problem could be observed on SMDK5410 board.
Signed-off-by: Pavel Fedin <p.fe...@samsung.com>
---
drivers/net/ethernet/smsc/smsc911x.c | 17 ++---
1 file changed, 6 insertions(+), 11 deletions(-)
diff --git a/drivers/net/ethernet/smsc/smsc911x.c
b/drivers/net/ethernet/smsc/smsc911x.c
index c860c90..219a99b 100644
--- a/drivers/net/ethernet/smsc/smsc911x.c
+++ b/drivers/net/ethernet/smsc/smsc911x.c
@@ -809,22 +809,17 @@ static int smsc911x_phy_check_loopbackpkt(struct
smsc911x_data *pdata)
static int smsc911x_phy_reset(struct smsc911x_data *pdata)
{
- struct phy_device *phy_dev = pdata->phy_dev;
unsigned int temp;
unsigned int i = 10;
- BUG_ON(!phy_dev);
- BUG_ON(!phy_dev->bus);
-
- SMSC_TRACE(pdata, hw, "Performing PHY BCR Reset");
- smsc911x_mii_write(phy_dev->bus, phy_dev->addr, MII_BMCR, BMCR_RESET);
+ temp = smsc911x_reg_read(pdata, PMT_CTRL);
+ smsc911x_reg_write(pdata, PMT_CTRL, temp | PMT_CTRL_PHY_RST_);
do {
msleep(1);
- temp = smsc911x_mii_read(phy_dev->bus, phy_dev->addr,
- MII_BMCR);
- } while ((i--) && (temp & BMCR_RESET));
+ temp = smsc911x_reg_read(pdata, PMT_CTRL);
+ } while ((i--) && (temp & PMT_CTRL_PHY_RST_));
- if (temp & BMCR_RESET) {
+ if (unlikely(temp & PMT_CTRL_PHY_RST_)) {
SMSC_WARN(pdata, hw, "PHY reset failed to complete");
return -EIO;
}
@@ -2296,7 +2291,7 @@ static int smsc911x_init(struct net_device *dev)
}
/* Reset the LAN911x */
- if (smsc911x_soft_reset(pdata))
+ if (smsc911x_phy_reset(pdata) || smsc911x_soft_reset(pdata))
return -ENODEV;
dev->flags |= IFF_MULTICAST;
--
2.4.4
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v8 4/4] ARM: dts: Add Ethernet chip to SMDK5410
The chip is smsc9115, connected via SROMc bank 3. Additionally, some GPIO
initialization is required.
Signed-off-by: Pavel Fedin <p.fe...@samsung.com>
Reviewed-by: Krzysztof Kozlowski <k.kozlow...@samsung.com>
---
arch/arm/boot/dts/exynos5410-smdk5410.dts | 41 +++
arch/arm/boot/dts/exynos5410.dtsi | 6 +
2 files changed, 47 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5410-smdk5410.dts
b/arch/arm/boot/dts/exynos5410-smdk5410.dts
index cebeaab..373abf7 100644
--- a/arch/arm/boot/dts/exynos5410-smdk5410.dts
+++ b/arch/arm/boot/dts/exynos5410-smdk5410.dts
@@ -11,6 +11,7 @@
/dts-v1/;
#include "exynos5410.dtsi"
+#include
/ {
model = "Samsung SMDK5410 board based on EXYNOS5410";
compatible = "samsung,smdk5410", "samsung,exynos5410",
"samsung,exynos5";
@@ -61,6 +62,46 @@
disable-wp;
};
+_0 {
+ srom_ctl: srom-ctl {
+ samsung,pins = "gpy0-3", "gpy0-4", "gpy0-5",
+ "gpy1-0", "gpy1-1", "gpy1-2", "gpy1-3";
+ samsung,pin-function = <2>;
+ samsung,pin-drv = <0>;
+ };
+
+ srom_ebi: srom-ebi {
+ samsung,pins = "gpy3-0", "gpy3-1", "gpy3-2", "gpy3-3",
+ "gpy3-4", "gpy3-5", "gpy3-6", "gpy3-7",
+ "gpy5-0", "gpy5-1", "gpy5-2", "gpy5-3",
+ "gpy5-4", "gpy5-5", "gpy5-6", "gpy5-7",
+ "gpy6-0", "gpy6-1", "gpy6-2", "gpy6-3",
+ "gpy6-4", "gpy6-5", "gpy6-6", "gpy6-7";
+ samsung,pin-function = <2>;
+ samsung,pin-pud = <3>;
+ samsung,pin-drv = <0>;
+ };
+};
+
+ {
+ pinctrl-names = "default";
+ pinctrl-0 = <_ctl>, <_ebi>;
+
+ ethernet@3 {
+ compatible = "smsc,lan9115";
+ reg = <3 0 0x1>;
+ phy-mode = "mii";
+ interrupt-parent = <>;
+ interrupts = <5 IRQ_TYPE_LEVEL_LOW>;
+ reg-io-width = <2>;
+ smsc,irq-push-pull;
+ smsc,force-internal-phy;
+
+ samsung,srom-page-mode = <1>;
+ samsung,srom-timing = <9 12 1 9 1 1>;
+ };
+};
+
{
status = "okay";
};
diff --git a/arch/arm/boot/dts/exynos5410.dtsi
b/arch/arm/boot/dts/exynos5410.dtsi
index e2b58f8..9cfb814 100644
--- a/arch/arm/boot/dts/exynos5410.dtsi
+++ b/arch/arm/boot/dts/exynos5410.dtsi
@@ -104,6 +104,12 @@
sromc: sromc@1225 {
compatible = "samsung,exynos-srom";
reg = <0x1225 0x14>;
+ #address-cells = <2>;
+ #size-cells = <1>;
+ ranges = <0 0 0x0400 0x2
+ 1 0 0x0500 0x2
+ 2 0 0x0600 0x2
+ 3 0 0x0700 0x2>;
};
pmu_system_controller: system-controller@1004 {
--
2.4.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v8 0/4] Exynos SROMc configuration and Ethernet support for SMDK5410
This patch extends Exynos SROM controller driver with ability to configure
controller outputs and enables SMSC9115 Ethernet chip on SMDK5410 board,
which is connected via SROMc bank #3.
With this patchset, support for the whole existing SMDK range can be added.
Actually, only bank number is different.
This patchset also depends on Exynos 5410 pinctrl support, introduced by
patches 0003 and 0004 from this set:
[PATCH v4 0/5] ARM: EXYNOS: ODROID-XU DT and LEDs
http://lists.infradead.org/pipermail/linux-arm-kernel/2015-March/330862.html
Pinctrl support is necessary in order to correctly configure
multifunctional pins of the Exynos chip.
v7 => v8:
- More fixes to documentation
v6 => v7:
- Fixed stupid error in Tacc description in the documentation
v5 => v6:
- Even more improvements to the documentation, fixed some errors and typos.
- Separated adding bus ranges from generic SROMc support
- Some stuff renamed for even better code readability
- Stylistic cleanups in the DTS (everything in alphabetic order, use named
constant name for interrupt config byte)
v4 => v5:
- Some cosmetic changes in the dtsi ("compatible" goes first)
- Use correctly specified ranges for the SROMc node
- Reuse existing properties where possible ("reg" for bank# and
"reg-io-width" for data width)
- Separated page-mode property from timings array
- More improvements to the documentation
v3 => v4:
- Devices are now added as subnodes, with additional properties. This allows
to cleary specify dependency. If configuration fails, error will be reported
and child devices will not be probed.
- These additional properties now have "samsung,srom-XXX" format
- Fixed code style, now better understood.
v2 => v3:
- Fixed up SROMc region size in the device tree
- Reordered patches, documentation goes first now
v1 => v2:
- Fixed some typos and bad labels in device tree
- Improved documentation
Pavel Fedin (4):
Documentation: dt-bindings: Describe SROMc configuration
ARM: dts: Add SROMc to Exynos 5410
drivers: exynos-srom: Add support for bank configuration
ARM: dts: Add Ethernet chip to SMDK5410
.../bindings/arm/samsung/exynos-srom.txt | 73 +-
arch/arm/boot/dts/exynos5410-smdk5410.dts | 41
arch/arm/boot/dts/exynos5410.dtsi | 11
arch/arm/mach-exynos/Kconfig | 2 +-
drivers/soc/samsung/Kconfig| 2 +-
drivers/soc/samsung/exynos-srom.c | 61 +-
6 files changed, 184 insertions(+), 6 deletions(-)
--
2.4.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v8 3/4] drivers: exynos-srom: Add support for bank configuration
Implement handling properties in subnodes and adding child devices to the
system. Child devices will not be added if configuration fails.
Since the driver now does more than suspend-resume support, dependency on
CONFIG_PM is removed.
Signed-off-by: Pavel Fedin <p.fe...@samsung.com>
Reviewed-by: Krzysztof Kozlowski <k.kozlow...@samsung.com>
---
arch/arm/mach-exynos/Kconfig | 2 +-
drivers/soc/samsung/Kconfig | 2 +-
drivers/soc/samsung/exynos-srom.c | 61 +--
3 files changed, 61 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig
index 83c85f5..c22dc42 100644
--- a/arch/arm/mach-exynos/Kconfig
+++ b/arch/arm/mach-exynos/Kconfig
@@ -16,7 +16,7 @@ menuconfig ARCH_EXYNOS
select ARM_GIC
select COMMON_CLK_SAMSUNG
select EXYNOS_THERMAL
- select EXYNOS_SROM if PM
+ select EXYNOS_SROM
select HAVE_ARM_SCU if SMP
select HAVE_S3C2410_I2C if I2C
select HAVE_S3C2410_WATCHDOG if WATCHDOG
diff --git a/drivers/soc/samsung/Kconfig b/drivers/soc/samsung/Kconfig
index 2833b5b..ea4bc2a 100644
--- a/drivers/soc/samsung/Kconfig
+++ b/drivers/soc/samsung/Kconfig
@@ -8,6 +8,6 @@ config SOC_SAMSUNG
config EXYNOS_SROM
bool
- depends on ARM && ARCH_EXYNOS && PM
+ depends on ARM && ARCH_EXYNOS
endmenu
diff --git a/drivers/soc/samsung/exynos-srom.c
b/drivers/soc/samsung/exynos-srom.c
index 57a232d..a4cf547 100644
--- a/drivers/soc/samsung/exynos-srom.c
+++ b/drivers/soc/samsung/exynos-srom.c
@@ -14,6 +14,7 @@
#include
#include
#include
+#include
#include
#include
@@ -67,11 +68,51 @@ static struct exynos_srom_reg_dump
*exynos_srom_alloc_reg_dump(
return rd;
}
+static int exynos_srom_configure_bank(struct exynos_srom *srom,
+ struct device_node *np)
+{
+ u32 bank, width, pmc;
+ u32 timing[6];
+ u32 cs, bw;
+
+ if (of_property_read_u32(np, "reg", ))
+ return -EINVAL;
+ if (of_property_read_u32(np, "reg-io-width", ))
+ width = 1;
+ if (of_property_read_u32(np, "samsung,srom-page-mode", ))
+ pmc = 0;
+ if (of_property_read_u32_array(np, "samsung,srom-timing", timing,
+ ARRAY_SIZE(timing)))
+ return -EINVAL;
+
+ bank *= 4; /* Convert bank into shift/offset */
+
+ cs = 1 << EXYNOS_SROM_BW__BYTEENABLE__SHIFT;
+ if (width == 2)
+ cs |= 1 << EXYNOS_SROM_BW__DATAWIDTH__SHIFT;
+
+ bw = __raw_readl(srom->reg_base + EXYNOS_SROM_BW);
+ bw = (bw & ~(EXYNOS_SROM_BW__CS_MASK << bank)) | (cs << bank);
+ __raw_writel(bw, srom->reg_base + EXYNOS_SROM_BW);
+
+ __raw_writel((pmc << EXYNOS_SROM_BCX__PMC__SHIFT) |
+ (timing[0] << EXYNOS_SROM_BCX__TACP__SHIFT) |
+ (timing[1] << EXYNOS_SROM_BCX__TCAH__SHIFT) |
+ (timing[2] << EXYNOS_SROM_BCX__TCOH__SHIFT) |
+ (timing[3] << EXYNOS_SROM_BCX__TACC__SHIFT) |
+ (timing[4] << EXYNOS_SROM_BCX__TCOS__SHIFT) |
+ (timing[5] << EXYNOS_SROM_BCX__TACS__SHIFT),
+ srom->reg_base + EXYNOS_SROM_BC0 + bank);
+
+ return 0;
+}
+
static int exynos_srom_probe(struct platform_device *pdev)
{
- struct device_node *np;
+ struct device_node *np, *child;
struct exynos_srom *srom;
struct device *dev = >dev;
+ bool bad_bank_config = false;
np = dev->of_node;
if (!np) {
@@ -100,7 +141,23 @@ static int exynos_srom_probe(struct platform_device *pdev)
return -ENOMEM;
}
- return 0;
+ for_each_child_of_node(np, child) {
+ if (exynos_srom_configure_bank(srom, child)) {
+ dev_err(dev,
+ "Could not decode bank configuration for %s\n",
+ child->name);
+ bad_bank_config = true;
+ }
+ }
+
+ /*
+* If any bank failed to configure, we still provide suspend/resume,
+* but do not probe child devices
+*/
+ if (bad_bank_config)
+ return 0;
+
+ return of_platform_populate(np, NULL, NULL, dev);
}
static int exynos_srom_remove(struct platform_device *pdev)
--
2.4.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v8 1/4] Documentation: dt-bindings: Describe SROMc configuration
Add documentation for new subnode properties, allowing bank configuration.
Based on u-boot implementation, but heavily reworked.
Also, fix size of SROMc mapping in the example.
Signed-off-by: Pavel Fedin <p.fe...@samsung.com>
Reviewed-by: Krzysztof Kozlowski <k.kozlow...@samsung.com>
---
.../bindings/arm/samsung/exynos-srom.txt | 73 +-
1 file changed, 71 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/arm/samsung/exynos-srom.txt
b/Documentation/devicetree/bindings/arm/samsung/exynos-srom.txt
index 33886d5..07c8507 100644
--- a/Documentation/devicetree/bindings/arm/samsung/exynos-srom.txt
+++ b/Documentation/devicetree/bindings/arm/samsung/exynos-srom.txt
@@ -5,8 +5,77 @@ Required properties:
- reg: offset and length of the register set
-Example:
+Optional properties:
+The SROM controller can be used to attach external peripherals. In this case
+extra properties, describing the bus behind it, should be specified as below:
+
+- #address-cells: Must be set to 2 to allow device address translation.
+ Address is specified as (bank#, offset).
+
+- #size-cells: Must be set to 1 to allow device size passing
+
+- ranges: Must be set up to reflect the memory layout with four integer values
+ per bank:
+0
+
+Sub-nodes:
+The actual device nodes should be added as subnodes to the SROMc node. These
+subnodes, except regular device specification, should contain the following
+properties, describing configuration of the relevant SROM bank:
+
+Required properties:
+- reg: bank number, base address (relative to start of the bank) and size of
+ the memory mapped for the device. Note that base address will be
+ typically 0 as this is the start of the bank.
+
+- samsung,srom-timing : array of 6 integers, specifying bank timings in the
+following order: Tacp, Tcah, Tcoh, Tacc, Tcos, Tacs.
+Each value is specified in cycles and has the following
+meaning and valid range:
+Tacp : Page mode access cycle at Page mode (0 - 15)
+Tcah : Address holding time after CSn (0 - 15)
+Tcoh : Chip selection hold on OEn (0 - 15)
+Tacc : Access cycle (0 - 31, the actual time is N + 1)
+Tcos : Chip selection set-up before OEn (0 - 15)
+Tacs : Address set-up before CSn (0 - 15)
+
+Optional properties:
+- reg-io-width : data width in bytes (1 or 2). If omitted, default of 1 is
used.
+
+- samsung,srom-page-mode : page mode configuration for the bank:
+ 0 - normal (one data)
+ 1 - four data
+ If omitted, default of 0 is used.
+
+Example: basic definition, no banks are configured
+ sromc@1257 {
+ compatible = "samsung,exynos-srom";
+ reg = <0x1257 0x14>;
+ };
+
+Example: SROMc with SMSC911x ethernet chip on bank 3
sromc@1257 {
+ #address-cells = <2>;
+ #size-cells = <1>;
+ ranges = <0 0 0x0400 0x2 // Bank0
+ 1 0 0x0500 0x2 // Bank1
+ 2 0 0x0600 0x2 // Bank2
+ 3 0 0x0700 0x2>; // Bank3
+
compatible = "samsung,exynos-srom";
- reg = <0x1257 0x10>;
+ reg = <0x1257 0x14>;
+
+ ethernet@3 {
+ compatible = "smsc,lan9115";
+ reg = <3 0 0x1>; // Bank 3, offset = 0
+ phy-mode = "mii";
+ interrupt-parent = <>;
+ interrupts = <5 8>;
+ reg-io-width = <2>;
+ smsc,irq-push-pull;
+ smsc,force-internal-phy;
+
+ samsung,srom-page-mode = <1>;
+ samsung,srom-timing = <9 12 1 9 1 1>;
+ };
};
--
2.4.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v8 2/4] ARM: dts: Add SROMc to Exynos 5410
This machine uses own SoC device tree file, add missing part.
Signed-off-by: Pavel Fedin <p.fe...@samsung.com>
Reviewed-by: Krzysztof Kozlowski <k.kozlow...@samsung.com>
---
arch/arm/boot/dts/exynos5410.dtsi | 5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5410.dtsi
b/arch/arm/boot/dts/exynos5410.dtsi
index 4603356..e2b58f8 100644
--- a/arch/arm/boot/dts/exynos5410.dtsi
+++ b/arch/arm/boot/dts/exynos5410.dtsi
@@ -101,6 +101,11 @@
reg = <0x1000 0x100>;
};
+ sromc: sromc@1225 {
+ compatible = "samsung,exynos-srom";
+ reg = <0x1225 0x14>;
+ };
+
pmu_system_controller: system-controller@1004 {
compatible = "samsung,exynos5410-pmu", "syscon";
reg = <0x1004 0x5000>;
--
2.4.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: PING: [PATCH] net: smsc911x: Reset PHY during initialization
Hello! > >> If you think I should reconsider the patch, you should resubmit it. > > > > I understand this, of course. But, before doing this i'd like to > > clarify your concern, why exactly you think that loopback test will > > break. > > If I didn't reply it means I don't have anything constructive to say > to you, and probably I'll end up agreeing with your analysis of the > loopback test issue. > > I'm not going to ask more than one more time for you to repost your > patch. But, in this case, i don't have anything to change, do i? Or is it just a formal requirement to RESEND? I can do this, if you want to. Kind regards, Pavel Fedin Expert Engineer Samsung Electronics Research center Russia -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH v7 1/4] Documentation: dt-bindings: Describe SROMc configuration
Hello! > >> > +- samsung,srom-timing : array of 6 integers, specifying bank timings in > >> > the > >> > +following order: Tacp, Tcah, Tcoh, Tacc, Tcos, > >> > Tacs. > >> > +Each value is specified in cycles and has the > >> > following > >> > +meaning and valid range: > >> > +Tacp : Page mode access cycle at Page mode (0 - > >> > 15) > >> > +Tcah : Address holding time after CSn (0 - 15) > >> > +Tcoh : Chip selection hold on OEn (0 - 15) > >> > +Tacc : Access cycle (0 - 31, the actual time is > >> > N + 1) > >> > +Tcos : Chip selection set-up before OEn (0 - 15) > >> > +Tacs : Address set-up before CSn (0 - 15) > >> > >> This is not easily extended. Perhaps a property per value instead. > > > > We had a discussion with Krzysztof about it, he agreed with this form of > > the property. > > My concern was that it's just too much typing, and makes little sense > > because these > > settings always go together. If register layout changes, or parameter set > > changes in > > incompatible way, then it's another device, not exynos-srom anymore. > > So would you agree with that, or is your position strong? > > I'm thinking for a new version of the controller which could add (or > remove) new timing parameters, but then I guess you can interpret the > field differently based on the compatible string. Anyway, your problem > to deal with. Of course, my thought is that if compatible string is different, then it's already a different device. And of course it would have different parameters. So, OK, i'll post new version with fixed documentation today. Kind regards, Pavel Fedin Expert Engineer Samsung Electronics Research center Russia -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: PING: [PATCH] net: smsc911x: Reset PHY during initialization
Hello! > >> If you think I should reconsider the patch, you should resubmit it. > > > > I understand this, of course. But, before doing this i'd like to > > clarify your concern, why exactly you think that loopback test will > > break. > > If I didn't reply it means I don't have anything constructive to say > to you, and probably I'll end up agreeing with your analysis of the > loopback test issue. > > I'm not going to ask more than one more time for you to repost your > patch. But, in this case, i don't have anything to change, do i? Or is it just a formal requirement to RESEND? I can do this, if you want to. Kind regards, Pavel Fedin Expert Engineer Samsung Electronics Research center Russia -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH v7 1/4] Documentation: dt-bindings: Describe SROMc configuration
Hello! > >> > +- samsung,srom-timing : array of 6 integers, specifying bank timings in > >> > the > >> > +following order: Tacp, Tcah, Tcoh, Tacc, Tcos, > >> > Tacs. > >> > +Each value is specified in cycles and has the > >> > following > >> > +meaning and valid range: > >> > +Tacp : Page mode access cycle at Page mode (0 - > >> > 15) > >> > +Tcah : Address holding time after CSn (0 - 15) > >> > +Tcoh : Chip selection hold on OEn (0 - 15) > >> > +Tacc : Access cycle (0 - 31, the actual time is > >> > N + 1) > >> > +Tcos : Chip selection set-up before OEn (0 - 15) > >> > +Tacs : Address set-up before CSn (0 - 15) > >> > >> This is not easily extended. Perhaps a property per value instead. > > > > We had a discussion with Krzysztof about it, he agreed with this form of > > the property. > > My concern was that it's just too much typing, and makes little sense > > because these > > settings always go together. If register layout changes, or parameter set > > changes in > > incompatible way, then it's another device, not exynos-srom anymore. > > So would you agree with that, or is your position strong? > > I'm thinking for a new version of the controller which could add (or > remove) new timing parameters, but then I guess you can interpret the > field differently based on the compatible string. Anyway, your problem > to deal with. Of course, my thought is that if compatible string is different, then it's already a different device. And of course it would have different parameters. So, OK, i'll post new version with fixed documentation today. Kind regards, Pavel Fedin Expert Engineer Samsung Electronics Research center Russia -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: PING: [PATCH] net: smsc911x: Reset PHY during initialization
Hello!
> If you think I should reconsider the patch, you should resubmit it.
I understand this, of course. But, before doing this i'd like to
clarify your concern, why exactly you think that loopback test will
break. Because the (simplified) algorithm is:
do {
result = loopback_test()
if (result == failed)
reset_phy()
} while (result == ok)
So, if loopback test works for the first time, PHY reset will never
be done. So, the conclusion is: in real situation it is never used at all.
Conclusion no 2, coming from my tests: if loopback test fails, phy reset
actually does not fix it. So, perhaps, it's not needed there at all.
I understand, that some other boards might behave differently, and loopback
test was written this very way for some reason. Also, i
understand that you, as a maintainer, have rights for the final decision. And
in order to rework the patch, i'd like to discuss with
you, which rework you would prefer. I came up with three possibilities:
--- cut ---
a) Leave PHY reset inside loopback test as it is, but add a second routine and
call it only before smsc911x_soft_reset().
b) Reset PHY only conditionally, using the following algorithm:
if smsc911x_soft_reset() {
/* NIC reset failed, kick the PHY and retry */
smsc911x_phy_reset()
if (smsc_911x_soft_reset())
return -ENODEV;
}
c) Do extra PHY reset only if some hint in device tree is specified (or the
machine is known to have the problem)
--- cut ---
I can even try to guess your thoughts (because you never elaborated them for
me):
1. loopback test will break because PHY has been reset before. In this case,
(b) or (c) is a way to go.
2. loopback test will break because of reset method change. In this case (a)
is the way to go.
So, what do you really think?
BTW, where is Steve, whose address is specified in MAINTAINERS for this code?
Is it abandonware?
Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH v7 1/4] Documentation: dt-bindings: Describe SROMc configuration
Hello!
> > +- samsung,srom-timing : array of 6 integers, specifying bank timings in the
> > +following order: Tacp, Tcah, Tcoh, Tacc, Tcos,
> > Tacs.
> > +Each value is specified in cycles and has the
> > following
> > +meaning and valid range:
> > +Tacp : Page mode access cycle at Page mode (0 - 15)
> > +Tcah : Address holding time after CSn (0 - 15)
> > +Tcoh : Chip selection hold on OEn (0 - 15)
> > +Tacc : Access cycle (0 - 31, the actual time is N
> > + 1)
> > +Tcos : Chip selection set-up before OEn (0 - 15)
> > +Tacs : Address set-up before CSn (0 - 15)
>
> This is not easily extended. Perhaps a property per value instead.
We had a discussion with Krzysztof about it, he agreed with this form of the
property.
My concern was that it's just too much typing, and makes little sense because
these
settings always go together. If register layout changes, or parameter set
changes in
incompatible way, then it's another device, not exynos-srom anymore.
So would you agree with that, or is your position strong?
> > compatible = "samsung,exynos-srom";
> > - reg = <0x1257 0x10>;
> > + reg = <0x1257 0x14>;
> > +
> > + ethernet@3 {
> > + compatible = "smsc,lan9115";
> > + reg = <3 0 0x1>; // Bank 3, offset = 0
> > + phy-mode = "mii";
> > + interrupt-parent = <>;
> > + interrupts = <5 8>;
> > + reg-io-width = <2>;
> > + smsc,irq-push-pull;
> > + smsc,force-internal-phy;
> > +
> > + samsung,srom-config = <1 9 12 1 9 1 1>;
>
> This doesn't match the doc.
Damn, overlooked. :(
Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: PING: [PATCH] net: smsc911x: Reset PHY during initialization
Hello!
> If you think I should reconsider the patch, you should resubmit it.
I understand this, of course. But, before doing this i'd like to
clarify your concern, why exactly you think that loopback test will
break. Because the (simplified) algorithm is:
do {
result = loopback_test()
if (result == failed)
reset_phy()
} while (result == ok)
So, if loopback test works for the first time, PHY reset will never
be done. So, the conclusion is: in real situation it is never used at all.
Conclusion no 2, coming from my tests: if loopback test fails, phy reset
actually does not fix it. So, perhaps, it's not needed there at all.
I understand, that some other boards might behave differently, and loopback
test was written this very way for some reason. Also, i
understand that you, as a maintainer, have rights for the final decision. And
in order to rework the patch, i'd like to discuss with
you, which rework you would prefer. I came up with three possibilities:
--- cut ---
a) Leave PHY reset inside loopback test as it is, but add a second routine and
call it only before smsc911x_soft_reset().
b) Reset PHY only conditionally, using the following algorithm:
if smsc911x_soft_reset() {
/* NIC reset failed, kick the PHY and retry */
smsc911x_phy_reset()
if (smsc_911x_soft_reset())
return -ENODEV;
}
c) Do extra PHY reset only if some hint in device tree is specified (or the
machine is known to have the problem)
--- cut ---
I can even try to guess your thoughts (because you never elaborated them for
me):
1. loopback test will break because PHY has been reset before. In this case,
(b) or (c) is a way to go.
2. loopback test will break because of reset method change. In this case (a)
is the way to go.
So, what do you really think?
BTW, where is Steve, whose address is specified in MAINTAINERS for this code?
Is it abandonware?
Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH v7 1/4] Documentation: dt-bindings: Describe SROMc configuration
Hello!
> > +- samsung,srom-timing : array of 6 integers, specifying bank timings in the
> > +following order: Tacp, Tcah, Tcoh, Tacc, Tcos,
> > Tacs.
> > +Each value is specified in cycles and has the
> > following
> > +meaning and valid range:
> > +Tacp : Page mode access cycle at Page mode (0 - 15)
> > +Tcah : Address holding time after CSn (0 - 15)
> > +Tcoh : Chip selection hold on OEn (0 - 15)
> > +Tacc : Access cycle (0 - 31, the actual time is N
> > + 1)
> > +Tcos : Chip selection set-up before OEn (0 - 15)
> > +Tacs : Address set-up before CSn (0 - 15)
>
> This is not easily extended. Perhaps a property per value instead.
We had a discussion with Krzysztof about it, he agreed with this form of the
property.
My concern was that it's just too much typing, and makes little sense because
these
settings always go together. If register layout changes, or parameter set
changes in
incompatible way, then it's another device, not exynos-srom anymore.
So would you agree with that, or is your position strong?
> > compatible = "samsung,exynos-srom";
> > - reg = <0x1257 0x10>;
> > + reg = <0x1257 0x14>;
> > +
> > + ethernet@3 {
> > + compatible = "smsc,lan9115";
> > + reg = <3 0 0x1>; // Bank 3, offset = 0
> > + phy-mode = "mii";
> > + interrupt-parent = <>;
> > + interrupts = <5 8>;
> > + reg-io-width = <2>;
> > + smsc,irq-push-pull;
> > + smsc,force-internal-phy;
> > +
> > + samsung,srom-config = <1 9 12 1 9 1 1>;
>
> This doesn't match the doc.
Damn, overlooked. :(
Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
PING: [PATCH] net: smsc911x: Reset PHY during initialization
Hello! So, what should we do with this?
Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia
> -Original Message-
> From: netdev-ow...@vger.kernel.org [mailto:netdev-ow...@vger.kernel.org] On
> Behalf Of Pavel
> Fedin
> Sent: Monday, November 02, 2015 10:19 AM
> To: 'David Miller'
> Cc: net...@vger.kernel.org; linux-kernel@vger.kernel.org;
> steve.glendinn...@shawell.net
> Subject: RE: [PATCH] net: smsc911x: Reset PHY during initialization
>
> Hello!
>
> > > On certain hardware after software reboot the chip may get stuck and fail
> > > to reinitialize during reset. This can be fixed by ensuring that PHY is
> > > reset too.
> > >
> > > Old PHY resetting method required operational MDIO interface, therefore
> > > the chip should have been already set up. In order to be able to function
> > > during probe, it is changed to use PMT_CTRL register.
> > >
> > > The problem could be observed on SMDK5410 board.
> > >
> > > Signed-off-by: Pavel Fedin
> >
> > I'm pretty sure this is going to break the PHY loopback test.
>
> It's not (at least in normal situation), because first we do the test, and
> only then, if it
> fails, we reset the PHY. So, during
> normal operation of the driver, when loopback test succeeds at first attempt,
> we never attempt
> to reset the PHY. And, by the way, at
> least on my board this PHY reset did nothing useful, because after it
> loopback test still
> failed, all 100 times.
> And, we don't use PHY reset anywhere outside of loopback test.
>
> > This is such a tricky and fragile area to get right, therefore I
> > want you to specifically guard any change in how PHY reset is
> > done with tests against the specific chips that have the problem.
>
> Well, i could do one (or some combination) of the following, if you really
> want to:
> a) Leave PHY reset inside loopback test as it is, but add a second routine
> and call it only
> before smsc911x_soft_reset().
> b) Reset PHY only conditionally, using the following algorithm:
> if smsc911x_soft_reset() {
> /* NIC reset failed, kick the PHY and retry */
> smsc911x_phy_reset()
> if (smsc_911x_soft_reset())
> return -ENODEV;
> }
> c) Do extra PHY reset only if some hint in device tree is specified (or the
> machine is known
> to have the problem)
>
> But, i dislike approach (a) for code duplication, because datasheet says
> that both reset
> methods are equivalent; i dislike approach
> (b) for actually being a hack; and i dislike (c) for adding extra stuff which
> seems to be not
> necessary. After all, what is wrong
> with just extra PHY reset before attempting to program anything? By the way,
> i test my patch
> with both software reboot and hardware
> reboot, and even powercycle. Everything is quite stable.
> Well, it's up to you to decide. But i'd like to get the fix upstreamed
> somehow because from
> time to time we use these boards for
> tests, and it's quite annoiying to be unable to reboot them properly.
>
> > Furthermore, I want you to test whether this has any negative
> > effects on the PHY loopback test.
>
> I did. I never disabled loopback test, so i actually discovered a problem
> (even two) with it.
> First, the problem was chip reset
> timeout. By increasing it to 300ms this problem seemed to be fixed, but
> loopback test started
> to fail. This was how i found and
> fixed crash with missing phy_disconnect(). I examined the code and discovered
> that upon
> loopback test failure we reset the PHY and
> retry. But in my case this PHY reset never did the right thing, and all
> loopback attempts
> (10x10 IIRC) were failing.
> Some comments in the code gave me a clue that the main NIC can misbehave on
> reset if e.g. PHY
> is in powerdown state. I printed
> value of its control register and discovered that it was not the case. But
> then i discovered
> that we actually never try to reset the
> PHY before doing anything. Also, while studying the datasheed i discovered
> that there is a
> shorthand for resetting PHY without MDIO
> bus set up, but our driver doesn't use it, preferring MDIO method instead,
> which already
> requires operational NIC.
> So, i suggested that PHY is just not being reset when board is rebooted by
> software. I wrote
> the patch and it worked. I verified it
> by reverting my previous NIC reset timeout increase, and it continued to
> work. After this
> loopback test on my board passes at first
> attempt.
>
> Kind regards,
> Pavel Fedin
> Expert Engineer
> Sam
PING: [PATCH] net: smsc911x: Reset PHY during initialization
Hello! So, what should we do with this?
Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia
> -Original Message-
> From: netdev-ow...@vger.kernel.org [mailto:netdev-ow...@vger.kernel.org] On
> Behalf Of Pavel
> Fedin
> Sent: Monday, November 02, 2015 10:19 AM
> To: 'David Miller'
> Cc: net...@vger.kernel.org; linux-kernel@vger.kernel.org;
> steve.glendinn...@shawell.net
> Subject: RE: [PATCH] net: smsc911x: Reset PHY during initialization
>
> Hello!
>
> > > On certain hardware after software reboot the chip may get stuck and fail
> > > to reinitialize during reset. This can be fixed by ensuring that PHY is
> > > reset too.
> > >
> > > Old PHY resetting method required operational MDIO interface, therefore
> > > the chip should have been already set up. In order to be able to function
> > > during probe, it is changed to use PMT_CTRL register.
> > >
> > > The problem could be observed on SMDK5410 board.
> > >
> > > Signed-off-by: Pavel Fedin <p.fe...@samsung.com>
> >
> > I'm pretty sure this is going to break the PHY loopback test.
>
> It's not (at least in normal situation), because first we do the test, and
> only then, if it
> fails, we reset the PHY. So, during
> normal operation of the driver, when loopback test succeeds at first attempt,
> we never attempt
> to reset the PHY. And, by the way, at
> least on my board this PHY reset did nothing useful, because after it
> loopback test still
> failed, all 100 times.
> And, we don't use PHY reset anywhere outside of loopback test.
>
> > This is such a tricky and fragile area to get right, therefore I
> > want you to specifically guard any change in how PHY reset is
> > done with tests against the specific chips that have the problem.
>
> Well, i could do one (or some combination) of the following, if you really
> want to:
> a) Leave PHY reset inside loopback test as it is, but add a second routine
> and call it only
> before smsc911x_soft_reset().
> b) Reset PHY only conditionally, using the following algorithm:
> if smsc911x_soft_reset() {
> /* NIC reset failed, kick the PHY and retry */
> smsc911x_phy_reset()
> if (smsc_911x_soft_reset())
> return -ENODEV;
> }
> c) Do extra PHY reset only if some hint in device tree is specified (or the
> machine is known
> to have the problem)
>
> But, i dislike approach (a) for code duplication, because datasheet says
> that both reset
> methods are equivalent; i dislike approach
> (b) for actually being a hack; and i dislike (c) for adding extra stuff which
> seems to be not
> necessary. After all, what is wrong
> with just extra PHY reset before attempting to program anything? By the way,
> i test my patch
> with both software reboot and hardware
> reboot, and even powercycle. Everything is quite stable.
> Well, it's up to you to decide. But i'd like to get the fix upstreamed
> somehow because from
> time to time we use these boards for
> tests, and it's quite annoiying to be unable to reboot them properly.
>
> > Furthermore, I want you to test whether this has any negative
> > effects on the PHY loopback test.
>
> I did. I never disabled loopback test, so i actually discovered a problem
> (even two) with it.
> First, the problem was chip reset
> timeout. By increasing it to 300ms this problem seemed to be fixed, but
> loopback test started
> to fail. This was how i found and
> fixed crash with missing phy_disconnect(). I examined the code and discovered
> that upon
> loopback test failure we reset the PHY and
> retry. But in my case this PHY reset never did the right thing, and all
> loopback attempts
> (10x10 IIRC) were failing.
> Some comments in the code gave me a clue that the main NIC can misbehave on
> reset if e.g. PHY
> is in powerdown state. I printed
> value of its control register and discovered that it was not the case. But
> then i discovered
> that we actually never try to reset the
> PHY before doing anything. Also, while studying the datasheed i discovered
> that there is a
> shorthand for resetting PHY without MDIO
> bus set up, but our driver doesn't use it, preferring MDIO method instead,
> which already
> requires operational NIC.
> So, i suggested that PHY is just not being reset when board is rebooted by
> software. I wrote
> the patch and it worked. I verified it
> by reverting my previous NIC reset timeout increase, and it continued to
> work. After this
> loopback test on my board passes at first
> attempt.
>
> Kind regards,
> Pavel Fedin
>
[PATCH v7 4/4] ARM: dts: Add Ethernet chip to SMDK5410
The chip is smsc9115, connected via SROMc bank 3. Additionally, some GPIO
initialization is required.
Signed-off-by: Pavel Fedin
Reviewed-by: Krzysztof Kozlowski
---
arch/arm/boot/dts/exynos5410-smdk5410.dts | 41 +++
arch/arm/boot/dts/exynos5410.dtsi | 6 +
2 files changed, 47 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5410-smdk5410.dts
b/arch/arm/boot/dts/exynos5410-smdk5410.dts
index cebeaab..373abf7 100644
--- a/arch/arm/boot/dts/exynos5410-smdk5410.dts
+++ b/arch/arm/boot/dts/exynos5410-smdk5410.dts
@@ -11,6 +11,7 @@
/dts-v1/;
#include "exynos5410.dtsi"
+#include
/ {
model = "Samsung SMDK5410 board based on EXYNOS5410";
compatible = "samsung,smdk5410", "samsung,exynos5410",
"samsung,exynos5";
@@ -61,6 +62,46 @@
disable-wp;
};
+_0 {
+ srom_ctl: srom-ctl {
+ samsung,pins = "gpy0-3", "gpy0-4", "gpy0-5",
+ "gpy1-0", "gpy1-1", "gpy1-2", "gpy1-3";
+ samsung,pin-function = <2>;
+ samsung,pin-drv = <0>;
+ };
+
+ srom_ebi: srom-ebi {
+ samsung,pins = "gpy3-0", "gpy3-1", "gpy3-2", "gpy3-3",
+ "gpy3-4", "gpy3-5", "gpy3-6", "gpy3-7",
+ "gpy5-0", "gpy5-1", "gpy5-2", "gpy5-3",
+ "gpy5-4", "gpy5-5", "gpy5-6", "gpy5-7",
+ "gpy6-0", "gpy6-1", "gpy6-2", "gpy6-3",
+ "gpy6-4", "gpy6-5", "gpy6-6", "gpy6-7";
+ samsung,pin-function = <2>;
+ samsung,pin-pud = <3>;
+ samsung,pin-drv = <0>;
+ };
+};
+
+ {
+ pinctrl-names = "default";
+ pinctrl-0 = <_ctl>, <_ebi>;
+
+ ethernet@3 {
+ compatible = "smsc,lan9115";
+ reg = <3 0 0x1>;
+ phy-mode = "mii";
+ interrupt-parent = <>;
+ interrupts = <5 IRQ_TYPE_LEVEL_LOW>;
+ reg-io-width = <2>;
+ smsc,irq-push-pull;
+ smsc,force-internal-phy;
+
+ samsung,srom-page-mode = <1>;
+ samsung,srom-timing = <9 12 1 9 1 1>;
+ };
+};
+
{
status = "okay";
};
diff --git a/arch/arm/boot/dts/exynos5410.dtsi
b/arch/arm/boot/dts/exynos5410.dtsi
index e2b58f8..9cfb814 100644
--- a/arch/arm/boot/dts/exynos5410.dtsi
+++ b/arch/arm/boot/dts/exynos5410.dtsi
@@ -104,6 +104,12 @@
sromc: sromc@1225 {
compatible = "samsung,exynos-srom";
reg = <0x1225 0x14>;
+ #address-cells = <2>;
+ #size-cells = <1>;
+ ranges = <0 0 0x0400 0x2
+ 1 0 0x0500 0x2
+ 2 0 0x0600 0x2
+ 3 0 0x0700 0x2>;
};
pmu_system_controller: system-controller@1004 {
--
2.4.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v7 2/4] ARM: dts: Add SROMc to Exynos 5410
This machine uses own SoC device tree file, add missing part.
Signed-off-by: Pavel Fedin
Reviewed-by: Krzysztof Kozlowski
---
arch/arm/boot/dts/exynos5410.dtsi | 5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5410.dtsi
b/arch/arm/boot/dts/exynos5410.dtsi
index 4603356..e2b58f8 100644
--- a/arch/arm/boot/dts/exynos5410.dtsi
+++ b/arch/arm/boot/dts/exynos5410.dtsi
@@ -101,6 +101,11 @@
reg = <0x1000 0x100>;
};
+ sromc: sromc@1225 {
+ compatible = "samsung,exynos-srom";
+ reg = <0x1225 0x14>;
+ };
+
pmu_system_controller: system-controller@1004 {
compatible = "samsung,exynos5410-pmu", "syscon";
reg = <0x1004 0x5000>;
--
2.4.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v7 1/4] Documentation: dt-bindings: Describe SROMc configuration
Add documentation for new subnode properties, allowing bank configuration.
Based on u-boot implementation, but heavily reworked.
Also, fix size of SROMc mapping in the example.
Signed-off-by: Pavel Fedin
Reviewed-by: Krzysztof Kozlowski
---
.../bindings/arm/samsung/exynos-srom.txt | 71 +-
1 file changed, 69 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/arm/samsung/exynos-srom.txt
b/Documentation/devicetree/bindings/arm/samsung/exynos-srom.txt
index 33886d5..3ff2950 100644
--- a/Documentation/devicetree/bindings/arm/samsung/exynos-srom.txt
+++ b/Documentation/devicetree/bindings/arm/samsung/exynos-srom.txt
@@ -5,8 +5,75 @@ Required properties:
- reg: offset and length of the register set
-Example:
+Optional properties:
+The SROM controller can be used to attach external peripherals. In this case
+extra properties, describing the bus behind it, should be specified as below:
+
+- #address-cells: Must be set to 2 to allow memory address translation
+
+- #size-cells: Must be set to 1 to allow CS address passing
+
+- ranges: Must be set up to reflect the memory layout with four integer values
+ per bank:
+0
+
+Sub-nodes:
+The actual device nodes should be added as subnodes to the SROMc node. These
+subnodes, except regular device specification, should contain the following
+properties, describing configuration of the relevant SROM bank:
+
+Required properties:
+- reg: bank number, base address (relative to start of the bank) and size of
+ the memory mapped for the device. Note that base address will be
+ typically 0 as this is the start of the bank.
+
+- samsung,srom-timing : array of 6 integers, specifying bank timings in the
+following order: Tacp, Tcah, Tcoh, Tacc, Tcos, Tacs.
+Each value is specified in cycles and has the following
+meaning and valid range:
+Tacp : Page mode access cycle at Page mode (0 - 15)
+Tcah : Address holding time after CSn (0 - 15)
+Tcoh : Chip selection hold on OEn (0 - 15)
+Tacc : Access cycle (0 - 31, the actual time is N + 1)
+Tcos : Chip selection set-up before OEn (0 - 15)
+Tacs : Address set-up before CSn (0 - 15)
+
+Optional properties:
+- reg-io-width : data width in bytes (1 or 2). If omitted, default of 1 is
used.
+
+- samsung,srom-page-mode : page mode configuration for the bank:
+ 0 - normal (one data)
+ 1 - four data
+ If omitted, default of 0 is used.
+
+Example: basic definition, no banks are configured
+ sromc@1257 {
+ compatible = "samsung,exynos-srom";
+ reg = <0x1257 0x14>;
+ };
+
+Example: SROMc with SMSC911x ethernet chip on bank 3
sromc@1257 {
+ #address-cells = <2>;
+ #size-cells = <1>;
+ ranges = <0 0 0x0400 0x2 // Bank0
+ 1 0 0x0500 0x2 // Bank1
+ 2 0 0x0600 0x2 // Bank2
+ 3 0 0x0700 0x2>; // Bank3
+
compatible = "samsung,exynos-srom";
- reg = <0x1257 0x10>;
+ reg = <0x1257 0x14>;
+
+ ethernet@3 {
+ compatible = "smsc,lan9115";
+ reg = <3 0 0x1>; // Bank 3, offset = 0
+ phy-mode = "mii";
+ interrupt-parent = <>;
+ interrupts = <5 8>;
+ reg-io-width = <2>;
+ smsc,irq-push-pull;
+ smsc,force-internal-phy;
+
+ samsung,srom-config = <1 9 12 1 9 1 1>;
+ };
};
--
2.4.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v7 0/4] Exynos SROMc configuration and Ethernet support for SMDK5410
This patch extends Exynos SROM controller driver with ability to configure
controller outputs and enables SMSC9115 Ethernet chip on SMDK5410 board,
which is connected via SROMc bank #3.
With this patchset, support for the whole existing SMDK range can be added.
Actually, only bank number is different.
This patchset also depends on Exynos 5410 pinctrl support, introduced by
patches 0003 and 0004 from this set:
[PATCH v4 0/5] ARM: EXYNOS: ODROID-XU DT and LEDs
http://lists.infradead.org/pipermail/linux-arm-kernel/2015-March/330862.html
Pinctrl support is necessary in order to correctly configure
multifunctional pins of the Exynos chip.
v6 => v7:
- Fixed stupid error in Tacc description in the documentation
v5 => v6:
- Even more improvements to the documentation, fixed some errors and typos.
- Separated adding bus ranges from generic SROMc support
- Some stuff renamed for even better code readability
- Stylistic cleanups in the DTS (everything in alphabetic order, use named
constant name for interrupt config byte)
v4 => v5:
- Some cosmetic changes in the dtsi ("compatible" goes first)
- Use correctly specified ranges for the SROMc node
- Reuse existing properties where possible ("reg" for bank# and
"reg-io-width" for data width)
- Separated page-mode property from timings array
- More improvements to the documentation
v3 => v4:
- Devices are now added as subnodes, with additional properties. This allows
to cleary specify dependency. If configuration fails, error will be reported
and child devices will not be probed.
- These additional properties now have "samsung,srom-XXX" format
- Fixed code style, now better understood.
v2 => v3:
- Fixed up SROMc region size in the device tree
- Reordered patches, documentation goes first now
v1 => v2:
- Fixed some typos and bad labels in device tree
- Improved documentation
Pavel Fedin (4):
Documentation: dt-bindings: Describe SROMc configuration
ARM: dts: Add SROMc to Exynos 5410
drivers: exynos-srom: Add support for bank configuration
ARM: dts: Add Ethernet chip to SMDK5410
.../bindings/arm/samsung/exynos-srom.txt | 71 +-
arch/arm/boot/dts/exynos5410-smdk5410.dts | 41 +
arch/arm/boot/dts/exynos5410.dtsi | 11
arch/arm/mach-exynos/Kconfig | 2 +-
drivers/soc/samsung/Kconfig| 2 +-
drivers/soc/samsung/exynos-srom.c | 61 ++-
6 files changed, 182 insertions(+), 6 deletions(-)
--
2.4.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v7 3/4] drivers: exynos-srom: Add support for bank configuration
Implement handling properties in subnodes and adding child devices to the
system. Child devices will not be added if configuration fails.
Since the driver now does more than suspend-resume support, dependency on
CONFIG_PM is removed.
Signed-off-by: Pavel Fedin
Reviewed-by: Krzysztof Kozlowski
---
arch/arm/mach-exynos/Kconfig | 2 +-
drivers/soc/samsung/Kconfig | 2 +-
drivers/soc/samsung/exynos-srom.c | 61 +--
3 files changed, 61 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig
index 83c85f5..c22dc42 100644
--- a/arch/arm/mach-exynos/Kconfig
+++ b/arch/arm/mach-exynos/Kconfig
@@ -16,7 +16,7 @@ menuconfig ARCH_EXYNOS
select ARM_GIC
select COMMON_CLK_SAMSUNG
select EXYNOS_THERMAL
- select EXYNOS_SROM if PM
+ select EXYNOS_SROM
select HAVE_ARM_SCU if SMP
select HAVE_S3C2410_I2C if I2C
select HAVE_S3C2410_WATCHDOG if WATCHDOG
diff --git a/drivers/soc/samsung/Kconfig b/drivers/soc/samsung/Kconfig
index 2833b5b..ea4bc2a 100644
--- a/drivers/soc/samsung/Kconfig
+++ b/drivers/soc/samsung/Kconfig
@@ -8,6 +8,6 @@ config SOC_SAMSUNG
config EXYNOS_SROM
bool
- depends on ARM && ARCH_EXYNOS && PM
+ depends on ARM && ARCH_EXYNOS
endmenu
diff --git a/drivers/soc/samsung/exynos-srom.c
b/drivers/soc/samsung/exynos-srom.c
index 57a232d..a4cf547 100644
--- a/drivers/soc/samsung/exynos-srom.c
+++ b/drivers/soc/samsung/exynos-srom.c
@@ -14,6 +14,7 @@
#include
#include
#include
+#include
#include
#include
@@ -67,11 +68,51 @@ static struct exynos_srom_reg_dump
*exynos_srom_alloc_reg_dump(
return rd;
}
+static int exynos_srom_configure_bank(struct exynos_srom *srom,
+ struct device_node *np)
+{
+ u32 bank, width, pmc;
+ u32 timing[6];
+ u32 cs, bw;
+
+ if (of_property_read_u32(np, "reg", ))
+ return -EINVAL;
+ if (of_property_read_u32(np, "reg-io-width", ))
+ width = 1;
+ if (of_property_read_u32(np, "samsung,srom-page-mode", ))
+ pmc = 0;
+ if (of_property_read_u32_array(np, "samsung,srom-timing", timing,
+ ARRAY_SIZE(timing)))
+ return -EINVAL;
+
+ bank *= 4; /* Convert bank into shift/offset */
+
+ cs = 1 << EXYNOS_SROM_BW__BYTEENABLE__SHIFT;
+ if (width == 2)
+ cs |= 1 << EXYNOS_SROM_BW__DATAWIDTH__SHIFT;
+
+ bw = __raw_readl(srom->reg_base + EXYNOS_SROM_BW);
+ bw = (bw & ~(EXYNOS_SROM_BW__CS_MASK << bank)) | (cs << bank);
+ __raw_writel(bw, srom->reg_base + EXYNOS_SROM_BW);
+
+ __raw_writel((pmc << EXYNOS_SROM_BCX__PMC__SHIFT) |
+ (timing[0] << EXYNOS_SROM_BCX__TACP__SHIFT) |
+ (timing[1] << EXYNOS_SROM_BCX__TCAH__SHIFT) |
+ (timing[2] << EXYNOS_SROM_BCX__TCOH__SHIFT) |
+ (timing[3] << EXYNOS_SROM_BCX__TACC__SHIFT) |
+ (timing[4] << EXYNOS_SROM_BCX__TCOS__SHIFT) |
+ (timing[5] << EXYNOS_SROM_BCX__TACS__SHIFT),
+ srom->reg_base + EXYNOS_SROM_BC0 + bank);
+
+ return 0;
+}
+
static int exynos_srom_probe(struct platform_device *pdev)
{
- struct device_node *np;
+ struct device_node *np, *child;
struct exynos_srom *srom;
struct device *dev = >dev;
+ bool bad_bank_config = false;
np = dev->of_node;
if (!np) {
@@ -100,7 +141,23 @@ static int exynos_srom_probe(struct platform_device *pdev)
return -ENOMEM;
}
- return 0;
+ for_each_child_of_node(np, child) {
+ if (exynos_srom_configure_bank(srom, child)) {
+ dev_err(dev,
+ "Could not decode bank configuration for %s\n",
+ child->name);
+ bad_bank_config = true;
+ }
+ }
+
+ /*
+* If any bank failed to configure, we still provide suspend/resume,
+* but do not probe child devices
+*/
+ if (bad_bank_config)
+ return 0;
+
+ return of_platform_populate(np, NULL, NULL, dev);
}
static int exynos_srom_remove(struct platform_device *pdev)
--
2.4.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH v6 1/4] Documentation: dt-bindings: Describe SROMc configuration
Hello! > > +- samsung,srom-timing : array of 6 integers, specifying bank timings in the > > +following order: Tacp, Tcah, Tcoh, Tacc, Tcos, > > Tacs. > > +Each value is specified in cycles and has the > > following > > +meaning and valid range: > > +Tacp : Page mode access cycle at Page mode (0 - 15) > > +Tcah : Address holding time after CSn (0 - 15) > > +Tcoh : Chip selection hold on OEn (0 - 15) > > +Tacc : Access cycle (0 - 32) > > All of the manuals have error here. Probably it can be either: 1-32 or > 0-31. I would bet on 0-31, what do you think? Damn, everything starts from 0, so i automatically put '0 - 32'. The actual time, however, varies from 1 to 32, but the value is from 0 to 31, i. e. - 1 What shall we do? Just document this, or adjust the code to take number of cycles and subtract 1? To tell the truth, i'm already sick of these small fixups, and i would prefer just to fix documentation. Kind regards, Pavel Fedin Expert Engineer Samsung Electronics Research center Russia -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH v6 1/4] Documentation: dt-bindings: Describe SROMc configuration
Hello! > > +- samsung,srom-timing : array of 6 integers, specifying bank timings in the > > +following order: Tacp, Tcah, Tcoh, Tacc, Tcos, > > Tacs. > > +Each value is specified in cycles and has the > > following > > +meaning and valid range: > > +Tacp : Page mode access cycle at Page mode (0 - 15) > > +Tcah : Address holding time after CSn (0 - 15) > > +Tcoh : Chip selection hold on OEn (0 - 15) > > +Tacc : Access cycle (0 - 32) > > All of the manuals have error here. Probably it can be either: 1-32 or > 0-31. I would bet on 0-31, what do you think? Damn, everything starts from 0, so i automatically put '0 - 32'. The actual time, however, varies from 1 to 32, but the value is from 0 to 31, i. e. - 1 What shall we do? Just document this, or adjust the code to take number of cycles and subtract 1? To tell the truth, i'm already sick of these small fixups, and i would prefer just to fix documentation. Kind regards, Pavel Fedin Expert Engineer Samsung Electronics Research center Russia -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v7 2/4] ARM: dts: Add SROMc to Exynos 5410
This machine uses own SoC device tree file, add missing part.
Signed-off-by: Pavel Fedin <p.fe...@samsung.com>
Reviewed-by: Krzysztof Kozlowski <k.kozlow...@samsung.com>
---
arch/arm/boot/dts/exynos5410.dtsi | 5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5410.dtsi
b/arch/arm/boot/dts/exynos5410.dtsi
index 4603356..e2b58f8 100644
--- a/arch/arm/boot/dts/exynos5410.dtsi
+++ b/arch/arm/boot/dts/exynos5410.dtsi
@@ -101,6 +101,11 @@
reg = <0x1000 0x100>;
};
+ sromc: sromc@1225 {
+ compatible = "samsung,exynos-srom";
+ reg = <0x1225 0x14>;
+ };
+
pmu_system_controller: system-controller@1004 {
compatible = "samsung,exynos5410-pmu", "syscon";
reg = <0x1004 0x5000>;
--
2.4.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v7 0/4] Exynos SROMc configuration and Ethernet support for SMDK5410
This patch extends Exynos SROM controller driver with ability to configure
controller outputs and enables SMSC9115 Ethernet chip on SMDK5410 board,
which is connected via SROMc bank #3.
With this patchset, support for the whole existing SMDK range can be added.
Actually, only bank number is different.
This patchset also depends on Exynos 5410 pinctrl support, introduced by
patches 0003 and 0004 from this set:
[PATCH v4 0/5] ARM: EXYNOS: ODROID-XU DT and LEDs
http://lists.infradead.org/pipermail/linux-arm-kernel/2015-March/330862.html
Pinctrl support is necessary in order to correctly configure
multifunctional pins of the Exynos chip.
v6 => v7:
- Fixed stupid error in Tacc description in the documentation
v5 => v6:
- Even more improvements to the documentation, fixed some errors and typos.
- Separated adding bus ranges from generic SROMc support
- Some stuff renamed for even better code readability
- Stylistic cleanups in the DTS (everything in alphabetic order, use named
constant name for interrupt config byte)
v4 => v5:
- Some cosmetic changes in the dtsi ("compatible" goes first)
- Use correctly specified ranges for the SROMc node
- Reuse existing properties where possible ("reg" for bank# and
"reg-io-width" for data width)
- Separated page-mode property from timings array
- More improvements to the documentation
v3 => v4:
- Devices are now added as subnodes, with additional properties. This allows
to cleary specify dependency. If configuration fails, error will be reported
and child devices will not be probed.
- These additional properties now have "samsung,srom-XXX" format
- Fixed code style, now better understood.
v2 => v3:
- Fixed up SROMc region size in the device tree
- Reordered patches, documentation goes first now
v1 => v2:
- Fixed some typos and bad labels in device tree
- Improved documentation
Pavel Fedin (4):
Documentation: dt-bindings: Describe SROMc configuration
ARM: dts: Add SROMc to Exynos 5410
drivers: exynos-srom: Add support for bank configuration
ARM: dts: Add Ethernet chip to SMDK5410
.../bindings/arm/samsung/exynos-srom.txt | 71 +-
arch/arm/boot/dts/exynos5410-smdk5410.dts | 41 +
arch/arm/boot/dts/exynos5410.dtsi | 11
arch/arm/mach-exynos/Kconfig | 2 +-
drivers/soc/samsung/Kconfig| 2 +-
drivers/soc/samsung/exynos-srom.c | 61 ++-
6 files changed, 182 insertions(+), 6 deletions(-)
--
2.4.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v7 3/4] drivers: exynos-srom: Add support for bank configuration
Implement handling properties in subnodes and adding child devices to the
system. Child devices will not be added if configuration fails.
Since the driver now does more than suspend-resume support, dependency on
CONFIG_PM is removed.
Signed-off-by: Pavel Fedin <p.fe...@samsung.com>
Reviewed-by: Krzysztof Kozlowski <k.kozlow...@samsung.com>
---
arch/arm/mach-exynos/Kconfig | 2 +-
drivers/soc/samsung/Kconfig | 2 +-
drivers/soc/samsung/exynos-srom.c | 61 +--
3 files changed, 61 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig
index 83c85f5..c22dc42 100644
--- a/arch/arm/mach-exynos/Kconfig
+++ b/arch/arm/mach-exynos/Kconfig
@@ -16,7 +16,7 @@ menuconfig ARCH_EXYNOS
select ARM_GIC
select COMMON_CLK_SAMSUNG
select EXYNOS_THERMAL
- select EXYNOS_SROM if PM
+ select EXYNOS_SROM
select HAVE_ARM_SCU if SMP
select HAVE_S3C2410_I2C if I2C
select HAVE_S3C2410_WATCHDOG if WATCHDOG
diff --git a/drivers/soc/samsung/Kconfig b/drivers/soc/samsung/Kconfig
index 2833b5b..ea4bc2a 100644
--- a/drivers/soc/samsung/Kconfig
+++ b/drivers/soc/samsung/Kconfig
@@ -8,6 +8,6 @@ config SOC_SAMSUNG
config EXYNOS_SROM
bool
- depends on ARM && ARCH_EXYNOS && PM
+ depends on ARM && ARCH_EXYNOS
endmenu
diff --git a/drivers/soc/samsung/exynos-srom.c
b/drivers/soc/samsung/exynos-srom.c
index 57a232d..a4cf547 100644
--- a/drivers/soc/samsung/exynos-srom.c
+++ b/drivers/soc/samsung/exynos-srom.c
@@ -14,6 +14,7 @@
#include
#include
#include
+#include
#include
#include
@@ -67,11 +68,51 @@ static struct exynos_srom_reg_dump
*exynos_srom_alloc_reg_dump(
return rd;
}
+static int exynos_srom_configure_bank(struct exynos_srom *srom,
+ struct device_node *np)
+{
+ u32 bank, width, pmc;
+ u32 timing[6];
+ u32 cs, bw;
+
+ if (of_property_read_u32(np, "reg", ))
+ return -EINVAL;
+ if (of_property_read_u32(np, "reg-io-width", ))
+ width = 1;
+ if (of_property_read_u32(np, "samsung,srom-page-mode", ))
+ pmc = 0;
+ if (of_property_read_u32_array(np, "samsung,srom-timing", timing,
+ ARRAY_SIZE(timing)))
+ return -EINVAL;
+
+ bank *= 4; /* Convert bank into shift/offset */
+
+ cs = 1 << EXYNOS_SROM_BW__BYTEENABLE__SHIFT;
+ if (width == 2)
+ cs |= 1 << EXYNOS_SROM_BW__DATAWIDTH__SHIFT;
+
+ bw = __raw_readl(srom->reg_base + EXYNOS_SROM_BW);
+ bw = (bw & ~(EXYNOS_SROM_BW__CS_MASK << bank)) | (cs << bank);
+ __raw_writel(bw, srom->reg_base + EXYNOS_SROM_BW);
+
+ __raw_writel((pmc << EXYNOS_SROM_BCX__PMC__SHIFT) |
+ (timing[0] << EXYNOS_SROM_BCX__TACP__SHIFT) |
+ (timing[1] << EXYNOS_SROM_BCX__TCAH__SHIFT) |
+ (timing[2] << EXYNOS_SROM_BCX__TCOH__SHIFT) |
+ (timing[3] << EXYNOS_SROM_BCX__TACC__SHIFT) |
+ (timing[4] << EXYNOS_SROM_BCX__TCOS__SHIFT) |
+ (timing[5] << EXYNOS_SROM_BCX__TACS__SHIFT),
+ srom->reg_base + EXYNOS_SROM_BC0 + bank);
+
+ return 0;
+}
+
static int exynos_srom_probe(struct platform_device *pdev)
{
- struct device_node *np;
+ struct device_node *np, *child;
struct exynos_srom *srom;
struct device *dev = >dev;
+ bool bad_bank_config = false;
np = dev->of_node;
if (!np) {
@@ -100,7 +141,23 @@ static int exynos_srom_probe(struct platform_device *pdev)
return -ENOMEM;
}
- return 0;
+ for_each_child_of_node(np, child) {
+ if (exynos_srom_configure_bank(srom, child)) {
+ dev_err(dev,
+ "Could not decode bank configuration for %s\n",
+ child->name);
+ bad_bank_config = true;
+ }
+ }
+
+ /*
+* If any bank failed to configure, we still provide suspend/resume,
+* but do not probe child devices
+*/
+ if (bad_bank_config)
+ return 0;
+
+ return of_platform_populate(np, NULL, NULL, dev);
}
static int exynos_srom_remove(struct platform_device *pdev)
--
2.4.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v7 1/4] Documentation: dt-bindings: Describe SROMc configuration
Add documentation for new subnode properties, allowing bank configuration.
Based on u-boot implementation, but heavily reworked.
Also, fix size of SROMc mapping in the example.
Signed-off-by: Pavel Fedin <p.fe...@samsung.com>
Reviewed-by: Krzysztof Kozlowski <k.kozlow...@samsung.com>
---
.../bindings/arm/samsung/exynos-srom.txt | 71 +-
1 file changed, 69 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/arm/samsung/exynos-srom.txt
b/Documentation/devicetree/bindings/arm/samsung/exynos-srom.txt
index 33886d5..3ff2950 100644
--- a/Documentation/devicetree/bindings/arm/samsung/exynos-srom.txt
+++ b/Documentation/devicetree/bindings/arm/samsung/exynos-srom.txt
@@ -5,8 +5,75 @@ Required properties:
- reg: offset and length of the register set
-Example:
+Optional properties:
+The SROM controller can be used to attach external peripherals. In this case
+extra properties, describing the bus behind it, should be specified as below:
+
+- #address-cells: Must be set to 2 to allow memory address translation
+
+- #size-cells: Must be set to 1 to allow CS address passing
+
+- ranges: Must be set up to reflect the memory layout with four integer values
+ per bank:
+0
+
+Sub-nodes:
+The actual device nodes should be added as subnodes to the SROMc node. These
+subnodes, except regular device specification, should contain the following
+properties, describing configuration of the relevant SROM bank:
+
+Required properties:
+- reg: bank number, base address (relative to start of the bank) and size of
+ the memory mapped for the device. Note that base address will be
+ typically 0 as this is the start of the bank.
+
+- samsung,srom-timing : array of 6 integers, specifying bank timings in the
+following order: Tacp, Tcah, Tcoh, Tacc, Tcos, Tacs.
+Each value is specified in cycles and has the following
+meaning and valid range:
+Tacp : Page mode access cycle at Page mode (0 - 15)
+Tcah : Address holding time after CSn (0 - 15)
+Tcoh : Chip selection hold on OEn (0 - 15)
+Tacc : Access cycle (0 - 31, the actual time is N + 1)
+Tcos : Chip selection set-up before OEn (0 - 15)
+Tacs : Address set-up before CSn (0 - 15)
+
+Optional properties:
+- reg-io-width : data width in bytes (1 or 2). If omitted, default of 1 is
used.
+
+- samsung,srom-page-mode : page mode configuration for the bank:
+ 0 - normal (one data)
+ 1 - four data
+ If omitted, default of 0 is used.
+
+Example: basic definition, no banks are configured
+ sromc@1257 {
+ compatible = "samsung,exynos-srom";
+ reg = <0x1257 0x14>;
+ };
+
+Example: SROMc with SMSC911x ethernet chip on bank 3
sromc@1257 {
+ #address-cells = <2>;
+ #size-cells = <1>;
+ ranges = <0 0 0x0400 0x2 // Bank0
+ 1 0 0x0500 0x2 // Bank1
+ 2 0 0x0600 0x2 // Bank2
+ 3 0 0x0700 0x2>; // Bank3
+
compatible = "samsung,exynos-srom";
- reg = <0x1257 0x10>;
+ reg = <0x1257 0x14>;
+
+ ethernet@3 {
+ compatible = "smsc,lan9115";
+ reg = <3 0 0x1>; // Bank 3, offset = 0
+ phy-mode = "mii";
+ interrupt-parent = <>;
+ interrupts = <5 8>;
+ reg-io-width = <2>;
+ smsc,irq-push-pull;
+ smsc,force-internal-phy;
+
+ samsung,srom-config = <1 9 12 1 9 1 1>;
+ };
};
--
2.4.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v7 4/4] ARM: dts: Add Ethernet chip to SMDK5410
The chip is smsc9115, connected via SROMc bank 3. Additionally, some GPIO
initialization is required.
Signed-off-by: Pavel Fedin <p.fe...@samsung.com>
Reviewed-by: Krzysztof Kozlowski <k.kozlow...@samsung.com>
---
arch/arm/boot/dts/exynos5410-smdk5410.dts | 41 +++
arch/arm/boot/dts/exynos5410.dtsi | 6 +
2 files changed, 47 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5410-smdk5410.dts
b/arch/arm/boot/dts/exynos5410-smdk5410.dts
index cebeaab..373abf7 100644
--- a/arch/arm/boot/dts/exynos5410-smdk5410.dts
+++ b/arch/arm/boot/dts/exynos5410-smdk5410.dts
@@ -11,6 +11,7 @@
/dts-v1/;
#include "exynos5410.dtsi"
+#include
/ {
model = "Samsung SMDK5410 board based on EXYNOS5410";
compatible = "samsung,smdk5410", "samsung,exynos5410",
"samsung,exynos5";
@@ -61,6 +62,46 @@
disable-wp;
};
+_0 {
+ srom_ctl: srom-ctl {
+ samsung,pins = "gpy0-3", "gpy0-4", "gpy0-5",
+ "gpy1-0", "gpy1-1", "gpy1-2", "gpy1-3";
+ samsung,pin-function = <2>;
+ samsung,pin-drv = <0>;
+ };
+
+ srom_ebi: srom-ebi {
+ samsung,pins = "gpy3-0", "gpy3-1", "gpy3-2", "gpy3-3",
+ "gpy3-4", "gpy3-5", "gpy3-6", "gpy3-7",
+ "gpy5-0", "gpy5-1", "gpy5-2", "gpy5-3",
+ "gpy5-4", "gpy5-5", "gpy5-6", "gpy5-7",
+ "gpy6-0", "gpy6-1", "gpy6-2", "gpy6-3",
+ "gpy6-4", "gpy6-5", "gpy6-6", "gpy6-7";
+ samsung,pin-function = <2>;
+ samsung,pin-pud = <3>;
+ samsung,pin-drv = <0>;
+ };
+};
+
+ {
+ pinctrl-names = "default";
+ pinctrl-0 = <_ctl>, <_ebi>;
+
+ ethernet@3 {
+ compatible = "smsc,lan9115";
+ reg = <3 0 0x1>;
+ phy-mode = "mii";
+ interrupt-parent = <>;
+ interrupts = <5 IRQ_TYPE_LEVEL_LOW>;
+ reg-io-width = <2>;
+ smsc,irq-push-pull;
+ smsc,force-internal-phy;
+
+ samsung,srom-page-mode = <1>;
+ samsung,srom-timing = <9 12 1 9 1 1>;
+ };
+};
+
{
status = "okay";
};
diff --git a/arch/arm/boot/dts/exynos5410.dtsi
b/arch/arm/boot/dts/exynos5410.dtsi
index e2b58f8..9cfb814 100644
--- a/arch/arm/boot/dts/exynos5410.dtsi
+++ b/arch/arm/boot/dts/exynos5410.dtsi
@@ -104,6 +104,12 @@
sromc: sromc@1225 {
compatible = "samsung,exynos-srom";
reg = <0x1225 0x14>;
+ #address-cells = <2>;
+ #size-cells = <1>;
+ ranges = <0 0 0x0400 0x2
+ 1 0 0x0500 0x2
+ 2 0 0x0600 0x2
+ 3 0 0x0700 0x2>;
};
pmu_system_controller: system-controller@1004 {
--
2.4.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v6 0/4] Exynos SROMc configuration and Ethernet support for SMDK5410
This patch extends Exynos SROM controller driver with ability to configure
controller outputs and enables SMSC9115 Ethernet chip on SMDK5410 board,
which is connected via SROMc bank #3.
With this patchset, support for the whole existing SMDK range can be added.
Actually, only bank number is different.
This patchset also depends on Exynos 5410 pinctrl support, introduced by
patches 0003 and 0004 from this set:
[PATCH v4 0/5] ARM: EXYNOS: ODROID-XU DT and LEDs
http://lists.infradead.org/pipermail/linux-arm-kernel/2015-March/330862.html
Pinctrl support is necessary in order to correctly configure
multifunctional pins of the Exynos chip.
v5 => v6:
- Even more improvements to the documentation, fixed some errors and typos.
- Separated adding bus ranges from generic SROMc support
- Some stuff renamed for even better code readability
- Stylistic cleanups in the DTS (everything in alphabetic order, use named
constant name for interrupt config byte)
v4 => v5:
- Some cosmetic changes in the dtsi ("compatible" goes first)
- Use correctly specified ranges for the SROMc node
- Reuse existing properties where possible ("reg" for bank# and
"reg-io-width" for data width)
- Separated page-mode property from timings array
- More improvements to the documentation
v3 => v4:
- Devices are now added as subnodes, with additional properties. This allows
to cleary specify dependency. If configuration fails, error will be reported
and child devices will not be probed.
- These additional properties now have "samsung,srom-XXX" format
- Fixed code style, now better understood.
v2 => v3:
- Fixed up SROMc region size in the device tree
- Reordered patches, documentation goes first now
v1 => v2:
- Fixed some typos and bad labels in device tree
- Improved documentation
Pavel Fedin (4):
Documentation: dt-bindings: Describe SROMc configuration
ARM: dts: Add SROMc to Exynos 5410
drivers: exynos-srom: Add support for bank configuration
ARM: dts: Add Ethernet chip to SMDK5410
.../bindings/arm/samsung/exynos-srom.txt | 71 +-
arch/arm/boot/dts/exynos5410-smdk5410.dts | 41 +
arch/arm/boot/dts/exynos5410.dtsi | 11
arch/arm/mach-exynos/Kconfig | 2 +-
drivers/soc/samsung/Kconfig| 2 +-
drivers/soc/samsung/exynos-srom.c | 61 ++-
6 files changed, 182 insertions(+), 6 deletions(-)
--
2.4.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v6 2/4] ARM: dts: Add SROMc to Exynos 5410
This machine uses own SoC device tree file, add missing part.
Signed-off-by: Pavel Fedin
---
arch/arm/boot/dts/exynos5410.dtsi | 5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5410.dtsi
b/arch/arm/boot/dts/exynos5410.dtsi
index 4603356..e2b58f8 100644
--- a/arch/arm/boot/dts/exynos5410.dtsi
+++ b/arch/arm/boot/dts/exynos5410.dtsi
@@ -101,6 +101,11 @@
reg = <0x1000 0x100>;
};
+ sromc: sromc@1225 {
+ compatible = "samsung,exynos-srom";
+ reg = <0x1225 0x14>;
+ };
+
pmu_system_controller: system-controller@1004 {
compatible = "samsung,exynos5410-pmu", "syscon";
reg = <0x1004 0x5000>;
--
2.4.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v6 3/4] drivers: exynos-srom: Add support for bank configuration
Implement handling properties in subnodes and adding child devices to the
system. Child devices will not be added if configuration fails.
Since the driver now does more than suspend-resume support, dependency on
CONFIG_PM is removed.
Signed-off-by: Pavel Fedin
---
arch/arm/mach-exynos/Kconfig | 2 +-
drivers/soc/samsung/Kconfig | 2 +-
drivers/soc/samsung/exynos-srom.c | 61 +--
3 files changed, 61 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig
index 83c85f5..c22dc42 100644
--- a/arch/arm/mach-exynos/Kconfig
+++ b/arch/arm/mach-exynos/Kconfig
@@ -16,7 +16,7 @@ menuconfig ARCH_EXYNOS
select ARM_GIC
select COMMON_CLK_SAMSUNG
select EXYNOS_THERMAL
- select EXYNOS_SROM if PM
+ select EXYNOS_SROM
select HAVE_ARM_SCU if SMP
select HAVE_S3C2410_I2C if I2C
select HAVE_S3C2410_WATCHDOG if WATCHDOG
diff --git a/drivers/soc/samsung/Kconfig b/drivers/soc/samsung/Kconfig
index 2833b5b..ea4bc2a 100644
--- a/drivers/soc/samsung/Kconfig
+++ b/drivers/soc/samsung/Kconfig
@@ -8,6 +8,6 @@ config SOC_SAMSUNG
config EXYNOS_SROM
bool
- depends on ARM && ARCH_EXYNOS && PM
+ depends on ARM && ARCH_EXYNOS
endmenu
diff --git a/drivers/soc/samsung/exynos-srom.c
b/drivers/soc/samsung/exynos-srom.c
index 57a232d..a4cf547 100644
--- a/drivers/soc/samsung/exynos-srom.c
+++ b/drivers/soc/samsung/exynos-srom.c
@@ -14,6 +14,7 @@
#include
#include
#include
+#include
#include
#include
@@ -67,11 +68,51 @@ static struct exynos_srom_reg_dump
*exynos_srom_alloc_reg_dump(
return rd;
}
+static int exynos_srom_configure_bank(struct exynos_srom *srom,
+ struct device_node *np)
+{
+ u32 bank, width, pmc;
+ u32 timing[6];
+ u32 cs, bw;
+
+ if (of_property_read_u32(np, "reg", ))
+ return -EINVAL;
+ if (of_property_read_u32(np, "reg-io-width", ))
+ width = 1;
+ if (of_property_read_u32(np, "samsung,srom-page-mode", ))
+ pmc = 0;
+ if (of_property_read_u32_array(np, "samsung,srom-timing", timing,
+ ARRAY_SIZE(timing)))
+ return -EINVAL;
+
+ bank *= 4; /* Convert bank into shift/offset */
+
+ cs = 1 << EXYNOS_SROM_BW__BYTEENABLE__SHIFT;
+ if (width == 2)
+ cs |= 1 << EXYNOS_SROM_BW__DATAWIDTH__SHIFT;
+
+ bw = __raw_readl(srom->reg_base + EXYNOS_SROM_BW);
+ bw = (bw & ~(EXYNOS_SROM_BW__CS_MASK << bank)) | (cs << bank);
+ __raw_writel(bw, srom->reg_base + EXYNOS_SROM_BW);
+
+ __raw_writel((pmc << EXYNOS_SROM_BCX__PMC__SHIFT) |
+ (timing[0] << EXYNOS_SROM_BCX__TACP__SHIFT) |
+ (timing[1] << EXYNOS_SROM_BCX__TCAH__SHIFT) |
+ (timing[2] << EXYNOS_SROM_BCX__TCOH__SHIFT) |
+ (timing[3] << EXYNOS_SROM_BCX__TACC__SHIFT) |
+ (timing[4] << EXYNOS_SROM_BCX__TCOS__SHIFT) |
+ (timing[5] << EXYNOS_SROM_BCX__TACS__SHIFT),
+ srom->reg_base + EXYNOS_SROM_BC0 + bank);
+
+ return 0;
+}
+
static int exynos_srom_probe(struct platform_device *pdev)
{
- struct device_node *np;
+ struct device_node *np, *child;
struct exynos_srom *srom;
struct device *dev = >dev;
+ bool bad_bank_config = false;
np = dev->of_node;
if (!np) {
@@ -100,7 +141,23 @@ static int exynos_srom_probe(struct platform_device *pdev)
return -ENOMEM;
}
- return 0;
+ for_each_child_of_node(np, child) {
+ if (exynos_srom_configure_bank(srom, child)) {
+ dev_err(dev,
+ "Could not decode bank configuration for %s\n",
+ child->name);
+ bad_bank_config = true;
+ }
+ }
+
+ /*
+* If any bank failed to configure, we still provide suspend/resume,
+* but do not probe child devices
+*/
+ if (bad_bank_config)
+ return 0;
+
+ return of_platform_populate(np, NULL, NULL, dev);
}
static int exynos_srom_remove(struct platform_device *pdev)
--
2.4.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v6 4/4] ARM: dts: Add Ethernet chip to SMDK5410
The chip is smsc9115, connected via SROMc bank 3. Additionally, some GPIO
initialization is required.
Signed-off-by: Pavel Fedin
---
arch/arm/boot/dts/exynos5410-smdk5410.dts | 41 +++
arch/arm/boot/dts/exynos5410.dtsi | 6 +
2 files changed, 47 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5410-smdk5410.dts
b/arch/arm/boot/dts/exynos5410-smdk5410.dts
index cebeaab..373abf7 100644
--- a/arch/arm/boot/dts/exynos5410-smdk5410.dts
+++ b/arch/arm/boot/dts/exynos5410-smdk5410.dts
@@ -11,6 +11,7 @@
/dts-v1/;
#include "exynos5410.dtsi"
+#include
/ {
model = "Samsung SMDK5410 board based on EXYNOS5410";
compatible = "samsung,smdk5410", "samsung,exynos5410",
"samsung,exynos5";
@@ -61,6 +62,46 @@
disable-wp;
};
+_0 {
+ srom_ctl: srom-ctl {
+ samsung,pins = "gpy0-3", "gpy0-4", "gpy0-5",
+ "gpy1-0", "gpy1-1", "gpy1-2", "gpy1-3";
+ samsung,pin-function = <2>;
+ samsung,pin-drv = <0>;
+ };
+
+ srom_ebi: srom-ebi {
+ samsung,pins = "gpy3-0", "gpy3-1", "gpy3-2", "gpy3-3",
+ "gpy3-4", "gpy3-5", "gpy3-6", "gpy3-7",
+ "gpy5-0", "gpy5-1", "gpy5-2", "gpy5-3",
+ "gpy5-4", "gpy5-5", "gpy5-6", "gpy5-7",
+ "gpy6-0", "gpy6-1", "gpy6-2", "gpy6-3",
+ "gpy6-4", "gpy6-5", "gpy6-6", "gpy6-7";
+ samsung,pin-function = <2>;
+ samsung,pin-pud = <3>;
+ samsung,pin-drv = <0>;
+ };
+};
+
+ {
+ pinctrl-names = "default";
+ pinctrl-0 = <_ctl>, <_ebi>;
+
+ ethernet@3 {
+ compatible = "smsc,lan9115";
+ reg = <3 0 0x1>;
+ phy-mode = "mii";
+ interrupt-parent = <>;
+ interrupts = <5 IRQ_TYPE_LEVEL_LOW>;
+ reg-io-width = <2>;
+ smsc,irq-push-pull;
+ smsc,force-internal-phy;
+
+ samsung,srom-page-mode = <1>;
+ samsung,srom-timing = <9 12 1 9 1 1>;
+ };
+};
+
{
status = "okay";
};
diff --git a/arch/arm/boot/dts/exynos5410.dtsi
b/arch/arm/boot/dts/exynos5410.dtsi
index e2b58f8..9cfb814 100644
--- a/arch/arm/boot/dts/exynos5410.dtsi
+++ b/arch/arm/boot/dts/exynos5410.dtsi
@@ -104,6 +104,12 @@
sromc: sromc@1225 {
compatible = "samsung,exynos-srom";
reg = <0x1225 0x14>;
+ #address-cells = <2>;
+ #size-cells = <1>;
+ ranges = <0 0 0x0400 0x2
+ 1 0 0x0500 0x2
+ 2 0 0x0600 0x2
+ 3 0 0x0700 0x2>;
};
pmu_system_controller: system-controller@1004 {
--
2.4.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v6 1/4] Documentation: dt-bindings: Describe SROMc configuration
Add documentation for new subnode properties, allowing bank configuration.
Based on u-boot implementation, but heavily reworked.
Also, fix size of SROMc mapping in the example.
Signed-off-by: Pavel Fedin
---
.../bindings/arm/samsung/exynos-srom.txt | 71 +-
1 file changed, 69 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/arm/samsung/exynos-srom.txt
b/Documentation/devicetree/bindings/arm/samsung/exynos-srom.txt
index 33886d5..cce5c1f 100644
--- a/Documentation/devicetree/bindings/arm/samsung/exynos-srom.txt
+++ b/Documentation/devicetree/bindings/arm/samsung/exynos-srom.txt
@@ -5,8 +5,75 @@ Required properties:
- reg: offset and length of the register set
-Example:
+Optional properties:
+The SROM controller can be used to attach external peripherals. In this case
+extra properties, describing the bus behind it, should be specified as below:
+
+- #address-cells: Must be set to 2 to allow memory address translation
+
+- #size-cells: Must be set to 1 to allow CS address passing
+
+- ranges: Must be set up to reflect the memory layout with four integer values
+ per bank:
+0
+
+Sub-nodes:
+The actual device nodes should be added as subnodes to the SROMc node. These
+subnodes, except regular device specification, should contain the following
+properties, describing configuration of the relevant SROM bank:
+
+Required properties:
+- reg: bank number, base address (relative to start of the bank) and size of
+ the memory mapped for the device. Note that base address will be
+ typically 0 as this is the start of the bank.
+
+- samsung,srom-timing : array of 6 integers, specifying bank timings in the
+following order: Tacp, Tcah, Tcoh, Tacc, Tcos, Tacs.
+Each value is specified in cycles and has the following
+meaning and valid range:
+Tacp : Page mode access cycle at Page mode (0 - 15)
+Tcah : Address holding time after CSn (0 - 15)
+Tcoh : Chip selection hold on OEn (0 - 15)
+Tacc : Access cycle (0 - 32)
+Tcos : Chip selection set-up before OEn (0 - 15)
+Tacs : Address set-up before CSn (0 - 15)
+
+Optional properties:
+- reg-io-width : data width in bytes (1 or 2). If omitted, default of 1 is
used.
+
+- samsung,srom-page-mode : page mode configuration for the bank:
+ 0 - normal (one data)
+ 1 - four data
+ If omitted, default of 0 is used.
+
+Example: basic definition, no banks are configured
+ sromc@1257 {
+ compatible = "samsung,exynos-srom";
+ reg = <0x1257 0x14>;
+ };
+
+Example: SROMc with SMSC911x ethernet chip on bank 3
sromc@1257 {
+ #address-cells = <2>;
+ #size-cells = <1>;
+ ranges = <0 0 0x0400 0x2 // Bank0
+ 1 0 0x0500 0x2 // Bank1
+ 2 0 0x0600 0x2 // Bank2
+ 3 0 0x0700 0x2>; // Bank3
+
compatible = "samsung,exynos-srom";
- reg = <0x1257 0x10>;
+ reg = <0x1257 0x14>;
+
+ ethernet@3 {
+ compatible = "smsc,lan9115";
+ reg = <3 0 0x1>; // Bank 3, offset = 0
+ phy-mode = "mii";
+ interrupt-parent = <>;
+ interrupts = <5 8>;
+ reg-io-width = <2>;
+ smsc,irq-push-pull;
+ smsc,force-internal-phy;
+
+ samsung,srom-config = <1 9 12 1 9 1 1>;
+ };
};
--
2.4.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH v5 4/4] ARM: dts: Add Ethernet chip to SMDK5410
Hello!
> >>> + ethernet@3 {
> >>> + compatible = "smsc,lan9115";
> >>> + reg = <3 0 0x1>;
> >>> + phy-mode = "mii";
> >>> + interrupt-parent = <>;
> >>> + interrupts = <5 8>;
> >>
> >> s/8/IRQ_TYPE_LEVEL_LOW/
> >> (is this really level low interrupt?)
> >
> > Yes, according to:
> > https://github.com/AndreiLux/Perseus-S3/blob/master/arch/arm/mach-
> exynos/mach-smdk5250.c#L133
>
> Although this is different board, but okay.
I am curious too, so i examined SMSC datasheet. The IRQ is fully programmable
on
chip's side too, and our driver indeed defaults to active-low. You can switch it
to active-high by addint smsc,irq-active-high property. But i just copied
settings from those old Android kernels, and it just works.
So, cleaning up and posting v6.
Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH v5 4/4] ARM: dts: Add Ethernet chip to SMDK5410
Hello!
> > + ethernet@3 {
> > + compatible = "smsc,lan9115";
> > + reg = <3 0 0x1>;
> > + phy-mode = "mii";
> > + interrupt-parent = <>;
> > + interrupts = <5 8>;
>
> s/8/IRQ_TYPE_LEVEL_LOW/
> (is this really level low interrupt?)
Yes, according to:
https://github.com/AndreiLux/Perseus-S3/blob/master/arch/arm/mach-exynos/mach-smdk5250.c#L133
> Some other DTS include regulators: vddvario-supply and vdd33a-supply. It
> seems that they are not described in SMSC911x bindings but in
> GPMC-eth... but the smsc911x driver is requesting them. Could you
> investigate that? I think these regulators should be provided (and
> SMSC911x bindings should be updated).
Sorry, i cannot. The board has lots of jumpers, which choose between fixed
voltage and regulators for different components,
according to board's manual, but the manual is very poor IMHO, and i don't
understand how to use them. And i use default,
fixed-voltage configuration.
One of my colleagues tried to get it working, but failed. It actually requires
more time, and IIRC you need to bring up i2c before
you can drive regulators.
So can we leave it as it is for now? At least it works, and this is much
better than no ethernet support at all.
> I don't have the board schematics so I couldn't verify the GPIOs.
Me neither, i wrote GPIO settings according to chip datasheet i have. They are
actually chip-specific, but i wrote them in board
file because on different boards you may use different banks, and therefore
different pins. Or, if you don't use SROMc at all, you
can configure all pins to do something else.
Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH v5 3/4] drivers: exynos-srom: Add support for bank configuration
Hello!
> > +static int decode_sromc(struct exynos_srom *srom, struct device_node *np)
>
> I missed that one previously: add prefix and more descriptive name, like:
> exynos_srom_parse_child()
exynos_srom_configure_bank(), is this name OK?
> > static int exynos_srom_probe(struct platform_device *pdev)
> > {
> > - struct device_node *np;
> > + struct device_node *np, *child;
> > struct exynos_srom *srom;
> > struct device *dev = >dev;
> > + bool error = false;
>
> The 'error' name is misleading - like error for entire probe which is
> not true.
>
> Instead split it to separate function like:
>
> +static int exynos_srom_parse_children() {
> + int ret = 0;
> +
> + for_each_child_of_node(np, child) {
> + ret = exynos_srom_parse_child(srom, child);
> + if (ret) {
> + dev_err(dev,
> + "Could not decode bank configuration for %s:
> %d\n",
> + child->name, ret);
> + break;
> + }
> + }
> +
> + return ret;
> +}
Factoring out this loop is unnecessary, because i could just 'return 0' in the
loop
instead of 'error = true'. Byt my idea is to go through all banks anyway, just
in
case, to diagnose all of them. So that the user will be able to spot and fix all
broken banks at once, instead of doing one-by-one.
I have renamed the variable to 'bool bad_bank_config', will this be OK?
Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH v5 0/4] Exynos SROMc configuration and Ethernet support for SMDK5410
Hello! > >>>>> This patchset also depends on Exynos 5410 pinctrl support, introduced by > >>>>> patches 0003 and 0004 from this set: > >>>>> [PATCH v4 0/5] ARM: EXYNOS: ODROID-XU DT and LEDs > >>>>> http://lists.infradead.org/pipermail/linux-arm-kernel/2015-March/330862.html > >>>> > >>>> Only the first patch made up to kernel. The rest (2-5) received feedback > >>>> and I am waiting for fixing it. Andreas apparently loose the interest... > >>> > >>> I have rechecked the original thread on archives and found nothing new. > >>> Where can > >>> i read those feedbacks? Perhaps it makes sense for me to pick them up and > >>> include > >>> into my set. > >> > >> Go ahead. The only waiting feedback is at patch 2/5: > >> > >> http://lists.infradead.org/pipermail/linux-arm-kernel/2015-March/330910.html > >> Javier's pointed use of linux,stdout-path and putting xxti in > >> exynos5410.dtsi (and customizing it per board if needed). > >> > >> Patches already got reviews and acks so only 2/5 is the stopper. > > > > Ah, it's odroidXU device tree. Sorry, i don't have this particular board, > > and my patch > actually doesn't need it. I could do some > > blind modifications, but cannot test them, and this is out of my scope at > > all. > > As mentioned in the commit msg, i need only 0003 and 0004 from there. Can > > they be picked up > independently? They don't need 0002 by > > themselves, only 0005 needs it. > > Indeed the order of patches is messed up and this makes the confusion. I > was waiting for resend of entire patchset but you are right - this is > not required. 3 and 4 can be applied independently. > > If they apply, I will pick up them after merge window. They should. I have quite recent linux-next tree, i've just checked, 0003 applies with a small fuzz and 0004 applies without problems at all. > If they don't, they will need rebasing by someone. Maybe you can take > care of them? Of course. Please notify me if rebasing will be needed, i'll do it. > You have the SMDK5410 for testing, right? Of course. And you can already get my Tested-by: Pavel Fedin on those two because my experimental tree already uses them, and everything works quite well. Kind regards, Pavel Fedin Expert Engineer Samsung Electronics Research center Russia -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH v5 0/4] Exynos SROMc configuration and Ethernet support for SMDK5410
Hello! > >>> This patchset also depends on Exynos 5410 pinctrl support, introduced by > >>> patches 0003 and 0004 from this set: > >>> [PATCH v4 0/5] ARM: EXYNOS: ODROID-XU DT and LEDs > >>> http://lists.infradead.org/pipermail/linux-arm-kernel/2015-March/330862.html > >> > >> Only the first patch made up to kernel. The rest (2-5) received feedback > >> and I am waiting for fixing it. Andreas apparently loose the interest... > > > > I have rechecked the original thread on archives and found nothing new. > > Where can > > i read those feedbacks? Perhaps it makes sense for me to pick them up and > > include > > into my set. > > Go ahead. The only waiting feedback is at patch 2/5: > > http://lists.infradead.org/pipermail/linux-arm-kernel/2015-March/330910.html > Javier's pointed use of linux,stdout-path and putting xxti in > exynos5410.dtsi (and customizing it per board if needed). > > Patches already got reviews and acks so only 2/5 is the stopper. Ah, it's odroidXU device tree. Sorry, i don't have this particular board, and my patch actually doesn't need it. I could do some blind modifications, but cannot test them, and this is out of my scope at all. As mentioned in the commit msg, i need only 0003 and 0004 from there. Can they be picked up independently? They don't need 0002 by themselves, only 0005 needs it. Kind regards, Pavel Fedin Expert Engineer Samsung Electronics Research center Russia -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH v5 0/4] Exynos SROMc configuration and Ethernet support for SMDK5410
Hello! > > This patchset also depends on Exynos 5410 pinctrl support, introduced by > > patches 0003 and 0004 from this set: > > [PATCH v4 0/5] ARM: EXYNOS: ODROID-XU DT and LEDs > > http://lists.infradead.org/pipermail/linux-arm-kernel/2015-March/330862.html > > Only the first patch made up to kernel. The rest (2-5) received feedback > and I am waiting for fixing it. Andreas apparently loose the interest... I have rechecked the original thread on archives and found nothing new. Where can i read those feedbacks? Perhaps it makes sense for me to pick them up and include into my set. Kind regards, Pavel Fedin Expert Engineer Samsung Electronics Research center Russia -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH v5 0/4] Exynos SROMc configuration and Ethernet support for SMDK5410
Hello! > >>>>> This patchset also depends on Exynos 5410 pinctrl support, introduced by > >>>>> patches 0003 and 0004 from this set: > >>>>> [PATCH v4 0/5] ARM: EXYNOS: ODROID-XU DT and LEDs > >>>>> http://lists.infradead.org/pipermail/linux-arm-kernel/2015-March/330862.html > >>>> > >>>> Only the first patch made up to kernel. The rest (2-5) received feedback > >>>> and I am waiting for fixing it. Andreas apparently loose the interest... > >>> > >>> I have rechecked the original thread on archives and found nothing new. > >>> Where can > >>> i read those feedbacks? Perhaps it makes sense for me to pick them up and > >>> include > >>> into my set. > >> > >> Go ahead. The only waiting feedback is at patch 2/5: > >> > >> http://lists.infradead.org/pipermail/linux-arm-kernel/2015-March/330910.html > >> Javier's pointed use of linux,stdout-path and putting xxti in > >> exynos5410.dtsi (and customizing it per board if needed). > >> > >> Patches already got reviews and acks so only 2/5 is the stopper. > > > > Ah, it's odroidXU device tree. Sorry, i don't have this particular board, > > and my patch > actually doesn't need it. I could do some > > blind modifications, but cannot test them, and this is out of my scope at > > all. > > As mentioned in the commit msg, i need only 0003 and 0004 from there. Can > > they be picked up > independently? They don't need 0002 by > > themselves, only 0005 needs it. > > Indeed the order of patches is messed up and this makes the confusion. I > was waiting for resend of entire patchset but you are right - this is > not required. 3 and 4 can be applied independently. > > If they apply, I will pick up them after merge window. They should. I have quite recent linux-next tree, i've just checked, 0003 applies with a small fuzz and 0004 applies without problems at all. > If they don't, they will need rebasing by someone. Maybe you can take > care of them? Of course. Please notify me if rebasing will be needed, i'll do it. > You have the SMDK5410 for testing, right? Of course. And you can already get my Tested-by: Pavel Fedin <p.fe...@samsung.com> on those two because my experimental tree already uses them, and everything works quite well. Kind regards, Pavel Fedin Expert Engineer Samsung Electronics Research center Russia -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
