[PATCH v2] ARC: io.h: Implement reads{x}()/writes{x}()

}_unaligned() helper instead of plain dereference of pointer in order to fix this. Changes from v1: - Check if buffer is already aligned (David) - Remove 64 bit mention (Alexey) Signed-off-by: Jose Abreu Tested-by: Vitor Soares Cc: Vineet Gupta Cc: Alexey Brodkin Cc: Joao Pinto Cc: Vitor Soares Cc

Re: [PATCH] ARC: io.h: Implement reads{x}()/writes{x}()

On 29-11-2018 13:03, David Laight wrote: > From: Jose Abreu [mailto:jose.ab...@synopsys.com] >> On 29-11-2018 12:47, David Laight wrote: >>> From: Jose Abreu >>>> Sent: 29 November 2018 12:42 >>>> >>>> Some ARC CPU's do not support unaligne

Re: [PATCH] ARC: io.h: Implement reads{x}()/writes{x}()

On 29-11-2018 13:03, David Laight wrote: > From: Jose Abreu [mailto:jose.ab...@synopsys.com] >> On 29-11-2018 12:47, David Laight wrote: >>> From: Jose Abreu >>>> Sent: 29 November 2018 12:42 >>>> >>>> Some ARC CPU's do not support unaligne

Re: [PATCH] Revert "net: stmmac: Do not keep rearming the coalesce timer in stmmac_xmit"

Hi Jerome, On 24-08-2018 10:04, Jerome Brunet wrote: > This reverts commit 4ae0169fd1b3c792b66be58995b7e6b629919ecf. > > This change in the handling of the coalesce timer is causing regression on > (at least) amlogic platforms. > > Network will break down very quickly (a few seconds) after

Re: [PATCH] Revert "net: stmmac: Do not keep rearming the coalesce timer in stmmac_xmit"

Hi Jerome, On 24-08-2018 10:04, Jerome Brunet wrote: > This reverts commit 4ae0169fd1b3c792b66be58995b7e6b629919ecf. > > This change in the handling of the coalesce timer is causing regression on > (at least) amlogic platforms. > > Network will break down very quickly (a few seconds) after

Re: [BUG] net: stmmac: dwmac-sun8i broken in linux-next

Hi Corentin, On 16-05-2018 19:32, Corentin Labbe wrote: > Hello > > The dwmac-sun8i driver is broken in next-20180515, symptom are no RX and TX > errors as shown by ifconfig: > eth0: flags=4163 mtu 1500 > inet 192.168.1.204 netmask 255.255.255.0

Re: [BUG] net: stmmac: dwmac-sun8i broken in linux-next

Hi Corentin, On 16-05-2018 19:32, Corentin Labbe wrote: > Hello > > The dwmac-sun8i driver is broken in next-20180515, symptom are no RX and TX > errors as shown by ifconfig: > eth0: flags=4163 mtu 1500 > inet 192.168.1.204 netmask 255.255.255.0 broadcast 192.168.1.255 > ether

Re: [PATCH net-next v2 2/2] drivers: net: Remove device_node checks with of_mdiobus_register()

| 12 +++- > drivers/net/ethernet/freescale/fec_main.c | 8 ++-- > drivers/net/ethernet/marvell/mvmdio.c | 5 + > drivers/net/ethernet/renesas/sh_eth.c | 11 +++ > drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c | 5 +-

Re: [PATCH net-next v2 2/2] drivers: net: Remove device_node checks with of_mdiobus_register()

> drivers/net/ethernet/freescale/fec_main.c | 8 ++-- > drivers/net/ethernet/marvell/mvmdio.c | 5 + > drivers/net/ethernet/renesas/sh_eth.c | 11 +++ > drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c | 5 + For stmmac: Reviewed-by

Re: [PATCH] net: stmmac: Avoid VLA usage

On 02-05-2018 13:36, Kees Cook wrote: > On Wed, May 2, 2018 at 1:54 AM, Jose Abreu <jose.ab...@synopsys.com> wrote: >> Hi Kees, >> >> On 01-05-2018 22:01, Kees Cook wrote: >>> In the quest to remove all stack VLAs from the kernel[1], this switches

Re: [PATCH] net: stmmac: Avoid VLA usage

On 02-05-2018 13:36, Kees Cook wrote: > On Wed, May 2, 2018 at 1:54 AM, Jose Abreu wrote: >> Hi Kees, >> >> On 01-05-2018 22:01, Kees Cook wrote: >>> In the quest to remove all stack VLAs from the kernel[1], this switches >>> the "status" stack

Re: [PATCH] net: stmmac: Avoid VLA usage

i96Vm5hJ_19IJiuxx_p_Rzo2g-uHDKw=TBD6a7UY2VbpPmV9LOW_eHAyg8uPq1ZPDhq93VROTVE=4fvOST1HhWmZ4lThQe-dHCJYEXNOwey00BCXOWm8tKo= > > Signed-off-by: Kees Cook <keesc...@chromium.org> > I rather prefer the variables declaration in reverse-tree order, but thats just a minor pick. Reviewed-by: Jose Abreu <joab...@synopsys.com

Re: [PATCH] net: stmmac: Avoid VLA usage

i96Vm5hJ_19IJiuxx_p_Rzo2g-uHDKw=TBD6a7UY2VbpPmV9LOW_eHAyg8uPq1ZPDhq93VROTVE=4fvOST1HhWmZ4lThQe-dHCJYEXNOwey00BCXOWm8tKo= > > Signed-off-by: Kees Cook > I rather prefer the variables declaration in reverse-tree order, but thats just a minor pick. Reviewed-by: Jose Abreu Thanks and Best Regards, Jose Miguel Abreu PS: Is

Re: [PATCH] net: dwc-xlgmac: fix xlgmac_xmit()'s return type

On 24-04-2018 14:17, Luc Van Oostenryck wrote: > The method ndo_start_xmit() is defined as returning an 'netdev_tx_t', > which is a typedef for an enum type, but the implementation in this > driver returns an 'int'. > > Fix this by returning 'netdev_tx_t' in this driver too. > > Signed-off-by: Luc

Re: [PATCH] net: dwc-xlgmac: fix xlgmac_xmit()'s return type

On 24-04-2018 14:17, Luc Van Oostenryck wrote: > The method ndo_start_xmit() is defined as returning an 'netdev_tx_t', > which is a typedef for an enum type, but the implementation in this > driver returns an 'int'. > > Fix this by returning 'netdev_tx_t' in this driver too. > > Signed-off-by: Luc

Re: [PATCH net-next] net: stmmac: remove superfluous wmb() memory barriers

Hi Niklas, On 08-03-2018 10:30, Niklas Cassel wrote: > These wmb() memory barriers are performed after the last descriptor write, > and they are followed by enable_dma_transmission()/set_tx_tail_ptr(), > i.e. a writel() to MMIO register space. > Since writel() itself performs the equivalent of a

Re: [PATCH net-next] net: stmmac: remove superfluous wmb() memory barriers

Hi Niklas, On 08-03-2018 10:30, Niklas Cassel wrote: > These wmb() memory barriers are performed after the last descriptor write, > and they are followed by enable_dma_transmission()/set_tx_tail_ptr(), > i.e. a writel() to MMIO register space. > Since writel() itself performs the equivalent of a

Re: [PATCH net-next 0/7] stmmac multi-queue fixes and cleanups

or code from stmmac_dt_phy() Thanks! The whole series is: Reviewed-by: Jose Abreu <joab...@synopsys.com> Best Regards, Jose Miguel Abreu > > drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c | 6 ++-- > drivers/net/ethernet/stmicro/stmmac/stmmac.h | 2 +- > d

Re: [PATCH net-next 0/7] stmmac multi-queue fixes and cleanups

or code from stmmac_dt_phy() Thanks! The whole series is: Reviewed-by: Jose Abreu Best Regards, Jose Miguel Abreu > > drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c | 6 ++-- > drivers/net/ethernet/stmicro/stmmac/stmmac.h | 2 +- > drivers/net/ethernet/stmicro/stmma

Re: [PATCH v10 4/4] [media] platform: Add Synopsys DesignWare HDMI RX Controller Driver

Hi Hans, On 13-12-2017 20:49, Hans Verkuil wrote: > On 13/12/17 15:00, Jose Abreu wrote: >> >> Indeed. I compared the values with the spec and they are not >> correct. Even hsync is wrong. I already corrected in the code the >> hsync but regarding interlace I'm n

Re: [PATCH v10 4/4] [media] platform: Add Synopsys DesignWare HDMI RX Controller Driver

Hi Hans, On 13-12-2017 20:49, Hans Verkuil wrote: > On 13/12/17 15:00, Jose Abreu wrote: >> >> Indeed. I compared the values with the spec and they are not >> correct. Even hsync is wrong. I already corrected in the code the >> hsync but regarding interlace I'm n

Re: [PATCH v10 4/4] [media] platform: Add Synopsys DesignWare HDMI RX Controller Driver

Hi Hans, On 13-12-2017 10:00, Hans Verkuil wrote: > On 12/12/17 17:02, Jose Abreu wrote: >> >>>> +static int dw_hdmi_s_routing(struct v4l2_subdev *sd, u32 input, u32 >>>> output, >>>> + u32 config) >>>

Re: [PATCH v10 4/4] [media] platform: Add Synopsys DesignWare HDMI RX Controller Driver

Hi Hans, On 13-12-2017 10:00, Hans Verkuil wrote: > On 12/12/17 17:02, Jose Abreu wrote: >> >>>> +static int dw_hdmi_s_routing(struct v4l2_subdev *sd, u32 input, u32 >>>> output, >>>> + u32 config) >>>

Re: [PATCH v10 4/4] [media] platform: Add Synopsys DesignWare HDMI RX Controller Driver

Hi Hans, On 12-12-2017 15:47, Hans Verkuil wrote: > Hi Jose, > > Some more comments: Thanks for the review! > > On 11/12/17 18:41, Jose Abreu wrote: >> This is an initial submission for the Synopsys DesignWare HDMI RX >> Controller Driver. This driver int

Re: [PATCH v10 4/4] [media] platform: Add Synopsys DesignWare HDMI RX Controller Driver

Hi Hans, On 12-12-2017 15:47, Hans Verkuil wrote: > Hi Jose, > > Some more comments: Thanks for the review! > > On 11/12/17 18:41, Jose Abreu wrote: >> This is an initial submission for the Synopsys DesignWare HDMI RX >> Controller Driver. This driver int

[PATCH v10 4/4] [media] platform: Add Synopsys DesignWare HDMI RX Controller Driver

sources might not be very stable at sending the video (i.e. we must react accordingly). Signed-off-by: Jose Abreu <joab...@synopsys.com> Cc: Joao Pinto <jpi...@synopsys.com> Cc: Mauro Carvalho Chehab <mche...@kernel.org> Cc: Hans Verkuil <hans.verk...@cis

[PATCH v10 4/4] [media] platform: Add Synopsys DesignWare HDMI RX Controller Driver

sources might not be very stable at sending the video (i.e. we must react accordingly). Signed-off-by: Jose Abreu Cc: Joao Pinto Cc: Mauro Carvalho Chehab Cc: Hans Verkuil Cc: Sylwester Nawrocki Cc: Sakari Ailus Cc: Philippe Ombredanne --- Changes from v9: - Use SPDX

[PATCH v10 2/4] MAINTAINERS: Add entry for Synopsys DesignWare HDMI drivers

Add an entry for Synopsys DesignWare HDMI Receivers drivers and phys. Signed-off-by: Jose Abreu <joab...@synopsys.com> Cc: Joao Pinto <jpi...@synopsys.com> --- MAINTAINERS | 7 +++ 1 file changed, 7 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 7a52a66..a1

[PATCH v10 2/4] MAINTAINERS: Add entry for Synopsys DesignWare HDMI drivers

Add an entry for Synopsys DesignWare HDMI Receivers drivers and phys. Signed-off-by: Jose Abreu Cc: Joao Pinto --- MAINTAINERS | 7 +++ 1 file changed, 7 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 7a52a66..a1675bc 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -13108,6

[PATCH v10 3/4] [media] platform: Add Synopsys DesignWare HDMI RX PHY e405 Driver

. configuration functions) and the controller must provide read/write callbacks, as well as other specific functions. Signed-off-by: Jose Abreu <joab...@synopsys.com> Cc: Joao Pinto <jpi...@synopsys.com> Cc: Mauro Carvalho Chehab <mche...@kernel.org> Cc: Hans Verkuil <hans.verk...@cis

[PATCH v10 3/4] [media] platform: Add Synopsys DesignWare HDMI RX PHY e405 Driver

. configuration functions) and the controller must provide read/write callbacks, as well as other specific functions. Signed-off-by: Jose Abreu Cc: Joao Pinto Cc: Mauro Carvalho Chehab Cc: Hans Verkuil Cc: Sylwester Nawrocki Cc: Philippe Ombredanne --- Changes from v9: - Use SPDX License ID

[PATCH v10 0/4] Synopsys DesignWare HDMI Video Capture Controller + PHY

several audio output interfaces). Version 10 addresses review comments from Hans Verkuil and from Philippe Ombredanne. This series was tested in a FPGA platform using an embedded platform called ARC AXS101. Jose Abreu (4): dt-bindings: media: Document Synopsys DesignWare HDMI RX MAINTAINERS: Add

[PATCH v10 0/4] Synopsys DesignWare HDMI Video Capture Controller + PHY

several audio output interfaces). Version 10 addresses review comments from Hans Verkuil and from Philippe Ombredanne. This series was tested in a FPGA platform using an embedded platform called ARC AXS101. Jose Abreu (4): dt-bindings: media: Document Synopsys DesignWare HDMI RX MAINTAINERS: Add

[PATCH v10 1/4] dt-bindings: media: Document Synopsys DesignWare HDMI RX

Document the bindings for the Synopsys DesignWare HDMI RX. Signed-off-by: Jose Abreu <joab...@synopsys.com> Acked-by: Rob Herring <r...@kernel.org> (v8) Cc: Joao Pinto <jpi...@synopsys.com> Cc: Rob Herring <robh...@kernel.org> Cc: Mark Rutland <mark.rutl...@arm.com

[PATCH v10 1/4] dt-bindings: media: Document Synopsys DesignWare HDMI RX

Document the bindings for the Synopsys DesignWare HDMI RX. Signed-off-by: Jose Abreu Acked-by: Rob Herring (v8) Cc: Joao Pinto Cc: Rob Herring Cc: Mark Rutland Cc: Mauro Carvalho Chehab Cc: Hans Verkuil Cc: Sylwester Nawrocki Cc: devicet...@vger.kernel.org --- Changes from v7

Re: [PATCH v2 net-next] net: stmmac: Add support for DWMAC5 with TSN features

Hi David, Florian, On 01-11-2017 11:48, David Miller wrote: > From: Jose Abreu <jose.ab...@synopsys.com> > Date: Fri, 27 Oct 2017 14:55:44 +0100 > >> This adds support for IP version 5 of DWMAC. The new introduced >> features are the Enhancements to Scheduled

Re: [PATCH v2 net-next] net: stmmac: Add support for DWMAC5 with TSN features

Hi David, Florian, On 01-11-2017 11:48, David Miller wrote: > From: Jose Abreu > Date: Fri, 27 Oct 2017 14:55:44 +0100 > >> This adds support for IP version 5 of DWMAC. The new introduced >> features are the Enhancements to Scheduled Traffic (EST) as >> defined by

Re: [PATCH v9 4/4] [media] platform: Add Synopsys DesignWare HDMI RX Controller Driver

Hi Hans, On 07-12-2017 12:33, Hans Verkuil wrote: > Hi Jose, > > Some (small) comments below: Thanks for the review! > > On 12/07/17 10:47, Jose Abreu wrote: >> This is an initial submission for the Synopsys DesignWare HDMI RX >> Controller Driver. This driver int

Re: [PATCH v9 4/4] [media] platform: Add Synopsys DesignWare HDMI RX Controller Driver

Hi Hans, On 07-12-2017 12:33, Hans Verkuil wrote: > Hi Jose, > > Some (small) comments below: Thanks for the review! > > On 12/07/17 10:47, Jose Abreu wrote: >> This is an initial submission for the Synopsys DesignWare HDMI RX >> Controller Driver. This driver int

Re: [PATCH v4 0/9] drm/i915: Implement HDCP

Hi Sean, On 07-12-2017 00:00, Sean Paul wrote: > Welcome to version 4 of the patchset. I think we're nearing the finish line > (hopefully) now. This set addresses the review feedback from v3. I applied > some > R-b's from v3 review, and converted others to Cc since other changes were made > to

Re: [PATCH v4 0/9] drm/i915: Implement HDCP

Hi Sean, On 07-12-2017 00:00, Sean Paul wrote: > Welcome to version 4 of the patchset. I think we're nearing the finish line > (hopefully) now. This set addresses the review feedback from v3. I applied > some > R-b's from v3 review, and converted others to Cc since other changes were made > to

[PATCH v9 0/4] Synopsys DesignWare HDMI Video Capture Controller + PHY

several audio output interfaces). Version 9 implements the work developed by Sakari Ailus regarding subdevices pipelines registration. This series was tested in a FPGA platform using an embedded platform called ARC AXS101. Jose Abreu (4): dt-bindings: media: Document Synopsys DesignWare HDMI RX

[PATCH v9 0/4] Synopsys DesignWare HDMI Video Capture Controller + PHY

several audio output interfaces). Version 9 implements the work developed by Sakari Ailus regarding subdevices pipelines registration. This series was tested in a FPGA platform using an embedded platform called ARC AXS101. Jose Abreu (4): dt-bindings: media: Document Synopsys DesignWare HDMI RX

[PATCH v9 2/4] MAINTAINERS: Add entry for Synopsys DesignWare HDMI drivers

Add an entry for Synopsys DesignWare HDMI Receivers drivers and phys. Signed-off-by: Jose Abreu <joab...@synopsys.com> Cc: Joao Pinto <jpi...@synopsys.com> --- MAINTAINERS | 7 +++ 1 file changed, 7 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 7a52a66..a1

[PATCH v9 2/4] MAINTAINERS: Add entry for Synopsys DesignWare HDMI drivers

Add an entry for Synopsys DesignWare HDMI Receivers drivers and phys. Signed-off-by: Jose Abreu Cc: Joao Pinto --- MAINTAINERS | 7 +++ 1 file changed, 7 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 7a52a66..a1675bc 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -13108,6

[PATCH v9 4/4] [media] platform: Add Synopsys DesignWare HDMI RX Controller Driver

sources might not be very stable at sending the video (i.e. we must react accordingly). Signed-off-by: Jose Abreu <joab...@synopsys.com> Cc: Joao Pinto <jpi...@synopsys.com> Cc: Mauro Carvalho Chehab <mche...@kernel.org> Cc: Hans Verkuil <hans.verk...@cis

[PATCH v9 4/4] [media] platform: Add Synopsys DesignWare HDMI RX Controller Driver

sources might not be very stable at sending the video (i.e. we must react accordingly). Signed-off-by: Jose Abreu Cc: Joao Pinto Cc: Mauro Carvalho Chehab Cc: Hans Verkuil Cc: Sylwester Nawrocki Cc: Sakari Ailus --- Changes from v8: - Incorporate Sakari's work on ASYNC

[PATCH v9 1/4] dt-bindings: media: Document Synopsys DesignWare HDMI RX

Document the bindings for the Synopsys DesignWare HDMI RX. Signed-off-by: Jose Abreu <joab...@synopsys.com> Acked-by: Rob Herring <r...@kernel.org> (v8) Cc: Joao Pinto <jpi...@synopsys.com> Cc: Rob Herring <robh...@kernel.org> Cc: Mark Rutland <mark.rutl...@arm.com

[PATCH v9 1/4] dt-bindings: media: Document Synopsys DesignWare HDMI RX

Document the bindings for the Synopsys DesignWare HDMI RX. Signed-off-by: Jose Abreu Acked-by: Rob Herring (v8) Cc: Joao Pinto Cc: Rob Herring Cc: Mark Rutland Cc: Mauro Carvalho Chehab Cc: Hans Verkuil Cc: Sylwester Nawrocki Cc: devicet...@vger.kernel.org --- Changes from v7

[PATCH v9 3/4] [media] platform: Add Synopsys DesignWare HDMI RX PHY e405 Driver

. configuration functions) and the controller must provide read/write callbacks, as well as other specific functions. Signed-off-by: Jose Abreu <joab...@synopsys.com> Cc: Joao Pinto <jpi...@synopsys.com> Cc: Mauro Carvalho Chehab <mche...@kernel.org> Cc: Hans Verkuil <hans.verk...@cis

[PATCH v9 3/4] [media] platform: Add Synopsys DesignWare HDMI RX PHY e405 Driver

. configuration functions) and the controller must provide read/write callbacks, as well as other specific functions. Signed-off-by: Jose Abreu Cc: Joao Pinto Cc: Mauro Carvalho Chehab Cc: Hans Verkuil Cc: Sylwester Nawrocki --- Changes from v4: - Use usleep_range (Sylwester) - Remove

Re: xf86-video-armada via UDL [was: Re: UDL's fbdev doesn't work for user-space apps]

On 05-12-2017 11:53, Alexey Brodkin wrote: > > From my note above about udl_drm_gem_mmap() being only used in case of Xserver > I barely may conclude anything. Given my lack of knowledge of DRM guts > especially > when it comes to complicated cases with DMA buffer exports/imports I cannot > say >

Re: xf86-video-armada via UDL [was: Re: UDL's fbdev doesn't work for user-space apps]

On 05-12-2017 11:53, Alexey Brodkin wrote: > > From my note above about udl_drm_gem_mmap() being only used in case of Xserver > I barely may conclude anything. Given my lack of knowledge of DRM guts > especially > when it comes to complicated cases with DMA buffer exports/imports I cannot > say >

Re: xf86-video-armada via UDL [was: Re: UDL's fbdev doesn't work for user-space apps]

Hi Alexey, On 04-12-2017 17:29, Alexey Brodkin wrote: > > Indeed, in case of kmscube etnaviv is a renderer while UDL > outputs the picture on the screen. Thats nice :) Ok, from your logs I was not able to see anything wrong. X server does not error exit and Prime seems to be working in DRM ...

Re: xf86-video-armada via UDL [was: Re: UDL's fbdev doesn't work for user-space apps]

Hi Alexey, On 04-12-2017 17:29, Alexey Brodkin wrote: > > Indeed, in case of kmscube etnaviv is a renderer while UDL > outputs the picture on the screen. Thats nice :) Ok, from your logs I was not able to see anything wrong. X server does not error exit and Prime seems to be working in DRM ...

Re: xf86-video-armada via UDL [was: Re: UDL's fbdev doesn't work for user-space apps]

On 04-12-2017 16:00, Alexey Brodkin wrote: > [30.763] (II) armada(0): etnaviv: Xv: using YUY2 format intermediate YUV > target > I'm wondering if this means that target format for UDL is YUV ... But anyway, I revisited your first email and noticed that you said kmscube runs fine. Is this

Re: xf86-video-armada via UDL [was: Re: UDL's fbdev doesn't work for user-space apps]

On 04-12-2017 16:00, Alexey Brodkin wrote: > [30.763] (II) armada(0): etnaviv: Xv: using YUY2 format intermediate YUV > target > I'm wondering if this means that target format for UDL is YUV ... But anyway, I revisited your first email and noticed that you said kmscube runs fine. Is this

Re: xf86-video-armada via UDL [was: Re: UDL's fbdev doesn't work for user-space apps]

On 04-12-2017 14:53, Alexey Brodkin wrote: > Full log you may find below. Sorry but I meant /var/log/Xorg.0.log file.

Re: xf86-video-armada via UDL [was: Re: UDL's fbdev doesn't work for user-space apps]

On 04-12-2017 14:53, Alexey Brodkin wrote: > Full log you may find below. Sorry but I meant /var/log/Xorg.0.log file.

Re: xf86-video-armada via UDL [was: Re: UDL's fbdev doesn't work for user-space apps]

On 04-12-2017 13:16, Alexey Brodkin wrote: > Option "kmsdev" "/dev/dri/card1" Which drm driver uses /dev/dri/card0? I'm seing drmOpen code and if you don't specify the busID it will fallback for the first card that matches "armada-drm" or "imx-drm" or "udl". > But if I swap

Re: xf86-video-armada via UDL [was: Re: UDL's fbdev doesn't work for user-space apps]

On 04-12-2017 13:16, Alexey Brodkin wrote: > Option "kmsdev" "/dev/dri/card1" Which drm driver uses /dev/dri/card0? I'm seing drmOpen code and if you don't specify the busID it will fallback for the first card that matches "armada-drm" or "imx-drm" or "udl". > But if I swap

Re: UDL's fbdev doesn't work for user-space apps

Hi Alexey, On 04-12-2017 11:32, Alexey Brodkin wrote: > My first [probably incorrect] assumption is Xserver requires fbdev (/dev/fbX) > and it cannot use DRI video card natively. Is that correct? > > Xserver can use DRI directly, you need to enable modesetting driver in Xorg config or use the

Re: UDL's fbdev doesn't work for user-space apps

Hi Alexey, On 04-12-2017 11:32, Alexey Brodkin wrote: > My first [probably incorrect] assumption is Xserver requires fbdev (/dev/fbX) > and it cannot use DRI video card natively. Is that correct? > > Xserver can use DRI directly, you need to enable modesetting driver in Xorg config or use the

Re: PROBLEM: Asus C201 video mode problems on HDMI hotplug (regression)

On 03-12-2017 05:20, Nick Bowler wrote: > > Your patch changes things. With this applied on top of 4.15-rc1 > it is failing 100% of the time instead of only half of the time. Ok, it was a long shot anyway. > > I brought the original test equipment back to the setup so I can > see the video and

Re: PROBLEM: Asus C201 video mode problems on HDMI hotplug (regression)

On 03-12-2017 05:20, Nick Bowler wrote: > > Your patch changes things. With this applied on top of 4.15-rc1 > it is failing 100% of the time instead of only half of the time. Ok, it was a long shot anyway. > > I brought the original test equipment back to the setup so I can > see the video and

Re: PROBLEM: Asus C201 video mode problems on HDMI hotplug (regression)

Hi Nick, On 01-12-2017 00:11, Nick Bowler wrote: > Hi, > > On 2017-11-27 22:30 -0500, Nick Bowler wrote: >> A note about the test setup: I had to remove the test equipment so I >> no longer have any information about the video mode from the sink side >> (like in the photos). Thus, with the

Re: PROBLEM: Asus C201 video mode problems on HDMI hotplug (regression)

Hi Nick, On 01-12-2017 00:11, Nick Bowler wrote: > Hi, > > On 2017-11-27 22:30 -0500, Nick Bowler wrote: >> A note about the test setup: I had to remove the test equipment so I >> no longer have any information about the video mode from the sink side >> (like in the photos). Thus, with the

Re: [PATCH v8 0/5] Synopsys Designware HDMI Video Capture Controller + PHY

equested' since it depends >> on >> Sakari's subnotifier work. Once that is accepted I assume you'll make a v9 >> on top >> and then this can hopefully be merged. >> >> Regards, >> >> Hans >> >> On 10/07/17 17:46, Jose Abreu wrote: &

Re: [PATCH v8 0/5] Synopsys Designware HDMI Video Capture Controller + PHY

equested' since it depends >> on >> Sakari's subnotifier work. Once that is accepted I assume you'll make a v9 >> on top >> and then this can hopefully be merged. >> >> Regards, >> >> Hans >> >> On 10/07/17 17:46, Jose Abreu wrote: &

Re: [PATCH v2 04/11] media: rkisp1: add Rockchip MIPI Synopsys DPHY driver

++ Joao, ++ Luis Hi Hans, We will take a look into this. Thanks for pointing this out! Best Regards, Jose Miguel Abreu On 27-11-2017 12:01, Hans Verkuil wrote: > I'm CC-ing Jose Abreu from Synopsys to this. Jose, can you or a colleague take > a look at this as well? > > Jacob, I ha

Re: [PATCH v2 04/11] media: rkisp1: add Rockchip MIPI Synopsys DPHY driver

++ Joao, ++ Luis Hi Hans, We will take a look into this. Thanks for pointing this out! Best Regards, Jose Miguel Abreu On 27-11-2017 12:01, Hans Verkuil wrote: > I'm CC-ing Jose Abreu from Synopsys to this. Jose, can you or a colleague take > a look at this as well? > > Jacob, I ha

Re: [PATCH AUTOSEL for 4.9 44/56] ASoC: dwc: Fix PIO mode initialization

On 15-11-2017 13:20, Mark Brown wrote: > > Why on earth would anyone use audio hardware without DMA in production > (or make it for that matter)? Not that it really matters. That was my thought while I was implementing this. I guess HW guys had their reasons. > Even if > there are users on

Re: [PATCH AUTOSEL for 4.9 44/56] ASoC: dwc: Fix PIO mode initialization

On 15-11-2017 13:20, Mark Brown wrote: > > Why on earth would anyone use audio hardware without DMA in production > (or make it for that matter)? Not that it really matters. That was my thought while I was implementing this. I guess HW guys had their reasons. > Even if > there are users on

Re: [PATCH AUTOSEL for 4.9 44/56] ASoC: dwc: Fix PIO mode initialization

Hi Mark, On 15-11-2017 10:54, Mark Brown wrote: > On Wed, Nov 15, 2017 at 02:45:45AM +, alexander.le...@verizon.com wrote: > >> We can no longer rely on the return value of >> devm_snd_dmaengine_pcm_register(...) to check if the DMA >> handle is declared in the DT. >> Previously this check

Re: [PATCH AUTOSEL for 4.9 44/56] ASoC: dwc: Fix PIO mode initialization

Hi Mark, On 15-11-2017 10:54, Mark Brown wrote: > On Wed, Nov 15, 2017 at 02:45:45AM +, alexander.le...@verizon.com wrote: > >> We can no longer rely on the return value of >> devm_snd_dmaengine_pcm_register(...) to check if the DMA >> handle is declared in the DT. >> Previously this check

[PATCH v2 net-next] net: stmmac: Add support for DWMAC5 with TSN features

transmission in this time window/slot. FPE: The IEEE802.1Qbu defines a mechanism which breaks interfering frames into smaller fragments shuch that we have a more efficient use of network bandwidth. This needs EST enabled. Signed-off-by: Jose Abreu <joab...@synopsys.com> Cc: David S. Mill

[PATCH v2 net-next] net: stmmac: Add support for DWMAC5 with TSN features

transmission in this time window/slot. FPE: The IEEE802.1Qbu defines a mechanism which breaks interfering frames into smaller fragments shuch that we have a more efficient use of network bandwidth. This needs EST enabled. Signed-off-by: Jose Abreu Cc: David S. Miller Cc: Joao Pinto Cc: Giuseppe

Re: [PATCH net-next 2/2] bindings: net: stmmac: Add documentation for TSN parameters

Hi Peppe, On 27-10-2017 13:29, Giuseppe CAVALLARO wrote: > Hello > > On 10/27/2017 11:05 AM, Jose Abreu wrote: >> I think we should take advantage of the fact that this is working >> and ready to be merged. Its just HW configuration but maybe it >> can serve as momentu

Re: [PATCH net-next 2/2] bindings: net: stmmac: Add documentation for TSN parameters

Hi Peppe, On 27-10-2017 13:29, Giuseppe CAVALLARO wrote: > Hello > > On 10/27/2017 11:05 AM, Jose Abreu wrote: >> I think we should take advantage of the fact that this is working >> and ready to be merged. Its just HW configuration but maybe it >> can serve as momentu

Re: [PATCH net-next 2/2] bindings: net: stmmac: Add documentation for TSN parameters

Hi Andrew, On 26-10-2017 22:56, Andrew Lunn wrote: >> About my patches, what I think would be better now would be to >> drop the configuration by DT and integrate the remaining >> configuration, letting the EST parameters be populated by SoC >> specific wrappers. > Hi Jose > > The problem with

Re: [PATCH net-next 2/2] bindings: net: stmmac: Add documentation for TSN parameters

Hi Andrew, On 26-10-2017 22:56, Andrew Lunn wrote: >> About my patches, what I think would be better now would be to >> drop the configuration by DT and integrate the remaining >> configuration, letting the EST parameters be populated by SoC >> specific wrappers. > Hi Jose > > The problem with

Re: [PATCH net-next 2/2] bindings: net: stmmac: Add documentation for TSN parameters

Hi Jesus, On 26-10-2017 17:23, Jesus Sanchez-Palencia wrote: > Hi Jose, > > > On 10/26/2017 03:08 AM, Jose Abreu wrote: >> Hi Andrew, >> >> On 26-10-2017 10:03, Andrew Lunn wrote: >>>> These parameters may also need to change in runtime depending on >

Re: [PATCH net-next 2/2] bindings: net: stmmac: Add documentation for TSN parameters

Hi Jesus, On 26-10-2017 17:23, Jesus Sanchez-Palencia wrote: > Hi Jose, > > > On 10/26/2017 03:08 AM, Jose Abreu wrote: >> Hi Andrew, >> >> On 26-10-2017 10:03, Andrew Lunn wrote: >>>> These parameters may also need to change in runtime depending on >

Re: [PATCH net-next 0/2] net: stmmac: Support DWMAC5 and TSN

Hi Jesus, On 26-10-2017 17:28, Jesus Sanchez-Palencia wrote: > Hi Jose, > > > On 10/25/2017 07:02 AM, Jose Abreu wrote: >> Hi, >> >> This adds support for a new IP version (5) of dwmac and for >> TSN features as defined by IEEE802.1Qbv-2015 and IEEE802.1Qbu

Re: [PATCH net-next 0/2] net: stmmac: Support DWMAC5 and TSN

Hi Jesus, On 26-10-2017 17:28, Jesus Sanchez-Palencia wrote: > Hi Jose, > > > On 10/25/2017 07:02 AM, Jose Abreu wrote: >> Hi, >> >> This adds support for a new IP version (5) of dwmac and for >> TSN features as defined by IEEE802.1Qbv-2015 and IEEE802.1Qbu

Re: [PATCH net] net: stmmac: First Queue must always be in DCB mode

On 26-10-2017 15:44, Bhadram Varka wrote: > Hi Jose, > >> -Original Message----- >> From: Jose Abreu [mailto:jose.ab...@synopsys.com] >> Sent: Thursday, October 26, 2017 5:19 PM >> To: Bhadram Varka <vbhad...@nvidia.com>; net...@vger.kernel.org; >>

Re: [PATCH net] net: stmmac: First Queue must always be in DCB mode

On 26-10-2017 15:44, Bhadram Varka wrote: > Hi Jose, > >> -Original Message----- >> From: Jose Abreu [mailto:jose.ab...@synopsys.com] >> Sent: Thursday, October 26, 2017 5:19 PM >> To: Bhadram Varka ; net...@vger.kernel.org; >> linux-kernel@vger.kernel.org

Re: [PATCH net] net: stmmac: First Queue must always be in DCB mode

Hi Bhadram, On 26-10-2017 11:51, Bhadram Varka wrote: > Hi Jose, > >> -Original Message- >> From: netdev-ow...@vger.kernel.org [mailto:netdev- >> ow...@vger.kernel.org] On Behalf Of Jose Abreu >> Sent: Thursday, October 26, 2017 2:37 PM >> To:

Re: [PATCH net] net: stmmac: First Queue must always be in DCB mode

Hi Bhadram, On 26-10-2017 11:51, Bhadram Varka wrote: > Hi Jose, > >> -Original Message- >> From: netdev-ow...@vger.kernel.org [mailto:netdev- >> ow...@vger.kernel.org] On Behalf Of Jose Abreu >> Sent: Thursday, October 26, 2017 2:37 PM >> To:

Re: [PATCH net-next 2/2] bindings: net: stmmac: Add documentation for TSN parameters

Hi Andrew, On 26-10-2017 10:03, Andrew Lunn wrote: >> These parameters may also need to change in runtime depending on >> the scheduled traffic. Unfortunately, net subsystem does not yet >> support TSN so this will have to wait and for now we will use >> fixed parameters. > Hi Jose > > what you

Re: [PATCH net-next 2/2] bindings: net: stmmac: Add documentation for TSN parameters

Hi Andrew, On 26-10-2017 10:03, Andrew Lunn wrote: >> These parameters may also need to change in runtime depending on >> the scheduled traffic. Unfortunately, net subsystem does not yet >> support TSN so this will have to wait and for now we will use >> fixed parameters. > Hi Jose > > what you

Re: [PATCH net-next 2/2] bindings: net: stmmac: Add documentation for TSN parameters

Hi Andrew, On 26-10-2017 10:03, Andrew Lunn wrote: >> These parameters may also need to change in runtime depending on >> the scheduled traffic. Unfortunately, net subsystem does not yet >> support TSN so this will have to wait and for now we will use >> fixed parameters. > Hi Jose > > what you

Re: [PATCH net-next 2/2] bindings: net: stmmac: Add documentation for TSN parameters

Hi Andrew, On 26-10-2017 10:03, Andrew Lunn wrote: >> These parameters may also need to change in runtime depending on >> the scheduled traffic. Unfortunately, net subsystem does not yet >> support TSN so this will have to wait and for now we will use >> fixed parameters. > Hi Jose > > what you

[PATCH net] net: stmmac: First Queue must always be in DCB mode

According to DWMAC databook the first queue operating mode must always be in DCB. As MTL_QUEUE_DCB = 1, we need to always set the first queue operating mode to DCB otherwise driver will think that queue is in AVB mode (because MTL_QUEUE_AVB = 0). Signed-off-by: Jose Abreu <joab...@synopsys.

[PATCH net] net: stmmac: First Queue must always be in DCB mode

According to DWMAC databook the first queue operating mode must always be in DCB. As MTL_QUEUE_DCB = 1, we need to always set the first queue operating mode to DCB otherwise driver will think that queue is in AVB mode (because MTL_QUEUE_AVB = 0). Signed-off-by: Jose Abreu Cc: Joao Pinto Cc

[PATCH net] net: stmmac: dwc-qos-eth: Fix typo in DT bindings parsing

According to DT bindings documentation we are expecting a property called "snps,read-requests" but we are parsing instead a property called "read,read-requests". This is clearly a typo. Fix it. Signed-off-by: Jose Abreu <joab...@synopsys.com> Cc: Joao Pinto <jpi

[PATCH net] net: stmmac: dwc-qos-eth: Fix typo in DT bindings parsing

According to DT bindings documentation we are expecting a property called "snps,read-requests" but we are parsing instead a property called "read,read-requests". This is clearly a typo. Fix it. Signed-off-by: Jose Abreu Cc: Joao Pinto Cc: David S. Miller Cc: Giuseppe Cava

Re: [PATCH net-next 2/2] bindings: net: stmmac: Add documentation for TSN parameters

Hi Florian, On 25-10-2017 20:34, Florian Fainelli wrote: > On 10/25/2017 07:04 AM, Jose Abreu wrote: >> This adds the documentation for TSN feature EST and FP. >> >> Signed-off-by: Jose Abreu <joab...@synopsys.com> >> Cc: David S. Miller <da...@d

Re: [PATCH net-next 2/2] bindings: net: stmmac: Add documentation for TSN parameters

Hi Florian, On 25-10-2017 20:34, Florian Fainelli wrote: > On 10/25/2017 07:04 AM, Jose Abreu wrote: >> This adds the documentation for TSN feature EST and FP. >> >> Signed-off-by: Jose Abreu >> Cc: David S. Miller >> Cc: Joao Pinto >> Cc: Giuseppe Ca

[PATCH net-next 2/2] bindings: net: stmmac: Add documentation for TSN parameters

This adds the documentation for TSN feature EST and FP. Signed-off-by: Jose Abreu <joab...@synopsys.com> Cc: David S. Miller <da...@davemloft.net> Cc: Joao Pinto <jpi...@synopsys.com> Cc: Giuseppe Cavallaro <peppe.cavall...@st.com> Cc: Alexandre Torgue <alexandre.tor

<    1   2   3   4   5   6   7   8   9   10   >