* Re: [RFC PATCH] media/doc: Allow sizeimage to be set by v4l clients
From: Stanimir Varbanov @ 2019-04-10 14:52 UTC (permalink / raw)
To: Hans Verkuil, linux-media
Cc: Mauro Carvalho Chehab, linux-kernel, linux-arm-msm,
Vikash Garodia, Tomasz Figa, Alexandre Courbot, Malathi Gottam
In-Reply-To: <f374662e-64f8-d280-21f8-892c70b6b29e@xs4all.nl>
On 4/10/19 5:39 PM, Hans Verkuil wrote:
> On 4/10/19 4:21 PM, Stanimir Varbanov wrote:
>> Hi Hans,
>>
>> On 3/14/19 3:11 PM, Hans Verkuil wrote:
>>> On 1/21/19 11:48 AM, Stanimir Varbanov wrote:
>>>> Hi Hans,
>>>>
>>>> On 1/18/19 11:13 AM, Hans Verkuil wrote:
>>>>> On 1/16/19 1:37 PM, Stanimir Varbanov wrote:
>>>>>> This changes v4l2_pix_format and v4l2_plane_pix_format sizeimage
>>>>>> field description to allow v4l clients to set bigger image size
>>>>>> in case of variable length compressed data.
>>>>>>
>>>>>> Signed-off-by: Stanimir Varbanov <stanimir.varbanov@linaro.org>
>>>>>> ---
>>>>>> Documentation/media/uapi/v4l/pixfmt-v4l2-mplane.rst | 5 ++++-
>>>>>> Documentation/media/uapi/v4l/pixfmt-v4l2.rst | 3 ++-
>>>>>> 2 files changed, 6 insertions(+), 2 deletions(-)
>>>>>>
>>>>>> diff --git a/Documentation/media/uapi/v4l/pixfmt-v4l2-mplane.rst b/Documentation/media/uapi/v4l/pixfmt-v4l2-mplane.rst
>>>>>> index 7f82dad9013a..dbe0b74e9ba4 100644
>>>>>> --- a/Documentation/media/uapi/v4l/pixfmt-v4l2-mplane.rst
>>>>>> +++ b/Documentation/media/uapi/v4l/pixfmt-v4l2-mplane.rst
>>>>>> @@ -30,7 +30,10 @@ describing all planes of that format.
>>>>>>
>>>>>> * - __u32
>>>>>> - ``sizeimage``
>>>>>> - - Maximum size in bytes required for image data in this plane.
>>>>>> + - Maximum size in bytes required for image data in this plane,
>>>>>> + set by the driver. When the image consists of variable length
>>>>>> + compressed data this is the maximum number of bytes required
>>>>>> + to hold an image, and it is allowed to be set by the client.
>>>>>> * - __u32
>>>>>> - ``bytesperline``
>>>>>> - Distance in bytes between the leftmost pixels in two adjacent
>>>>>> diff --git a/Documentation/media/uapi/v4l/pixfmt-v4l2.rst b/Documentation/media/uapi/v4l/pixfmt-v4l2.rst
>>>>>> index 71eebfc6d853..54b6d2b67bd7 100644
>>>>>> --- a/Documentation/media/uapi/v4l/pixfmt-v4l2.rst
>>>>>> +++ b/Documentation/media/uapi/v4l/pixfmt-v4l2.rst
>>>>>> @@ -89,7 +89,8 @@ Single-planar format structure
>>>>>> - Size in bytes of the buffer to hold a complete image, set by the
>>>>>> driver. Usually this is ``bytesperline`` times ``height``. When
>>>>>> the image consists of variable length compressed data this is the
>>>>>> - maximum number of bytes required to hold an image.
>>>>>> + maximum number of bytes required to hold an image, and it is
>>>>>> + allowed to be set by the client.
>>>>>> * - __u32
>>>>>> - ``colorspace``
>>>>>> - Image colorspace, from enum :c:type:`v4l2_colorspace`.
>>>>>>
>>>>>
>>>>> Hmm. "maximum number of bytes required to hold an image": that's not actually true
>>>>> for bitstream formats like MPEG. It's just the size of the buffer used to store the
>>>>> bitstream, i.e. one buffer may actually contain multiple compressed images, or a
>>>>> compressed image is split over multiple buffers.
>>>>>
>>>>
>>>> Do you want me to change something in the current documentation, i.e.
>>>> the quoted above?
>>>
>>> Hmm, it looks like this discussion stalled (i.e. I forgot to reply).
>>>
>>> How about this:
>>>
>>> "When the image consists of variable length compressed data this is the
>>> number of bytes required by the encoder to support the worst-case
>>
>> I don't think 'encoder' is the right word here:
>>
>> s/encoder/encoder or decoder
>
> or perhaps just 'codec'? Either is fine by me.
OK, then just 'codec'.
>
>>
>>> compression scenario. Clients are allowed to set this field. However,
>>> drivers may ignore the value or modify it."
>>
>> Can we rephrase to:
>>
>> "Clients are allowed to set sizeimage field, but however drivers my
>> ignore the value or modify it."
>>
>
> How about this:
>
> "Clients are allowed to set the sizeimage field, but drivers may
> modify it."
I'm fine with that.
I'll send with those changes and as regular patch. Thanks!
>
> 'ignore the value' isn't right, since that suggests that the sizeimage
> value that is returned may not be in actual use. Since sizeimage can now
> be set by userspace, this means that a sanity check is needed in drivers
> as well (i.e. what if userspace sets sizeimage to ~0?)
>
> This should be tested in v4l2-compliance as well.
>
> Regards,
>
> Hans
>
--
regards,
Stan
^ permalink raw reply
* Re: Bug: VHCI + USB 3.0
From: Alan Stern @ 2019-04-10 14:52 UTC (permalink / raw)
To: Bollinger, Seth; +Cc: Ming Lei, Jens Axboe, USB list, linux-block
In-Reply-To: <D5C0CBE7-AD66-4CF6-AD7D-2A0064FDA464@digi.com>
On Wed, 10 Apr 2019, Bollinger, Seth wrote:
> > On Apr 9, 2019, at 2:13 PM, Bollinger, Seth <Seth.Bollinger@digi.com<mailto:Seth.Bollinger@digi.com>> wrote:
> >
> > > Seth, you can try adding:
> > >
> > > blk_queue_virt_boundary(sdev->request_queue, 1024 - 1)
> > >
> > > in drivers/usb/storage/scsiglue.c:slave_alloc(), just after the call to
> > > blk_queue_update_dma_alignment(). Perhaps that will help
> > >
> >
> > I will do that as a test. However, I’m concerned that we’re solving only a specific case. Won’t it fail in a similar way if a different subsystem does the same thing (USB modem or > video drivers, etc.)?
>
> Just to follow up, this does seem to solve the specific problem.
Great! Okay, here's an actual patch for you to try. I have removed
the blk_queue_update_dma_alignment() call because it doesn't seem to
be necessary. The starting location of each scatterlist element is
unimportant; only the length matters.
If this works, I will submit it as a bugfix for the kernel.
Alan Stern
drivers/usb/storage/scsiglue.c | 21 ++++++++-------------
1 file changed, 8 insertions(+), 13 deletions(-)
Index: usb-4.x/drivers/usb/storage/scsiglue.c
===================================================================
--- usb-4.x.orig/drivers/usb/storage/scsiglue.c
+++ usb-4.x/drivers/usb/storage/scsiglue.c
@@ -65,6 +65,7 @@ static const char* host_info(struct Scsi
static int slave_alloc (struct scsi_device *sdev)
{
struct us_data *us = host_to_us(sdev->host);
+ int maxp;
/*
* Set the INQUIRY transfer length to 36. We don't use any of
@@ -74,22 +75,16 @@ static int slave_alloc (struct scsi_devi
sdev->inquiry_len = 36;
/*
- * USB has unusual DMA-alignment requirements: Although the
- * starting address of each scatter-gather element doesn't matter,
+ * USB has unusual scatter-gather requirements: Although the
+ * starting address of each scatterlist element doesn't matter,
* the length of each element except the last must be divisible
- * by the Bulk maxpacket value. There's currently no way to
- * express this by block-layer constraints, so we'll cop out
- * and simply require addresses to be aligned at 512-byte
- * boundaries. This is okay since most block I/O involves
- * hardware sectors that are multiples of 512 bytes in length,
- * and since host controllers up through USB 2.0 have maxpacket
- * values no larger than 512.
+ * by the Bulk maxpacket value. Fortunately this value is always
+ * a power of 2.
*
- * But it doesn't suffice for Wireless USB, where Bulk maxpacket
- * values can be as large as 2048. To make that work properly
- * will require changes to the block layer.
+ * Inform the block layer about this requirement.
*/
- blk_queue_update_dma_alignment(sdev->request_queue, (512 - 1));
+ maxp = usb_maxpacket(us->pusb_dev, us->recv_bulk_pipe, 0);
+ blk_queue_virt_boundary(sdev->request_queue, maxp - 1);
/* Tell the SCSI layer if we know there is more than one LUN */
if (us->protocol == USB_PR_BULK && us->max_lun > 0)
^ permalink raw reply
* Bug: VHCI + USB 3.0
From: Alan Stern @ 2019-04-10 14:52 UTC (permalink / raw)
To: Bollinger, Seth; +Cc: Ming Lei, Jens Axboe, USB list, linux-block
On Wed, 10 Apr 2019, Bollinger, Seth wrote:
> > On Apr 9, 2019, at 2:13 PM, Bollinger, Seth <Seth.Bollinger@digi.com<mailto:Seth.Bollinger@digi.com>> wrote:
> >
> > > Seth, you can try adding:
> > >
> > > blk_queue_virt_boundary(sdev->request_queue, 1024 - 1)
> > >
> > > in drivers/usb/storage/scsiglue.c:slave_alloc(), just after the call to
> > > blk_queue_update_dma_alignment(). Perhaps that will help
> > >
> >
> > I will do that as a test. However, I’m concerned that we’re solving only a specific case. Won’t it fail in a similar way if a different subsystem does the same thing (USB modem or > video drivers, etc.)?
>
> Just to follow up, this does seem to solve the specific problem.
Great! Okay, here's an actual patch for you to try. I have removed
the blk_queue_update_dma_alignment() call because it doesn't seem to
be necessary. The starting location of each scatterlist element is
unimportant; only the length matters.
If this works, I will submit it as a bugfix for the kernel.
Alan Stern
drivers/usb/storage/scsiglue.c | 21 ++++++++-------------
1 file changed, 8 insertions(+), 13 deletions(-)
Index: usb-4.x/drivers/usb/storage/scsiglue.c
===================================================================
--- usb-4.x.orig/drivers/usb/storage/scsiglue.c
+++ usb-4.x/drivers/usb/storage/scsiglue.c
@@ -65,6 +65,7 @@ static const char* host_info(struct Scsi
static int slave_alloc (struct scsi_device *sdev)
{
struct us_data *us = host_to_us(sdev->host);
+ int maxp;
/*
* Set the INQUIRY transfer length to 36. We don't use any of
@@ -74,22 +75,16 @@ static int slave_alloc (struct scsi_devi
sdev->inquiry_len = 36;
/*
- * USB has unusual DMA-alignment requirements: Although the
- * starting address of each scatter-gather element doesn't matter,
+ * USB has unusual scatter-gather requirements: Although the
+ * starting address of each scatterlist element doesn't matter,
* the length of each element except the last must be divisible
- * by the Bulk maxpacket value. There's currently no way to
- * express this by block-layer constraints, so we'll cop out
- * and simply require addresses to be aligned at 512-byte
- * boundaries. This is okay since most block I/O involves
- * hardware sectors that are multiples of 512 bytes in length,
- * and since host controllers up through USB 2.0 have maxpacket
- * values no larger than 512.
+ * by the Bulk maxpacket value. Fortunately this value is always
+ * a power of 2.
*
- * But it doesn't suffice for Wireless USB, where Bulk maxpacket
- * values can be as large as 2048. To make that work properly
- * will require changes to the block layer.
+ * Inform the block layer about this requirement.
*/
- blk_queue_update_dma_alignment(sdev->request_queue, (512 - 1));
+ maxp = usb_maxpacket(us->pusb_dev, us->recv_bulk_pipe, 0);
+ blk_queue_virt_boundary(sdev->request_queue, maxp - 1);
/* Tell the SCSI layer if we know there is more than one LUN */
if (us->protocol == USB_PR_BULK && us->max_lun > 0)
^ permalink raw reply
* Re: [PATCH] x86/entry/64: randomize kernel stack offset upon syscall
From: Andy Lutomirski @ 2019-04-10 14:52 UTC (permalink / raw)
To: Reshetova, Elena
Cc: Ingo Molnar, Josh Poimboeuf, luto@kernel.org,
linux-kernel@vger.kernel.org, keescook@chromium.org,
jannh@google.com, Perla, Enrico, mingo@redhat.com, bp@alien8.de,
tglx@linutronix.de, peterz@infradead.org,
gregkh@linuxfoundation.org
In-Reply-To: <2236FBA76BA1254E88B949DDB74E612BA4C48B15@IRSMSX102.ger.corp.intel.com>
On Wed, Apr 10, 2019 at 3:24 AM Reshetova, Elena
<elena.reshetova@intel.com> wrote:
>
>
> > > > On Mon, Apr 08, 2019 at 09:13:58AM +0300, Elena Reshetova wrote:
> > > > > diff --git a/arch/x86/entry/common.c b/arch/x86/entry/common.c
> > > > > index 7bc105f47d21..38ddc213a5e9 100644
> > > > > --- a/arch/x86/entry/common.c
> > > > > +++ b/arch/x86/entry/common.c
> > > > > @@ -35,6 +35,12 @@
> > > > > #define CREATE_TRACE_POINTS
> > > > > #include <trace/events/syscalls.h>
> > > > >
> > > > > +#ifdef CONFIG_RANDOMIZE_KSTACK_OFFSET
> > > > > +#include <linux/random.h>
> > > > > +
> > > > > +void *alloca(size_t size);
> > > > > +#endif
> > > > > +
> > > > > #ifdef CONFIG_CONTEXT_TRACKING
> > > > > /* Called on entry from user mode with IRQs off. */
> > > > > __visible inline void enter_from_user_mode(void)
> > > > > @@ -273,6 +279,13 @@ __visible void do_syscall_64(unsigned long nr, struct
> > > pt_regs *regs)
> > > > > {
> > > > > struct thread_info *ti;
> > > > >
> > > > > +#ifdef CONFIG_RANDOMIZE_KSTACK_OFFSET
> > > > > + size_t offset = ((size_t)prandom_u32()) % 256;
> > > > > + char *ptr = alloca(offset);
> > > > > +
> > > > > + asm volatile("":"=m"(*ptr));
> > > > > +#endif
> > > > > +
> > > > > enter_from_user_mode();
> > > > > local_irq_enable();
> > > > > ti = current_thread_info();
> > > >
> > > > Would it make sense to also do this for the compat syscalls
> > > > (do_fast_syscall_32, do_int80_syscall_32)?
> > >
> > > Could someone please include the full patch, with justification and
> > > performance impact analysis etc.? Can only find the code part of the
> > > thread on lkml, which leaves out this context.
> > >
> >
> > Sorry, this is very weird, I cannot find it either from lkml, but it was sent there
> > to begin with (and as visible from reply-to headers).
> >
> > Do you want me to resent original version or with "do_fast_syscall_32,
> > do_int80_syscall_32" additions (I am finishing testing them now).
>
> I will resend the original x86_64 now since this is the one I tested and
> measured properly. The 32 bit changes seem to work fine inside my 32 bit VM,
> but since I don't have any real 32 bit HW, I am hesitant to send them out without
> real HW testing and measuring.
>
> This is the asm code for 32 bits (note it requires __builtin_alloca definition and not just alloca,
> so I will change the 64 bit version to use it also):
>
> #ifdef CONFIG_RANDOMIZE_KSTACK_OFFSET
> size_t offset = ((size_t)prandom_u32()) % 256;
> 0xc10025b6 call 0xc146f7d0 <prandom_u32>
> 0xc10025bb movzbl %al,%eax
> char *ptr = __builtin_alloca(offset);
> 0xc10025be add $0x12,%eax
> 0xc10025c1 and $0x1fc,%eax
> 0xc10025c6 sub %eax,%esp
> 0xc10025c8 lea 0x27(%esp),%eax
> 0xc10025cc and $0xfffffff0,%eax
>
> Also, the result is 47 different random offsets produced,
> which is slightly better than 33 offsets for x86_64.
>
I would suggest that you macro-ify this thing:
#ifdef WHATEVER
#define add_random_stack_offset() do { void *addr = ... } while (0)
#else
#define add_random_stack_offset() do {} while (0)
#endif
since you'll end up with more than one call site.
^ permalink raw reply
* Re: [PATCH 0/2] ARM: meson: Add support for Libretech-AC
From: Neil Armstrong @ 2019-04-10 14:52 UTC (permalink / raw)
To: u-boot-amlogic; +Cc: u-boot
In-Reply-To: <20190326102035.9239-1-narmstrong@baylibre.com>
On 26/03/2019 11:20, Neil Armstrong wrote:
> LibreTech AC is a single board computer manufactured by Libre Technology
> with the following specifications:
>
> - Amlogic S805X ARM Cortex-A53 quad-core SoC @ 1.2GHz
> - ARM Mali 450 GPU
> - 512MiB DDR4 SDRAM
> - 10/100 Ethernet
> - HDMI 2.0 4K/60Hz display
> - 40-pin GPIO header
> - 4 x USB 2.0 Host
> - eMMC, SPI NOR Flash
> - Infrared receiver
>
> The u-boot specific code is the same as the P212 support,
> so use the P212 board support code with a distinct defconfig
> and config include files.
>
> The patchset inports the DT from Linux 5.0 and add the corresponding
> configs and update the MAINTAINERS files.
>
> Neil Armstrong (2):
> ARM: dts: Import libretech-ac DT from Linux 5.0
> boards: Amlogic: Add support for Libretech-AC
>
> arch/arm/dts/Makefile | 1 +
> arch/arm/dts/meson-gxl-s805x-libretech-ac.dts | 248 ++++++++++++++++++
> arch/arm/dts/meson-gxl.dtsi | 70 ++++-
> board/amlogic/p212/MAINTAINERS | 1 +
> board/amlogic/p212/README.libretech-ac | 103 ++++++++
> configs/libretech-ac_defconfig | 74 ++++++
> include/configs/libretech-ac.h | 24 ++
> 7 files changed, 512 insertions(+), 9 deletions(-)
> create mode 100644 arch/arm/dts/meson-gxl-s805x-libretech-ac.dts
> create mode 100644 board/amlogic/p212/README.libretech-ac
> create mode 100644 configs/libretech-ac_defconfig
> create mode 100644 include/configs/libretech-ac.h
>
Applied both to u-boot-amlogic
Neil
^ permalink raw reply
* [U-Boot] [PATCH 0/2] ARM: meson: Add support for Libretech-AC
From: Neil Armstrong @ 2019-04-10 14:52 UTC (permalink / raw)
To: u-boot
In-Reply-To: <20190326102035.9239-1-narmstrong@baylibre.com>
On 26/03/2019 11:20, Neil Armstrong wrote:
> LibreTech AC is a single board computer manufactured by Libre Technology
> with the following specifications:
>
> - Amlogic S805X ARM Cortex-A53 quad-core SoC @ 1.2GHz
> - ARM Mali 450 GPU
> - 512MiB DDR4 SDRAM
> - 10/100 Ethernet
> - HDMI 2.0 4K/60Hz display
> - 40-pin GPIO header
> - 4 x USB 2.0 Host
> - eMMC, SPI NOR Flash
> - Infrared receiver
>
> The u-boot specific code is the same as the P212 support,
> so use the P212 board support code with a distinct defconfig
> and config include files.
>
> The patchset inports the DT from Linux 5.0 and add the corresponding
> configs and update the MAINTAINERS files.
>
> Neil Armstrong (2):
> ARM: dts: Import libretech-ac DT from Linux 5.0
> boards: Amlogic: Add support for Libretech-AC
>
> arch/arm/dts/Makefile | 1 +
> arch/arm/dts/meson-gxl-s805x-libretech-ac.dts | 248 ++++++++++++++++++
> arch/arm/dts/meson-gxl.dtsi | 70 ++++-
> board/amlogic/p212/MAINTAINERS | 1 +
> board/amlogic/p212/README.libretech-ac | 103 ++++++++
> configs/libretech-ac_defconfig | 74 ++++++
> include/configs/libretech-ac.h | 24 ++
> 7 files changed, 512 insertions(+), 9 deletions(-)
> create mode 100644 arch/arm/dts/meson-gxl-s805x-libretech-ac.dts
> create mode 100644 board/amlogic/p212/README.libretech-ac
> create mode 100644 configs/libretech-ac_defconfig
> create mode 100644 include/configs/libretech-ac.h
>
Applied both to u-boot-amlogic
Neil
^ permalink raw reply
* Re: powerpc/64s/radix: Fix radix segment exception handling
From: Michael Ellerman @ 2019-04-10 14:49 UTC (permalink / raw)
To: Nicholas Piggin, linuxppc-dev
Cc: Aneesh Kumar K . V, Nicholas Piggin, Anton Blanchard
In-Reply-To: <20190329074257.14428-1-npiggin@gmail.com>
On Fri, 2019-03-29 at 07:42:57 UTC, Nicholas Piggin wrote:
> Commit 48e7b76957 ("powerpc/64s/hash: Convert SLB miss handlers to C")
> broke the radix-mode segment exception handler. In radix mode, this is
> exception is not an SLB miss, rather it signals that the EA is outside
> the range translated by any page table.
>
> The commit lost the radix feature alternate code patch, which can
> cause faults to some EAs to kernel BUG at arch/powerpc/mm/slb.c:639!
>
> The original radix code would send faults to slb_miss_large_addr,
> which would end up faulting due to slb_addr_limit being 0. This patch
> sends radix directly to do_bad_slb_fault, which is a bit clearer.
>
> Fixes: 48e7b76957 ("powerpc/64s/hash: Convert SLB miss handlers to C")
> Cc: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
> Reported-by: Anton Blanchard <anton@samba.org>
> Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
> Reviewed-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
Applied to powerpc fixes, thanks.
https://git.kernel.org/powerpc/c/7100e8704b61247649c50551b965e71d
cheers
^ permalink raw reply
* Re: [PATCH 1/2] drm: panel-simple: Add simple-panel driver.
From: Heiko Stübner @ 2019-04-10 14:50 UTC (permalink / raw)
To: Christoph Muellner
Cc: Thierry Reding, David Airlie, Daniel Vetter, Rob Herring,
Mark Rutland, dri-devel, devicetree, linux-kernel
In-Reply-To: <20190410141045.58097-1-christoph.muellner@theobroma-systems.com>
Hi Christoph,
Am Mittwoch, 10. April 2019, 16:10:44 CEST schrieb Christoph Muellner:
> On our RK3399-Q7 EVK base board we have the option to connect an arbitrary
> monitor via DP cable. The actual monitor is therefore not known in advance.
> This means, we don't have any panel information besides the EDID
> data from the device itself.
Just so I understand correctly, you have a real dp-connector wired to
the Analogix dp-controller, and therefore want to connect actual
monitors to it.
So the problem you're trying to work around is probably that the
rockchip-driver of the analogix controller explictly expects a bridge
to be present during probe, right?
I think hacking up the panel-driver is not an ideal approach:
(1) bridges/panels do expect to stay connected all the time
and are meant for devices with actual hard-wired displays with specific
power-sequence requirements
(2) devicetree is expected to describe the real hardware, therefore the
dt should not describe one thing while the actual hardware is really
different
So, I guess a more ideal approach could perhaps be to:
(1) define a "dp-connector" devicetree binding, see
Documentation/devicetree/bindings/display/connector/hdmi-connector.txt
for a similar one
(2) steal an idea from drivers/gpu/drm/mediatek/mtk_hdmi.c and check
for that new compatible:
if (!of_device_is_compatible(remote, "hdmi-connector")) {
//move bridge handling here
}
and modify both the rockchip-part and the generic analogix bridge code
to work with the connector declared instead of a panel?
Heiko
> The functionality for a 'simple-panel' has been remove a couple
> of years ago with 81cf32b. This patch brings this feature back.
>
> Signed-off-by: Christoph Muellner <christoph.muellner@theobroma-systems.com>
> ---
> drivers/gpu/drm/panel/panel-simple.c | 24 ++++++++++++++++--------
> 1 file changed, 16 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c
> index 9e8218f6a3f2..1f69283f3e4b 100644
> --- a/drivers/gpu/drm/panel/panel-simple.c
> +++ b/drivers/gpu/drm/panel/panel-simple.c
> @@ -176,7 +176,7 @@ static int panel_simple_disable(struct drm_panel *panel)
> backlight_update_status(p->backlight);
> }
>
> - if (p->desc->delay.disable)
> + if (p->desc && p->desc->delay.disable)
> msleep(p->desc->delay.disable);
>
> p->enabled = false;
> @@ -195,7 +195,7 @@ static int panel_simple_unprepare(struct drm_panel *panel)
>
> regulator_disable(p->supply);
>
> - if (p->desc->delay.unprepare)
> + if (p->desc && p->desc->delay.unprepare)
> msleep(p->desc->delay.unprepare);
>
> p->prepared = false;
> @@ -220,11 +220,13 @@ static int panel_simple_prepare(struct drm_panel *panel)
>
> gpiod_set_value_cansleep(p->enable_gpio, 1);
>
> - delay = p->desc->delay.prepare;
> - if (p->no_hpd)
> - delay += p->desc->delay.hpd_absent_delay;
> - if (delay)
> - msleep(delay);
> + if (p->desc) {
> + delay = p->desc->delay.prepare;
> + if (p->no_hpd)
> + delay += p->desc->delay.hpd_absent_delay;
> + if (delay)
> + msleep(delay);
> + }
>
> p->prepared = true;
>
> @@ -238,7 +240,7 @@ static int panel_simple_enable(struct drm_panel *panel)
> if (p->enabled)
> return 0;
>
> - if (p->desc->delay.enable)
> + if (p->desc && p->desc->delay.enable)
> msleep(p->desc->delay.enable);
>
> if (p->backlight) {
> @@ -280,6 +282,9 @@ static int panel_simple_get_timings(struct drm_panel *panel,
> struct panel_simple *p = to_panel_simple(panel);
> unsigned int i;
>
> + if (!p->desc)
> + return 0;
> +
> if (p->desc->num_timings < num_timings)
> num_timings = p->desc->num_timings;
>
> @@ -2536,6 +2541,9 @@ static const struct panel_desc arm_rtsm = {
>
> static const struct of_device_id platform_of_match[] = {
> {
> + .compatible = "simple-panel",
> + .data = NULL,
> + }, {
> .compatible = "ampire,am-480272h3tmqw-t01h",
> .data = &ire_am_480272h3tmqw_t01h,
> }, {
>
^ permalink raw reply
* Re: [PATCH] i2c: meson: add configurable divider factors
From: Neil Armstrong @ 2019-04-10 14:50 UTC (permalink / raw)
To: Guillaume La Roque, hs, u-boot-amlogic, u-boot
In-Reply-To: <20190322134932.17103-1-glaroque@baylibre.com>
On 22/03/2019 14:49, Guillaume La Roque wrote:
> This patch add support for I2C controller in Meson-AXG SoC,
> Due to the IP changes between I2C controller, we need to introduce
> a compatible data to make the divider factor configurable.
>
> backport from linux:
> 931b18e92cd0 ("2c: meson: add configurable divider factors")
>
> Signed-off-by: Guillaume La Roque <glaroque@baylibre.com>
> ---
> drivers/i2c/meson_i2c.c | 30 +++++++++++++++++++++++++-----
> 1 file changed, 25 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/i2c/meson_i2c.c b/drivers/i2c/meson_i2c.c
> index 7d06d95cf3..ee59bac123 100644
> --- a/drivers/i2c/meson_i2c.c
> +++ b/drivers/i2c/meson_i2c.c
> @@ -41,7 +41,12 @@ struct i2c_regs {
> u32 tok_rdata1;
> };
>
> +struct meson_i2c_data {
> + unsigned char div_factor;
> +};
> +
> struct meson_i2c {
> + const struct meson_i2c_data *data;
> struct clk clk;
> struct i2c_regs *regs;
> struct i2c_msg *msg; /* Current I2C message */
> @@ -229,7 +234,7 @@ static int meson_i2c_set_bus_speed(struct udevice *bus, unsigned int speed)
> if (IS_ERR_VALUE(clk_rate))
> return -EINVAL;
>
> - div = DIV_ROUND_UP(clk_rate, speed * 4);
> + div = DIV_ROUND_UP(clk_rate, speed * i2c->data->div_factor);
>
> /* clock divider has 12 bits */
> if (div >= (1 << 12)) {
> @@ -253,6 +258,8 @@ static int meson_i2c_probe(struct udevice *bus)
> struct meson_i2c *i2c = dev_get_priv(bus);
> int ret;
>
> + i2c->data = (const struct meson_i2c_data *)dev_get_driver_data(bus);
> +
> ret = clk_get_by_index(bus, 0, &i2c->clk);
> if (ret < 0)
> return ret;
> @@ -272,11 +279,24 @@ static const struct dm_i2c_ops meson_i2c_ops = {
> .set_bus_speed = meson_i2c_set_bus_speed,
> };
>
> +static const struct meson_i2c_data i2c_meson6_data = {
> + .div_factor = 4,
> +};
> +
> +static const struct meson_i2c_data i2c_gxbb_data = {
> + .div_factor = 4,
> +};
> +
> +static const struct meson_i2c_data i2c_axg_data = {
> + .div_factor = 3,
> +};
> +
> static const struct udevice_id meson_i2c_ids[] = {
> - { .compatible = "amlogic,meson6-i2c" },
> - { .compatible = "amlogic,meson-gx-i2c" },
> - { .compatible = "amlogic,meson-gxbb-i2c" },
> - { }
> + {.compatible = "amlogic,meson6-i2c", .data = (ulong)&i2c_meson6_data},
> + {.compatible = "amlogic,meson-gx-i2c", .data = (ulong)&i2c_gxbb_data},
> + {.compatible = "amlogic,meson-gxbb-i2c", .data = (ulong)&i2c_gxbb_data},
> + {.compatible = "amlogic,meson-axg-i2c", .data = (ulong)&i2c_axg_data},
> + {}
> };
>
> U_BOOT_DRIVER(i2c_meson) = {
>
Applied to u-boot-amlogic
Thanks
^ permalink raw reply
* [U-Boot] [PATCH] i2c: meson: add configurable divider factors
From: Neil Armstrong @ 2019-04-10 14:50 UTC (permalink / raw)
To: u-boot
In-Reply-To: <20190322134932.17103-1-glaroque@baylibre.com>
On 22/03/2019 14:49, Guillaume La Roque wrote:
> This patch add support for I2C controller in Meson-AXG SoC,
> Due to the IP changes between I2C controller, we need to introduce
> a compatible data to make the divider factor configurable.
>
> backport from linux:
> 931b18e92cd0 ("2c: meson: add configurable divider factors")
>
> Signed-off-by: Guillaume La Roque <glaroque@baylibre.com>
> ---
> drivers/i2c/meson_i2c.c | 30 +++++++++++++++++++++++++-----
> 1 file changed, 25 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/i2c/meson_i2c.c b/drivers/i2c/meson_i2c.c
> index 7d06d95cf3..ee59bac123 100644
> --- a/drivers/i2c/meson_i2c.c
> +++ b/drivers/i2c/meson_i2c.c
> @@ -41,7 +41,12 @@ struct i2c_regs {
> u32 tok_rdata1;
> };
>
> +struct meson_i2c_data {
> + unsigned char div_factor;
> +};
> +
> struct meson_i2c {
> + const struct meson_i2c_data *data;
> struct clk clk;
> struct i2c_regs *regs;
> struct i2c_msg *msg; /* Current I2C message */
> @@ -229,7 +234,7 @@ static int meson_i2c_set_bus_speed(struct udevice *bus, unsigned int speed)
> if (IS_ERR_VALUE(clk_rate))
> return -EINVAL;
>
> - div = DIV_ROUND_UP(clk_rate, speed * 4);
> + div = DIV_ROUND_UP(clk_rate, speed * i2c->data->div_factor);
>
> /* clock divider has 12 bits */
> if (div >= (1 << 12)) {
> @@ -253,6 +258,8 @@ static int meson_i2c_probe(struct udevice *bus)
> struct meson_i2c *i2c = dev_get_priv(bus);
> int ret;
>
> + i2c->data = (const struct meson_i2c_data *)dev_get_driver_data(bus);
> +
> ret = clk_get_by_index(bus, 0, &i2c->clk);
> if (ret < 0)
> return ret;
> @@ -272,11 +279,24 @@ static const struct dm_i2c_ops meson_i2c_ops = {
> .set_bus_speed = meson_i2c_set_bus_speed,
> };
>
> +static const struct meson_i2c_data i2c_meson6_data = {
> + .div_factor = 4,
> +};
> +
> +static const struct meson_i2c_data i2c_gxbb_data = {
> + .div_factor = 4,
> +};
> +
> +static const struct meson_i2c_data i2c_axg_data = {
> + .div_factor = 3,
> +};
> +
> static const struct udevice_id meson_i2c_ids[] = {
> - { .compatible = "amlogic,meson6-i2c" },
> - { .compatible = "amlogic,meson-gx-i2c" },
> - { .compatible = "amlogic,meson-gxbb-i2c" },
> - { }
> + {.compatible = "amlogic,meson6-i2c", .data = (ulong)&i2c_meson6_data},
> + {.compatible = "amlogic,meson-gx-i2c", .data = (ulong)&i2c_gxbb_data},
> + {.compatible = "amlogic,meson-gxbb-i2c", .data = (ulong)&i2c_gxbb_data},
> + {.compatible = "amlogic,meson-axg-i2c", .data = (ulong)&i2c_axg_data},
> + {}
> };
>
> U_BOOT_DRIVER(i2c_meson) = {
>
Applied to u-boot-amlogic
Thanks
^ permalink raw reply
* Re: [dpdk-dev] [PATCH] doc: add guideines for initial PMD submission
From: Akhil Goyal @ 2019-04-10 14:49 UTC (permalink / raw)
To: Rami Rosen
Cc: Trahe, Fiona, dev@dpdk.org, Yigit, Ferruh, De Lara Guarch, Pablo,
Mcnamara, John, Kovacevic, Marko, stable@dpdk.org
If that is the case, then probably a reference to MAINTAINERS should be mentioned in the documentation
because there are a lot more other stuff(beyond PMDs) in DPDK where people can contribute and for that people need to
look into MAINTAINERS anyway.
Hi Akhil,
Thanks for your response. It seems to me though that the MAINTAINER file is not really part of the documentation,
it is more of a reference type of file. Not sure that new DPDK developers will know to look in it for this type of information.
I will send V2 of the patch and add event and bbdev.
Regards,
Rami Rosen
^ permalink raw reply
* [PATCH lttng-ust 1/1] Fix: don't access packet header for stream_id and stream_instance_id getters
From: Mathieu Desnoyers @ 2019-04-10 14:49 UTC (permalink / raw)
To: joraj, jgalar; +Cc: lttng-dev
The stream ID and stream instance ID are invariant for a stream, so
there is no point reading them from the packet header currently owned by
the consumer (between get/put subbuf).
Actually, the consumer try to access the stream_id from the live timer
when sending a live beacon without getting the reader subbuffer first,
which was handled by issuing a CHAN_WARN_ON, which disables tracing for
the channel, and prints warning to the consumerd console when running
consumerd with LTTNG_UST_DEBUG=1).
In the case where a ring buffer does not have any data ready, it makes
no sense to try to get a subbuffer for reading anyway, so the approach
was broken.
So return the stream id and stream instance id from the internal
data structures rather than reading it from the ring buffer.
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
---
liblttng-ust/lttng-ring-buffer-client.h | 13 +++++--------
1 file changed, 5 insertions(+), 8 deletions(-)
diff --git a/liblttng-ust/lttng-ring-buffer-client.h b/liblttng-ust/lttng-ring-buffer-client.h
index 0fae8878..ab472352 100644
--- a/liblttng-ust/lttng-ring-buffer-client.h
+++ b/liblttng-ust/lttng-ring-buffer-client.h
@@ -580,12 +580,11 @@ static int client_stream_id(struct lttng_ust_lib_ring_buffer *buf,
struct lttng_ust_shm_handle *handle,
uint64_t *stream_id)
{
- struct packet_header *header;
+ struct channel *chan = shmp(handle, buf->backend.chan);
+ struct lttng_channel *lttng_chan = channel_get_private(chan);
+
+ *stream_id = lttng_chan->id;
- header = client_packet_header(buf, handle);
- if (!header)
- return -1;
- *stream_id = header->stream_id;
return 0;
}
@@ -616,10 +615,8 @@ static int client_instance_id(struct lttng_ust_lib_ring_buffer *buf,
struct lttng_ust_shm_handle *handle,
uint64_t *id)
{
- struct packet_header *header;
+ *id = buf->backend.cpu;
- header = client_packet_header(buf, handle);
- *id = header->stream_instance_id;
return 0;
}
--
2.11.0
^ permalink raw reply related
* Re: [PATCH 1/1] x86/entry/64: randomize kernel stack offset upon syscall
From: Andy Lutomirski @ 2019-04-10 14:48 UTC (permalink / raw)
To: Ingo Molnar
Cc: Elena Reshetova, Andrew Lutomirski, LKML, Josh Poimboeuf,
Kees Cook, Jann Horn, Perla, Enrico, Ingo Molnar, Borislav Petkov,
Thomas Gleixner, Peter Zijlstra, Greg KH
In-Reply-To: <20190410114259.GB9293@gmail.com>
On Wed, Apr 10, 2019 at 4:43 AM Ingo Molnar <mingo@kernel.org> wrote:
>
>
> * Elena Reshetova <elena.reshetova@intel.com> wrote:
>
> > 2) Andy's tests, misc-tests: ./timing_test_64 10M sys_enosys
> > base: 10000000 loops in 1.62224s = 162.22 nsec / loop
> > random_offset (prandom_u32() every syscall): 10000000 loops in 1.64660s = 166.26 nsec / loop
>
> Stupid question, how did you manage to buil timing_test_64? Here it fails
> with a bog standard gcc 7.3.0 x86-64 distro toolchain:
>
> dagon:~/luto-misc-tests.git> make timing_test_64
> g++ -m64 -o timing_test_64 -O2 -g -std=gnu++11 -pthread -Wall timing_test.cc -lrt -ldl
> /usr/bin/ld: /tmp/cc8VRkuV.o: relocation R_X86_64_32S against `.text.startup' can not be used when making a PIE object; recompile with -fPIC
> /usr/bin/ld: final link failed: Nonrepresentable section on outputcollect2: error: ld returned 1 exit status
> Makefile:39: recipe for target 'timing_test_64' failed
>
I think your toolchain is screwy. If I create this file as ingo.c:
#include <stdio.h>
int main(int argc, char **argv)
{
printf("Hello world!");
return 0;
}
And build it like this, it fails:
$ gcc -o ingo -g ingo.c -pie
/usr/bin/ld: /tmp/ccofYU9N.o: relocation R_X86_64_32 against `.rodata'
can not be used when making a PIE object; recompile with -fPIC
/usr/bin/ld: final link failed: nonrepresentable section on output
collect2: error: ld returned 1 exit status
Which I assume means that -pie requires -fPIC, and your toolchain is
screwed up and is defaulting to useless options. I'm guessing you
should file a bug against your distro gcc package. For me, it works
if I remove -pie.
^ permalink raw reply
* [PATCH lttng-modules 1/1] Fix: don't access packet header for stream_id and stream_instance_id getters
From: Mathieu Desnoyers @ 2019-04-10 14:48 UTC (permalink / raw)
To: joraj, jgalar; +Cc: lttng-dev
The stream ID and stream instance ID are invariant for a stream, so
there is no point reading them from the packet header currently owned by
the consumer (between get/put subbuf).
Actually, the consumer try to access the stream_id from the live timer
when sending a live beacon without getting the reader subbuffer first,
which can trigger WARN_ON safety nets in libringbuffer. This safety
net triggers a kernel OOPS report and disables tracing for that channel.
In the case where a ring buffer does not have any data ready, it makes
no sense to try to get a subbuffer for reading anyway, so the approach
was broken.
So return the stream id and stream instance id from the internal
data structures rather than reading it from the ring buffer.
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
---
lttng-ring-buffer-client.h | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/lttng-ring-buffer-client.h b/lttng-ring-buffer-client.h
index dc3356e4..d5c512c5 100644
--- a/lttng-ring-buffer-client.h
+++ b/lttng-ring-buffer-client.h
@@ -479,9 +479,10 @@ static int client_stream_id(const struct lib_ring_buffer_config *config,
struct lib_ring_buffer *buf,
uint64_t *stream_id)
{
- struct packet_header *header = client_packet_header(config, buf);
- *stream_id = header->stream_id;
+ struct channel *chan = buf->backend.chan;
+ struct lttng_channel *lttng_chan = channel_get_private(chan);
+ *stream_id = lttng_chan->id;
return 0;
}
@@ -510,8 +511,7 @@ int client_instance_id(const struct lib_ring_buffer_config *config,
struct lib_ring_buffer *buf,
uint64_t *id)
{
- struct packet_header *header = client_packet_header(config, buf);
- *id = header->stream_instance_id;
+ *id = buf->backend.cpu;
return 0;
}
--
2.11.0
^ permalink raw reply related
* [PATCH] nvme: rdma: Fix typo in struct comment
From: Minwoo Im @ 2019-04-10 14:48 UTC (permalink / raw)
struct nvme_rdma_cm_rej has two different attributes: recfmt and sts.
And sts will have value what this comment wanted to show.
Signed-off-by: Minwoo Im <minwoo.im.dev at gmail.com>
---
include/linux/nvme-rdma.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/nvme-rdma.h b/include/linux/nvme-rdma.h
index 3aa97b98dc89..3ec8e50efa16 100644
--- a/include/linux/nvme-rdma.h
+++ b/include/linux/nvme-rdma.h
@@ -77,7 +77,7 @@ struct nvme_rdma_cm_rep {
* struct nvme_rdma_cm_rej - rdma connect reject
*
* @recfmt: format of the RDMA Private Data
- * @fsts: error status for the associated connect request
+ * @sts: error status for the associated connect request
*/
struct nvme_rdma_cm_rej {
__le16 recfmt;
--
2.17.1
^ permalink raw reply related
* Re: [PATCH 07/13] si2157: Briefly wait for tuning operation to complete
From: Brad Love @ 2019-04-10 14:48 UTC (permalink / raw)
To: Brad Love, Sean Young; +Cc: linux-media, mchehab
In-Reply-To: <af0663f0-e0ba-a468-1b17-8ba73d8d779c@nextdimension.cc>
Hi Sean,
On 08/04/2019 16.37, Brad Love wrote:
> Hi Sean,
>
>
> On 08/04/2019 15.55, Sean Young wrote:
>> On Mon, Apr 08, 2019 at 01:14:08PM -0500, Brad Love wrote:
>>> On 05/04/2019 05.29, Sean Young wrote:
>>>> On Sat, Dec 29, 2018 at 11:51:16AM -0600, Brad Love wrote:
>>>>> Some software reports no signal found on a frequency due to immediately
>>>>> checking for lock as soon as set_params returns. This waits up 40ms for
>>>>> tuning operation, then from 30-150ms (dig/analog) for signal lock before
>>>>> returning from set_params and set_analog_params.
>>>>>
>>>>> Tuning typically completes in 20-30ms. Digital tuning will additionally
>>>>> wait depending on signal characteristics. Analog tuning will wait the
>>>>> full timeout in case of no signal.
>>>> This looks like a workaround for broken userspace. Very possibly this
>>>> is software was tested on a different frontend which does wait for tuning
>>>> to complete.
>>>>
>>>> This is a change in uapi and will have to be done for all frontends, and
>>>> documented. However I doubt such a change is acceptable.
>>>>
>>>> What software are you refering to?
>>> Hi Sean,
>>>
>>> I would have to check with support to find out the various software that
>>> expect when a tune command returns for that tuning operation to have
>>> actually completed. In the current state when you tune si2157 it
>>> immediately returns, no care of the tuning operation completion, no care
>>> of the pll lock success. This is correct? Not so according to Silicon
>>> Labs documentation, which suggests a brief wait. I just took a look at
>>> other drivers, sampling only those with set_analog_params, all but two
>>> have similar code in place to actually allow the tune operation time to
>>> complete (both digital and analog) before returning to userland. The
>>> other drivers just insert arbitrary time delays to accommodate the
>>> operations completion time. At least with my patch I am monitoring the
>>> hardware to know when the operation actually completes.
>>>
>>> I see in tuners (not frontends):
>>>
>>> mt2063 - waits up to 100ms for lock status and return
>>> r820t - sleep 100ms for pll lock status and return
>>> tda827x - 170-500ms wait after tune before checking status and return
>>> tda8290 - sleep 100ms up to 3x while checking tune status and return
>>> tuner-xc2028 - sleep for 110ms awaiting lock status and return
>>> xc4000 - 10ms sleep after tune, unless debug, then 100ms and return
>>> xc5000 - 20ms sleep after tune, if pll not locked, re-tune and sleep
>>> again, repeat until success and return
>>>
>>> There's also other arbitrary sleeps peppered throughout the operations.
>>>
>>> Then you have si2157 that fires off the tuning commands and goes right
>>> back to userland immediately, when with instrumented testing, the
>>> operation takes time to complete and lock. The operation does not happen
>>> instantaneously. Software that expects clocks to be locked when the
>>> function returns determine this is an error. They query the tuner
>>> immediately when tune returns and they output tuning failed.
>>>
>>> Please explain why awaiting the hardware to say the "tuning operation
>>> you requested is done and clocks are locked" is not ok. If it's not ok,
>>> fine, but then a lot of other drivers are currently "not ok" as well.
>> If you read the dvb userspace api, there is nothing in the DTV_TUNE
>> property that says it will block until a lock has been made.
>>
>> https://www.kernel.org/doc/html/latest/media/uapi/dvb/fe_property_parameters.html#dtv-tune
>>
>> The locking status can be queried using read status.
>>
>> https://www.kernel.org/doc/html/latest/media/uapi/dvb/fe-read-status.html#fe-read-status
>>
>> Using this mechanism, there is a minimum of sleeping in the kernel which helps
>> interactivity. (uninterruptable) sleeping in drivers something that really
>> should be avoided if at all possible. Userspace can't do anything during that
>> time.
>
> This is not dealing with signal lock. As far as I understand the
> documentation I have, this is hardware tuning completion, aka the pll's
> and whatever else are properly configured and the tuning operation
> itself is finished successfully. The byte read is looking for
> TUNINT/ATVINT/DTVINT bits set, meaning the operation is complete. Right
> now I ignore errors, which probably should be returned to userland, as
> if a tune fails the userland has no way to determine this fact. This
> process comes directly from a flowchart in the SL guide.
>
> Signal lock is determined later, using the methods you describe. No
> property registers are being queried here, the success of the previous
> (tuning) operation is.
Hi Sean,
Just noticing now that my commit message does not agree with what I'm
saying. I will need to do some testing to see which is correct. I've
been basing my statements here off the SL reference I have, but I wrote
the commit message over a year ago probably. I'll need to do some
testing, I seem to recall the timing being consistent whether a signal
is found or not. I might have mis-wrote the message long ago when I was
splitting this up.
Regards,
Brad
>
>
>> So if you look at how dvbv5-zap finds a lock, you can see that it sets
>> DTV_TUNE (amongst others) and then uses the frontend read_status() to query
>> for locking until either timeout or a lock is found (not sure why it polls
>> one per second though, seems a bit overly conservative).
>>
>> https://git.linuxtv.org/v4l-utils.git/tree/utils/dvb/dvbv5-zap.c#n494
>>
>> Now, if other drivers have a sleep to wait for tuning lock in them and whether
>> they should be removed, is another question. Looking at the tda8290 driver
>> it needs to try various things in order to make a lock, so there is (currently)
>> no way to avoid this. It would be nice if it could be changed to interruptable
>> sleeps though, so that dvb userspace does not "hang" until a lock is made
>> or failed.
>
> I indeed noticed none of the other drivers use usleep_range, which is
> interruptible, correct?
>
> Regards,
>
> Brad
>
>
>>
>> Thanks,
>>
>> Sean
^ permalink raw reply
* [PATCH] board: amlogic-q200: fix Khadas VIM2 README
From: Neil Armstrong @ 2019-04-10 14:47 UTC (permalink / raw)
To: u-boot; +Cc: Neil Armstrong, u-boot-amlogic, baylibre-upstreaming
The vendor U-boot branch and defconfig was wrong for the
Khadas VIM2, fix this.
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
board/amlogic/q200/README.khadas-vim2 | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/board/amlogic/q200/README.khadas-vim2 b/board/amlogic/q200/README.khadas-vim2
index 578693fd2d..8bcfc296f3 100644
--- a/board/amlogic/q200/README.khadas-vim2
+++ b/board/amlogic/q200/README.khadas-vim2
@@ -48,9 +48,9 @@ the git tree published by the board vendor:
> tar xvfJ gcc-linaro-aarch64-none-elf-4.8-2013.11_linux.tar.xz
> tar xvfJ gcc-linaro-arm-none-eabi-4.8-2013.11_linux.tar.xz
> export PATH=$PWD/gcc-linaro-aarch64-none-elf-4.8-2013.11_linux/bin:$PWD/gcc-linaro-arm-none-eabi-4.8-2013.11_linux/bin:$PATH
- > git clone https://github.com/khadas/u-boot -b Vim vim-u-boot
+ > git clone https://github.com/khadas/u-boot -b khadas-vim-v2015.01 vim-u-boot
> cd vim-u-boot
- > make kvim_defconfig
+ > make kvim2_defconfig
> make
> export FIPDIR=$PWD/fip
--
2.21.0
^ permalink raw reply related
* [U-Boot] [PATCH] board: amlogic-q200: fix Khadas VIM2 README
From: Neil Armstrong @ 2019-04-10 14:47 UTC (permalink / raw)
To: u-boot
The vendor U-boot branch and defconfig was wrong for the
Khadas VIM2, fix this.
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
board/amlogic/q200/README.khadas-vim2 | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/board/amlogic/q200/README.khadas-vim2 b/board/amlogic/q200/README.khadas-vim2
index 578693fd2d..8bcfc296f3 100644
--- a/board/amlogic/q200/README.khadas-vim2
+++ b/board/amlogic/q200/README.khadas-vim2
@@ -48,9 +48,9 @@ the git tree published by the board vendor:
> tar xvfJ gcc-linaro-aarch64-none-elf-4.8-2013.11_linux.tar.xz
> tar xvfJ gcc-linaro-arm-none-eabi-4.8-2013.11_linux.tar.xz
> export PATH=$PWD/gcc-linaro-aarch64-none-elf-4.8-2013.11_linux/bin:$PWD/gcc-linaro-arm-none-eabi-4.8-2013.11_linux/bin:$PATH
- > git clone https://github.com/khadas/u-boot -b Vim vim-u-boot
+ > git clone https://github.com/khadas/u-boot -b khadas-vim-v2015.01 vim-u-boot
> cd vim-u-boot
- > make kvim_defconfig
+ > make kvim2_defconfig
> make
> export FIPDIR=$PWD/fip
--
2.21.0
^ permalink raw reply related
* Re: (unknown)
From: Jan Kiszka @ 2019-04-10 14:47 UTC (permalink / raw)
To: Lange Norbert, Xenomai
In-Reply-To: <VI1PR05MB5917B5956F2E9365F10D6539F62E0@VI1PR05MB5917.eurprd05.prod.outlook.com>
[re-adding the list]
On 10.04.19 16:44, Lange Norbert wrote:
>
>
>> -----Original Message-----
>> From: Xenomai <xenomai-bounces@xenomai.org> On Behalf Of Jan Kiszka via
>> Xenomai
>> Sent: Mittwoch, 10. April 2019 16:36
>> To: Norbert Lange <nolange79@gmail.com>; xenomai@xenomai.org
>> Subject: Re: (unknown)
>>
>> E-MAIL FROM A NON-ANDRITZ SOURCE: AS A SECURITY MEASURE, PLEASE
>> EXERCISE CAUTION WITH E-MAIL CONTENT AND ANY LINKS OR ATTACHMENTS.
>>
>>
>> On 10.04.19 13:14, Norbert Lange via Xenomai wrote:
>>> V3 of the patchset, corrected many checkstyle issues, simplified
>>> condvar autoinit.
>>>
>>> I did not use ARRAY_SIZE, as that would need another include.
>>>
>>
>> All applied now. Patch 1 was not cleanly based on next, though. I think some
>> local style cleanup was missing.
>
> I based all patches on master, thought this is the primary development branch?
>
Line 566 in lib/cobalt/mutex.c had a trailing tab, your patch context did not,
and that made the application fail. Maybe that was removed while transporting
the patch into your mail client - better use git send-email in that case.
Jan
--
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux
^ permalink raw reply
* [U-Boot] [PULL] u-boot-sh/master
From: Marek Vasut @ 2019-04-10 14:47 UTC (permalink / raw)
To: u-boot
The following changes since commit 3c99166441bf3ea325af2da83cfe65430b49c066:
Prepare v2019.04 (2019-04-08 21:40:40 -0400)
are available in the Git repository at:
git://git.denx.de/u-boot-sh.git master
for you to fetch changes up to c8630bb09674e2b8496753929ac4d0a610583f1e:
ARM: rmobile: rcar-common: Zap arch_preboot_os() (2019-04-09 19:20:38
+0200)
----------------------------------------------------------------
Eugeniu Rosca (1):
ARM: rmobile: rcar-common: Zap arch_preboot_os()
Marek Vasut (23):
spl: ymodem: Terminate YModem session on error
spl: ymodem: Move GZ handling out of YModem session
lib: fdt: Split fdtdec_setup_mem_size_base()
lib: fdt: Split fdtdec_setup_memory_banksize()
ARM: renesas: Save boot parameters passed in by ATF
lib: fdt: Allow enabling both LZO and GZIP DT compression
lib: fdt: Allow LZO and GZIP DT compression in U-Boot
ARM: rmobile: Enable multi-DTB fit LZO compression
ARM: rmobile: Add dedicated R8A77965 SoC support
clk: renesas: Add R8A77965 clock tables
pinctrl: renesas: Add R8A77965 pin control tables
ARM: dts: rmobile: Import R8A77965 M3NULCB DTs
ARM: rmobile: Add R8A77965 M3NULCB support
clk: renesas: Synchronize Gen2 tables with Linux 5.0
clk: renesas: Synchronize Gen3 tables with Linux 5.0
pinctrl: renesas: Add TDSEL fixup for H2/E2 ES1.0 SoCs
pinctrl: renesas: Synchronize Gen2 tables with Linux 5.0
pinctrl: renesas: Synchronize Gen3 tables with Linux 5.0
ARM: dts: rmobile: Synchronize Gen2 DTs with Linux 5.0
ARM: dts: rmobile: Synchronize Gen3 DTs with Linux 5.0
net: sh_eth: Initialize PHY in probe() once
ARM: rmobile: alt: Increase USB power-good delay
ARM: dts: rmobile: Enable USB on E2 Alt
Makefile | 16 +-
arch/arm/dts/Makefile | 1 +
arch/arm/dts/r8a7790-lager.dts | 2 -
arch/arm/dts/r8a7790-stout.dts | 19 +-
arch/arm/dts/r8a7790.dtsi | 6 +-
arch/arm/dts/r8a7791-koelsch.dts | 2 -
arch/arm/dts/r8a7791-porter.dts | 2 -
arch/arm/dts/r8a7791.dtsi | 6 +-
arch/arm/dts/r8a7792.dtsi | 3 +-
arch/arm/dts/r8a7793-gose.dts | 16 +
arch/arm/dts/r8a7793.dtsi | 2 +-
arch/arm/dts/r8a7794-alt-u-boot.dts | 28 +
arch/arm/dts/r8a7794-silk.dts | 25 +
arch/arm/dts/r8a7794.dtsi | 3 +-
arch/arm/dts/r8a7795-h3ulcb-u-boot.dts | 13 -
arch/arm/dts/r8a7795-h3ulcb.dts | 3 +-
arch/arm/dts/r8a7795-salvator-x-u-boot.dts | 17 -
arch/arm/dts/r8a7795-salvator-x.dts | 5 +-
arch/arm/dts/r8a7795-u-boot.dtsi | 16 +-
arch/arm/dts/r8a7795.dtsi | 477 ++++++++---
arch/arm/dts/r8a7796-m3ulcb-u-boot.dts | 13 -
arch/arm/dts/r8a7796-m3ulcb.dts | 3 +-
arch/arm/dts/r8a7796-salvator-x-u-boot.dts | 17 -
arch/arm/dts/r8a7796-salvator-x.dts | 3 +-
arch/arm/dts/r8a7796-u-boot.dtsi | 16 +-
arch/arm/dts/r8a7796.dtsi | 481 +++++++++--
arch/arm/dts/r8a77965-m3nulcb-u-boot.dts | 34 +
arch/arm/dts/r8a77965-m3nulcb.dts | 33 +
arch/arm/dts/r8a77965-salvator-x-u-boot.dts | 17 -
arch/arm/dts/r8a77965-u-boot.dtsi | 16 +-
arch/arm/dts/r8a77965.dtsi | 511 ++++++++++--
arch/arm/dts/r8a77970-u-boot.dtsi | 16 +-
arch/arm/dts/r8a77970.dtsi | 333 +++++++-
arch/arm/dts/r8a77990-ebisu-u-boot.dts | 157 ----
arch/arm/dts/r8a77990-ebisu.dts | 604 +++++++++++++-
arch/arm/dts/r8a77990-u-boot.dtsi | 40 +-
arch/arm/dts/r8a77990.dtsi | 1442
+++++++++++++++++++++++++++++++-
arch/arm/dts/r8a77995-draak.dts | 382 ++++++---
arch/arm/dts/r8a77995-u-boot.dtsi | 16 +-
arch/arm/dts/r8a77995.dtsi | 131 ++-
arch/arm/dts/salvator-common.dtsi | 23 +-
arch/arm/dts/ulcb.dtsi | 83 +-
arch/arm/mach-rmobile/Kconfig.64 | 24 +
arch/arm/mach-rmobile/lowlevel_init_gen3.S | 15 +
board/renesas/rcar-common/common.c | 53 --
board/renesas/ulcb/MAINTAINERS | 1 +
board/renesas/ulcb/ulcb.c | 4 +
common/spl/spl_ymodem.c | 33 +-
configs/r8a7795_salvator-x_defconfig | 4 +-
configs/r8a7795_ulcb_defconfig | 5 +-
configs/r8a77965_salvator-x_defconfig | 3 +-
configs/r8a77965_ulcb_defconfig | 67 ++
configs/r8a7796_salvator-x_defconfig | 3 +-
configs/r8a7796_ulcb_defconfig | 5 +-
doc/README.rmobile | 1 +
drivers/clk/renesas/Kconfig | 6 +
drivers/clk/renesas/Makefile | 1 +
drivers/clk/renesas/clk-rcar-gen3.c | 4 +-
drivers/clk/renesas/r8a7790-cpg-mssr.c | 6 +-
drivers/clk/renesas/r8a7791-cpg-mssr.c | 8 +-
drivers/clk/renesas/r8a7792-cpg-mssr.c | 8 +-
drivers/clk/renesas/r8a7794-cpg-mssr.c | 8 +-
drivers/clk/renesas/r8a7795-cpg-mssr.c | 89 +-
drivers/clk/renesas/r8a7796-cpg-mssr.c | 103 ++-
drivers/clk/renesas/r8a77965-cpg-mssr.c | 355 ++++++++
drivers/clk/renesas/r8a77990-cpg-mssr.c | 37 +-
drivers/clk/renesas/r8a77995-cpg-mssr.c | 44 +-
drivers/clk/renesas/rcar-gen3-cpg.h | 34 +-
drivers/clk/renesas/renesas-cpg-mssr.h | 3 +
drivers/net/sh_eth.c | 31 +-
drivers/pinctrl/renesas/Kconfig | 10 +
drivers/pinctrl/renesas/Makefile | 1 +
drivers/pinctrl/renesas/pfc-r8a7790.c | 11 +
drivers/pinctrl/renesas/pfc-r8a7791.c | 114 +--
drivers/pinctrl/renesas/pfc-r8a7792.c | 23 +-
drivers/pinctrl/renesas/pfc-r8a7794.c | 17 +-
drivers/pinctrl/renesas/pfc-r8a7795.c | 295 +++----
drivers/pinctrl/renesas/pfc-r8a7796.c | 1102
+++++++++++++------------
drivers/pinctrl/renesas/pfc-r8a77965.c | 6350
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
drivers/pinctrl/renesas/pfc-r8a77970.c | 231 +++---
drivers/pinctrl/renesas/pfc-r8a77990.c | 1559
+++++++++++++++++++----------------
drivers/pinctrl/renesas/pfc-r8a77995.c | 382 ++++++++-
drivers/pinctrl/renesas/pfc.c | 12 +-
drivers/pinctrl/renesas/sh_pfc.h | 61 +-
dts/Kconfig | 57 ++
include/config_defaults.h | 3 -
include/configs/alt.h | 3 +-
include/dt-bindings/clock/r8a7790-cpg-mssr.h | 8 +-
include/dt-bindings/clock/r8a7791-cpg-mssr.h | 8 +-
include/dt-bindings/clock/r8a7792-cpg-mssr.h | 8 +-
include/dt-bindings/clock/r8a7793-clock.h | 12 +-
include/dt-bindings/clock/r8a7793-cpg-mssr.h | 8 +-
include/dt-bindings/clock/r8a7794-clock.h | 8 +-
include/dt-bindings/clock/r8a7794-cpg-mssr.h | 8 +-
include/dt-bindings/clock/r8a7795-cpg-mssr.h | 10 +-
include/dt-bindings/clock/r8a7796-cpg-mssr.h | 10 +-
include/dt-bindings/clock/r8a77995-cpg-mssr.h | 13 +-
include/fdtdec.h | 39 +
lib/Kconfig | 13 +
lib/fdtdec.c | 50 +-
100 files changed, 13741 insertions(+), 2673 deletions(-)
create mode 100644 arch/arm/dts/r8a77965-m3nulcb-u-boot.dts
create mode 100644 arch/arm/dts/r8a77965-m3nulcb.dts
create mode 100644 configs/r8a77965_ulcb_defconfig
create mode 100644 drivers/clk/renesas/r8a77965-cpg-mssr.c
create mode 100644 drivers/pinctrl/renesas/pfc-r8a77965.c
^ permalink raw reply
* Re: [PATCH 2/2] drm/i915/execlists: Always reset the context's RING registers
From: Chris Wilson @ 2019-04-10 14:46 UTC (permalink / raw)
To: Mika Kuoppala, intel-gfx
In-Reply-To: <871s29exf6.fsf@gaia.fi.intel.com>
Quoting Mika Kuoppala (2019-04-10 15:40:13)
> Chris Wilson <chris@chris-wilson.co.uk> writes:
> > /* Rerun the request; its payload has been neutered (if guilty). */
> > - rq->ring->head = intel_ring_wrap(rq->ring, rq->head);
> > - intel_ring_update_space(rq->ring);
> > +out_replay:
> > + ce->ring->head =
> > + rq ? intel_ring_wrap(ce->ring, rq->head) : ce->ring->tail;
>
> The ce and rq ring should be same with the rq set. I guess
> you had a reasons to keep it as ce, perhaps because it is
> the culprit.
Yes, by this point we know that rq->hw_context == ce, and so rq->ring ==
ce->ring. I decided that execlists_reset() was now all about the active
context, and the request just a hint as how far along that context we had
completed -- hence trying to using ce as the primary throughout.
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply
* RE: [PATCH RESEND 1/1] PCI: Add ATS-disable quirk for AMD Radeon R7 GPUs
From: Deucher, Alexander @ 2019-04-10 14:46 UTC (permalink / raw)
To: Bjorn Helgaas, Nikolai Kostrigin, Suthikulpanit, Suravee,
Lendacky, Thomas, Kuehling, Felix, Koenig, Christian
Cc: linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org,
jroedel@suse.de
In-Reply-To: <20190409215927.GC256045@google.com>
> -----Original Message-----
> From: Bjorn Helgaas <helgaas@kernel.org>
> Sent: Tuesday, April 9, 2019 5:59 PM
> To: Nikolai Kostrigin <nickel@altlinux.org>
> Cc: linux-pci@vger.kernel.org; linux-kernel@vger.kernel.org;
> jroedel@suse.de; Deucher, Alexander <Alexander.Deucher@amd.com>
> Subject: Re: [PATCH RESEND 1/1] PCI: Add ATS-disable quirk for AMD Radeon
> R7 GPUs
>
> [+cc Alex]
>
> This claims to be a resend, but I don't see a previous posting.
>
> There *was* discussion when the quirk was added two years ago for a
> different device. As part of that, Alex thought only that device would be
> affected and ATS was validated on other GPUs:
>
>
> https://lore.kernel.org/lkml/BN6PR12MB165278346BE8A76B1E4412AFF7EA0
> @BN6PR12MB1652.namprd12.prod.outlook.com/
>
> On Mon, Apr 08, 2019 at 01:37:25PM +0300, Nikolai Kostrigin wrote:
> > ATS is broken on this hardware (at least for Stoney Ridge based
> > laptop) and causes IOMMU stalls and system failure. Disable ATS on
> > these devices to make them usable again with IOMMU enabled Thanks to
> > Joerg Roedel <jroedel@suse.de> for help.
> >
> > https://bugzilla.kernel.org/show_bug.cgi?id=194521
> >
+ a few AMD people
Seeing this bug makes it more clear. I don't think this is a problem with the GPU. I think it's a problem with either the sbios or iommu. I think the original quirk added for stoney (0x98e4) is probably wrong as well. I suspect we need a quirk for a particular laptop or sbios versions. We validated ATS extensively with Carrizo based systems (the system in the bug report above is Carrizo based) since it is the basis of our ROCm support on APUs. We have also been involved in tons of Linux OEM preloads with both Carrizo and Stoney based APUs in combination with TOPAZ dGPUs (0x6900) and haven't seen this issue in those programs. We also have TOPAZ dGPUs used in OEM programs with Intel chipsets and haven't seen the issue. I suspect since windows does not use the IOMMU by default, the sbios settings may not be well validated on certain windows only skus. I'd rather make these DMI matches or something like that for the platform or at the very least match the SSIDs as well.
Alex
> > Signed-off-by: Nikolai Kostrigin <nickel@altlinux.org>
>
> Joerg, I'm happy to merge this if you would review or ack it. I don't know
> enough to conclude that this is the root cause. It'd be nice to have an actual
> AMD erratum. Maybe it would even have a list of affected devices so we
> could get them all at once so people wouldn't have to trip over them one by
> one.
>
> > ---
> > drivers/pci/quirks.c | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c index
> > 4700d24e5d55..abb2532e16bf 100644
> > --- a/drivers/pci/quirks.c
> > +++ b/drivers/pci/quirks.c
> > @@ -4876,6 +4876,7 @@ static void quirk_no_ats(struct pci_dev *pdev)
> >
> > /* AMD Stoney platform GPU */
> > DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_ATI, 0x98e4, quirk_no_ats);
> > +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_ATI, 0x6900,
> quirk_no_ats);
> > #endif /* CONFIG_PCI_ATS */
> >
> > /* Freescale PCIe doesn't support MSI in RC mode */
> > --
> > 2.21.0
> >
^ permalink raw reply
* [U-Boot] [PULL] u-boot-socfpga/master
From: Marek Vasut @ 2019-04-10 14:46 UTC (permalink / raw)
To: u-boot
The following changes since commit 3c99166441bf3ea325af2da83cfe65430b49c066:
Prepare v2019.04 (2019-04-08 21:40:40 -0400)
are available in the Git repository at:
git://git.denx.de/u-boot-socfpga.git master
for you to fetch changes up to ef8679b24ec6226b7198e06747ff047a16030ca4:
arm: dts: Stratix10: Add QSPI node (2019-04-09 13:11:06 +0200)
----------------------------------------------------------------
Ley Foon Tan (7):
ddr: altera: stratix10: Move SDRAM size check to SDRAM driver
ddr: altera: Stratix10: Add multi-banks DRAM size check
configs: stratix10: Change CONFIG_NR_DRAM_BANKS to 2
arm: dts: Stratix10: Modify stratix10 socdk memory node
arm: socfpga: stratix10: Add cpu_has_been_warmreset()
ddr: altera: Stratix10: Add ECC memory scrubbing
arm: dts: Stratix10: Add QSPI node
Simon Goldschmidt (9):
arm: socfpga: gen5: sync devicetrees to Linux
arm: socfpga: gen5: add reset & sdr node to SPL devicetrees
reset: socfpga: rename membase ptr to modrst_base
arm: socfpga: gen5: deassert peripheral reset by default
reset: socfpga: add reset handling for old kernels
arm: socfpga: move gen5 SDR driver to DM
mtd: rawnand: denali: add reset handling
spi: cadence_qspi: add reset handling
arm: socfpga: implement proper peripheral reset
arch/arm/Kconfig | 2 ++
arch/arm/dts/socfpga-common-u-boot.dtsi | 19
++++++++++++++++++
arch/arm/dts/socfpga.dtsi | 23
++++++++++++++++++----
arch/arm/dts/socfpga_arria5_socdk-u-boot.dtsi | 6 ++----
arch/arm/dts/socfpga_cyclone5_dbm_soc1.dts | 5 +----
arch/arm/dts/socfpga_cyclone5_de0_nano_soc-u-boot.dtsi | 6 ++----
arch/arm/dts/socfpga_cyclone5_de10_nano.dts | 5 +----
arch/arm/dts/socfpga_cyclone5_de1_soc.dts | 5 +----
arch/arm/dts/socfpga_cyclone5_is1.dts | 5 +----
arch/arm/dts/socfpga_cyclone5_socdk-u-boot.dtsi | 6 ++----
arch/arm/dts/socfpga_cyclone5_sockit-u-boot.dtsi | 6 ++----
arch/arm/dts/socfpga_cyclone5_socrates-u-boot.dtsi | 6 ++----
arch/arm/dts/socfpga_cyclone5_socrates.dts | 2 --
arch/arm/dts/socfpga_cyclone5_sr1500.dts | 5 +----
arch/arm/dts/socfpga_cyclone5_vining_fpga-u-boot.dtsi | 6 ++----
arch/arm/dts/socfpga_stratix10.dtsi | 13 ++++++++++++
arch/arm/dts/socfpga_stratix10_socdk-u-boot.dtsi | 25
+++++++++++++++++++++++
arch/arm/dts/socfpga_stratix10_socdk.dts | 39
+++++++++++++++++++++++++++++++++++-
arch/arm/mach-socfpga/include/mach/reset_manager_s10.h | 3 +++
arch/arm/mach-socfpga/include/mach/sdram_gen5.h | 4 ----
arch/arm/mach-socfpga/include/mach/sdram_s10.h | 9 +++++++++
arch/arm/mach-socfpga/misc_gen5.c | 10 ----------
arch/arm/mach-socfpga/reset_manager_s10.c | 9 +++++++++
arch/arm/mach-socfpga/spl_gen5.c | 38
++++++++++-------------------------
arch/arm/mach-socfpga/spl_s10.c | 11 -----------
configs/socfpga_stratix10_defconfig | 2 +-
drivers/ddr/altera/Kconfig | 1 +
drivers/ddr/altera/sdram_gen5.c | 143
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++--------------
drivers/ddr/altera/sdram_s10.c | 136
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++--
drivers/ddr/altera/sequencer.c | 9 ++++++++-
drivers/ddr/altera/sequencer.h | 35
+++++++++++++++++++++++++++++++++
drivers/mtd/nand/raw/denali.h | 2 ++
drivers/mtd/nand/raw/denali_dt.c | 15 ++++++++++++++
drivers/reset/reset-socfpga.c | 55
++++++++++++++++++++++++++++++++++++++++++++++-----
drivers/spi/cadence_qspi.c | 17
++++++++++++++++
drivers/spi/cadence_qspi.h | 4 ++++
include/configs/socfpga_common.h | 1 +
37 files changed, 560 insertions(+), 128 deletions(-)
create mode 100644 arch/arm/dts/socfpga-common-u-boot.dtsi
mode change 100644 => 100755 arch/arm/dts/socfpga_stratix10.dtsi
create mode 100755 arch/arm/dts/socfpga_stratix10_socdk-u-boot.dtsi
mode change 100644 => 100755 arch/arm/dts/socfpga_stratix10_socdk.dts
^ permalink raw reply
* [PATCH] board: amlogic: enable PHY_REALTEK for selected boards
From: Neil Armstrong @ 2019-04-10 14:46 UTC (permalink / raw)
To: u-boot; +Cc: Neil Armstrong, u-boot-amlogic, baylibre-upstreaming
When using the generic PHY on boards using an RGMII Realtek PHY,
gigabit speed is not always reliable.
This patch enables the Realtek PHY driver for such boards.
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
configs/khadas-vim2_defconfig | 1 +
configs/nanopi-k2_defconfig | 1 +
configs/odroid-c2_defconfig | 1 +
configs/s400_defconfig | 1 +
4 files changed, 4 insertions(+)
diff --git a/configs/khadas-vim2_defconfig b/configs/khadas-vim2_defconfig
index 080dd19590..f7fb9338e2 100644
--- a/configs/khadas-vim2_defconfig
+++ b/configs/khadas-vim2_defconfig
@@ -31,6 +31,7 @@ CONFIG_MMC_MESON_GX=y
CONFIG_MTD=y
CONFIG_DM_ETH=y
CONFIG_ETH_DESIGNWARE=y
+CONFIG_PHY_REALTEK=y
CONFIG_PHY=y
CONFIG_MESON_GXL_USB_PHY=y
CONFIG_PINCTRL=y
diff --git a/configs/nanopi-k2_defconfig b/configs/nanopi-k2_defconfig
index 8bbf48f41f..106c5c0193 100644
--- a/configs/nanopi-k2_defconfig
+++ b/configs/nanopi-k2_defconfig
@@ -28,6 +28,7 @@ CONFIG_DM_MMC=y
CONFIG_MMC_MESON_GX=y
CONFIG_DM_ETH=y
CONFIG_ETH_DESIGNWARE=y
+CONFIG_PHY_REALTEK=y
CONFIG_PINCTRL=y
CONFIG_PINCTRL_MESON_GXBB=y
CONFIG_DM_REGULATOR=y
diff --git a/configs/odroid-c2_defconfig b/configs/odroid-c2_defconfig
index 747da184b3..91baddbb60 100644
--- a/configs/odroid-c2_defconfig
+++ b/configs/odroid-c2_defconfig
@@ -29,6 +29,7 @@ CONFIG_DM_MMC=y
CONFIG_MMC_MESON_GX=y
CONFIG_DM_ETH=y
CONFIG_ETH_DESIGNWARE=y
+CONFIG_PHY_REALTEK=y
CONFIG_PINCTRL=y
CONFIG_PINCTRL_MESON_GXBB=y
CONFIG_DM_REGULATOR=y
diff --git a/configs/s400_defconfig b/configs/s400_defconfig
index 1bd4b7127b..9b8448e003 100644
--- a/configs/s400_defconfig
+++ b/configs/s400_defconfig
@@ -26,6 +26,7 @@ CONFIG_DM_MMC=y
CONFIG_MMC_MESON_GX=y
CONFIG_DM_ETH=y
CONFIG_ETH_DESIGNWARE=y
+CONFIG_PHY_REALTEK=y
CONFIG_PINCTRL=y
CONFIG_PINCTRL_MESON_AXG=y
CONFIG_DM_REGULATOR=y
--
2.21.0
^ permalink raw reply related
* [U-Boot] [PATCH] board: amlogic: enable PHY_REALTEK for selected boards
From: Neil Armstrong @ 2019-04-10 14:46 UTC (permalink / raw)
To: u-boot
When using the generic PHY on boards using an RGMII Realtek PHY,
gigabit speed is not always reliable.
This patch enables the Realtek PHY driver for such boards.
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
configs/khadas-vim2_defconfig | 1 +
configs/nanopi-k2_defconfig | 1 +
configs/odroid-c2_defconfig | 1 +
configs/s400_defconfig | 1 +
4 files changed, 4 insertions(+)
diff --git a/configs/khadas-vim2_defconfig b/configs/khadas-vim2_defconfig
index 080dd19590..f7fb9338e2 100644
--- a/configs/khadas-vim2_defconfig
+++ b/configs/khadas-vim2_defconfig
@@ -31,6 +31,7 @@ CONFIG_MMC_MESON_GX=y
CONFIG_MTD=y
CONFIG_DM_ETH=y
CONFIG_ETH_DESIGNWARE=y
+CONFIG_PHY_REALTEK=y
CONFIG_PHY=y
CONFIG_MESON_GXL_USB_PHY=y
CONFIG_PINCTRL=y
diff --git a/configs/nanopi-k2_defconfig b/configs/nanopi-k2_defconfig
index 8bbf48f41f..106c5c0193 100644
--- a/configs/nanopi-k2_defconfig
+++ b/configs/nanopi-k2_defconfig
@@ -28,6 +28,7 @@ CONFIG_DM_MMC=y
CONFIG_MMC_MESON_GX=y
CONFIG_DM_ETH=y
CONFIG_ETH_DESIGNWARE=y
+CONFIG_PHY_REALTEK=y
CONFIG_PINCTRL=y
CONFIG_PINCTRL_MESON_GXBB=y
CONFIG_DM_REGULATOR=y
diff --git a/configs/odroid-c2_defconfig b/configs/odroid-c2_defconfig
index 747da184b3..91baddbb60 100644
--- a/configs/odroid-c2_defconfig
+++ b/configs/odroid-c2_defconfig
@@ -29,6 +29,7 @@ CONFIG_DM_MMC=y
CONFIG_MMC_MESON_GX=y
CONFIG_DM_ETH=y
CONFIG_ETH_DESIGNWARE=y
+CONFIG_PHY_REALTEK=y
CONFIG_PINCTRL=y
CONFIG_PINCTRL_MESON_GXBB=y
CONFIG_DM_REGULATOR=y
diff --git a/configs/s400_defconfig b/configs/s400_defconfig
index 1bd4b7127b..9b8448e003 100644
--- a/configs/s400_defconfig
+++ b/configs/s400_defconfig
@@ -26,6 +26,7 @@ CONFIG_DM_MMC=y
CONFIG_MMC_MESON_GX=y
CONFIG_DM_ETH=y
CONFIG_ETH_DESIGNWARE=y
+CONFIG_PHY_REALTEK=y
CONFIG_PINCTRL=y
CONFIG_PINCTRL_MESON_AXG=y
CONFIG_DM_REGULATOR=y
--
2.21.0
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.