On Tue, 2018-05-22 at 13:55 +0200, Hans Verkuil wrote:
> On 21/05/18 18:59, Ezequiel Garcia wrote:
> > From: Gustavo Padovan
> >
> > Now that we've introduced the V4L2_FMT_FLAG_UNORDERED flag,
> > mark the appropriate formats.
> >
> > v2: Set unord
On Tue, 2018-05-22 at 18:48 +0200, Hans Verkuil wrote:
> On 22/05/18 18:22, Ezequiel Garcia wrote:
> > > > @@ -1615,7 +1762,12 @@ static void __vb2_dqbuf(struct vb2_buffer *vb)
> > > > return;
> > > >
> > &
On Tue, 2018-05-22 at 14:37 +0200, Hans Verkuil wrote:
> On 21/05/18 18:59, Ezequiel Garcia wrote:
> > From: Gustavo Padovan
> >
> > Receive in-fence from userspace and add support for waiting on them
> > before queueing the buffer to the driver. Buffers can't be
On Tue, 2018-05-22 at 14:05 +0200, Hans Verkuil wrote:
> On 21/05/18 18:59, Ezequiel Garcia wrote:
> > From: Gustavo Padovan
> >
> > Turn the reserved2 field into fence_fd that we will use to send
> > an in-fence to the kernel or return an out-fence from the kernel to
From: Gustavo Padovan
Instead of putting V4L2_CAP_STREAMING and V4L2_CAP_READWRITE
everywhere, set device_caps earlier with these values.
Signed-off-by: Gustavo Padovan
---
drivers/media/usb/hackrf/hackrf.c | 11 ---
1 file changed, 4 insertions(+), 7 deletions(-)
diff --git a/drivers
From: Gustavo Padovan
Instead of putting V4L2_CAP_STREAMING everywhere, set device_caps
earlier with this value.
v2: move cap->capabilities assignment down (Hans Verkuil)
Signed-off-by: Gustavo Padovan
---
drivers/media/platform/omap3isp/ispvideo.c | 10 ++
1 file changed, 6 insertion
From: Gustavo Padovan
Explicit synchronization benefits a lot from ordered queues, they fit
better in a pipeline with DRM for example so create a opt-in way for
drivers notify videobuf2 that the queue is unordered.
Drivers don't need implement it if the queue is ordered.
v5: rename it to vb2_op
From: Gustavo Padovan
Turn the reserved2 field into fence_fd that we will use to send
an in-fence to the kernel or return an out-fence from the kernel to
userspace.
Two new flags were added, V4L2_BUF_FLAG_IN_FENCE, that should be used
when sending an in-fence to the kernel to be waited on, and
V
)
Signed-off-by: Gustavo Padovan
Signed-off-by: Ezequiel Garcia
---
drivers/media/platform/coda/coda-common.c | 1 +
drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c | 1 +
drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.c | 1 +
drivers/media/platform/qcom/venus/vdec.c | 1
- call fd_install() after vb2_core_qbuf() (Hans)
- clean up fence if vb2_core_qbuf() fails (Hans)
- add list to store sync_file and fence for the next queued buffer
v2: check if the queue is ordered.
Signed-off-by: Gustavo Padovan
Signed-off-by: Ezequiel Garcia
---
drivers/media/comm
gned-off-by: Gustavo Padovan
Signed-off-by: Ezequiel Garcia
---
drivers/media/platform/exynos-gsc/gsc-m2m.c| 3 ++-
drivers/media/platform/m2m-deinterlace.c | 3 ++-
drivers/media/platform/mtk-mdp/mtk_mdp_m2m.c | 3 ++-
.../media/platform/mtk-vcodec/mtk_vcodec_dec_dr
IN_FENCE is not set (Hans)
v2: - mention that fences are files (Hans)
- rework for the new API
Signed-off-by: Gustavo Padovan
Signed-off-by: Ezequiel Garcia
---
Documentation/media/uapi/v4l/vidioc-qbuf.rst | 53 +++-
Documentation/media/uapi/v4l/vidioc-querybuf.rst | 12
From: Gustavo Padovan
Drivers capable of using fences (vb2 drivers) should report the
V4L2_CAP_FENCES to userspace, so add this flag to the uapi.
v2: minor doc/english fix (Hans Verkuil)
Signed-off-by: Gustavo Padovan
---
Documentation/media/uapi/v4l/vidioc-querycap.rst | 3 +++
include/uapi/
first ready buffer
- handle queue cancel
Signed-off-by: Gustavo Padovan
Signed-off-by: Ezequiel Garcia
---
drivers/media/common/videobuf2/Kconfig | 1 +
drivers/media/common/videobuf2/videobuf2-core.c | 224
drivers/media/common/videobuf2/videobuf2-v4l2.c
From: Gustavo Padovan
The cobalt driver may reorder the capture buffers so we need to report
it as such.
v3: set formats as unordered
v2: use vb2_ops_set_unordered() helper
Signed-off-by: Gustavo Padovan
Signed-off-by: Ezequiel Garcia
---
drivers/media/pci/cobalt/cobalt-v4l2.c | 4
1
From: Gustavo Padovan
Now that we've introduced the V4L2_FMT_FLAG_UNORDERED flag,
mark the appropriate formats.
v2: Set unordered flag before calling the driver callback.
Signed-off-by: Gustavo Padovan
Signed-off-by: Ezequiel Garcia
---
drivers/media/v4l2-core/v4l2-ioctl.c
From: Gustavo Padovan
vb2_ops_wait_prepare() and vb2_ops_wait_finish() were in the
wrong file.
Signed-off-by: Gustavo Padovan
---
drivers/media/common/videobuf2/videobuf2-core.c | 14 ++
drivers/media/common/videobuf2/videobuf2-v4l2.c | 14 --
include/media/videobuf2-co
From: Gustavo Padovan
For explicit synchronization it important for userspace to know if the
format being used by the driver can deliver the buffers back to userspace
in the same order they were queued with QBUF.
Ordered streams fits nicely in a pipeline with DRM for example, where
ordered buffe
From: Gustavo Padovan
To better organize the code we concentrate the setting of
V4L2_CAP_STREAMING in one place.
v2: move cap->capabilities assignment down (Hans Verkuil)
Signed-off-by: Gustavo Padovan
---
drivers/media/platform/xilinx/xilinx-dma.c | 10 ++
1 file changed, 6 insertion
contexts.
Signed-off-by: Ezequiel Garcia
---
drivers/media/common/videobuf2/videobuf2-core.c | 27 ++---
include/media/videobuf2-core.h | 7 +--
2 files changed, 29 insertions(+), 5 deletions(-)
diff --git a/drivers/media/common/videobuf2/videobuf2-core.c
b
AP_FENCES check.
* Minor documentation changes.
Ezequiel Garcia (1):
videobuf2: Make struct vb2_buffer refcounted
Gustavo Padovan (15):
xilinx: regroup caps on querycap
hackrf: group device capabilities
omap3isp: group device capabilities
vb2: move vb2_ops functions to videobuf2-core.
On Wed, 2018-05-09 at 17:33 +0100, Brian Starkey wrote:
> On Wed, May 09, 2018 at 12:52:26PM -0300, Ezequiel Garcia wrote:
> > On Wed, 2018-05-09 at 11:33 +0100, Brian Starkey wrote:
> > > Hi Ezequiel,
> > >
> > > On Fri, May 04, 2018 at 05:06:07PM -0300,
On Wed, 2018-05-09 at 17:33 +0100, Brian Starkey wrote:
> On Wed, May 09, 2018 at 12:52:26PM -0300, Ezequiel Garcia wrote:
> > On Wed, 2018-05-09 at 11:33 +0100, Brian Starkey wrote:
> > > Hi Ezequiel,
> > >
> > > On Fri, May 04, 2018 at 05:06:07PM -0300,
On Wed, 2018-05-09 at 11:36 +0100, Brian Starkey wrote:
[..]
> > @@ -203,9 +215,14 @@ static void __fill_v4l2_buffer(struct vb2_buffer *vb,
> > void *pb)
> > b->timestamp = ns_to_timeval(vb->timestamp);
> > b->timecode = vbuf->timecode;
> > b->sequence = vbuf->sequence;
> > - b->fen
On Wed, 2018-05-09 at 11:33 +0100, Brian Starkey wrote:
> Hi Ezequiel,
>
> On Fri, May 04, 2018 at 05:06:07PM -0300, Ezequiel Garcia wrote:
> > From: Gustavo Padovan
> >
> > Turn the reserved2 field into fence_fd that we will use to send
> > an in-fence to the k
On Mon, 2018-05-07 at 14:07 +0200, Hans Verkuil wrote:
> On 04/05/18 22:06, Ezequiel Garcia wrote:
> > From: Gustavo Padovan
> >
> > Receive in-fence from userspace and add support for waiting on them
> > before queueing the buffer to the driver. Buffers can't be
From: Gustavo Padovan
vb2_ops_wait_prepare() and vb2_ops_wait_finish() were in the
wrong file.
Signed-off-by: Gustavo Padovan
---
drivers/media/common/videobuf2/videobuf2-core.c | 14 ++
drivers/media/common/videobuf2/videobuf2-v4l2.c | 14 --
include/media/videobuf2-co
From: Gustavo Padovan
Now that we've introduced the V4L2_FMT_FLAG_UNORDERED flag,
mark the appropriate formats.
Signed-off-by: Gustavo Padovan
---
drivers/media/v4l2-core/v4l2-ioctl.c | 55
1 file changed, 30 insertions(+), 25 deletions(-)
diff --git a/dri
From: Gustavo Padovan
To better organize the code we concentrate the setting of
V4L2_CAP_STREAMING in one place.
v2: move cap->capabilities assignment down (Hans Verkuil)
Signed-off-by: Gustavo Padovan
---
drivers/media/platform/xilinx/xilinx-dma.c | 10 ++
1 file changed, 6 insertion
From: Gustavo Padovan
Instead of putting V4L2_CAP_STREAMING and V4L2_CAP_READWRITE
everywhere, set device_caps earlier with these values.
Signed-off-by: Gustavo Padovan
---
drivers/media/usb/hackrf/hackrf.c | 11 ---
1 file changed, 4 insertions(+), 7 deletions(-)
diff --git a/drivers
From: Gustavo Padovan
The cobalt driver may reorder the capture buffers so we need to report
it as such.
v3: set unordered as a property
v2: use vb2_ops_set_unordered() helper
Signed-off-by: Gustavo Padovan
Signed-off-by: Ezequiel Garcia
---
drivers/media/pci/cobalt/cobalt-v4l2.c | 1 +
1
as unordered (Nicolas and Hans)
Signed-off-by: Gustavo Padovan
Signed-off-by: Ezequiel Garcia
---
drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c | 2 ++
drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.c | 1 +
drivers/media/platform/qcom/venus/venc.c | 2 ++
drivers/media/platform
From: Gustavo Padovan
Drivers capable of using fences (vb2 drivers) should report the
V4L2_CAP_FENCES to userspace, so add this flag to the uapi.
v2: minor doc/english fix (Hans Verkuil)
Signed-off-by: Gustavo Padovan
---
Documentation/media/uapi/v4l/vidioc-querycap.rst | 3 +++
include/uapi/
: - mention that fences are files (Hans)
- rework for the new API
Signed-off-by: Gustavo Padovan
Signed-off-by: Ezequiel Garcia
---
Documentation/media/uapi/v4l/vidioc-qbuf.rst | 54 +++-
Documentation/media/uapi/v4l/vidioc-querybuf.rst | 12 --
2 files changed, 62
From: Gustavo Padovan
Drivers that use videobuf2 are capable of using fences and
should report that to userspace.
v9: Add in the core.
Signed-off-by: Gustavo Padovan
Signed-off-by: Ezequiel Garcia
---
drivers/media/v4l2-core/v4l2-ioctl.c | 8
include/media/v4l2-fh.h
and fence for the next queued buffer
v2: check if the queue is ordered.
Signed-off-by: Gustavo Padovan
Signed-off-by: Ezequiel Garcia
---
drivers/media/common/videobuf2/videobuf2-core.c | 95 +++--
drivers/media/common/videobuf2/videobuf2-v4l2.c | 22 +-
dri
DMABUF only (Javier)
- check num of ready buffers to start streaming
- when queueing, start from the first ready buffer
- handle queue cancel
Signed-off-by: Gustavo Padovan
Signed-off-by: Ezequiel Garcia
---
drivers/media/common/videobuf2/videobuf2-core.c | 197
d
From: Gustavo Padovan
For explicit synchronization it important for userspace to know if the
format being used by the driver can deliver the buffers back to userspace
in the same order they were queued with QBUF.
Ordered streams fits nicely in a pipeline with DRM for example, where
ordered buffe
vb2_ops_is_unordered() (Hans Verkuil)
v3: - make it bool (Hans)
- create vb2_ops_set_unordered() helper
v2: improve comments for is_unordered flag (Hans Verkuil)
Signed-off-by: Gustavo Padovan
Signed-off-by: Ezequiel Garcia
---
include/media/videobuf2-core.h | 3 +++
1 file changed, 3
From: Gustavo Padovan
Turn the reserved2 field into fence_fd that we will use to send
an in-fence to the kernel or return an out-fence from the kernel to
userspace.
Two new flags were added, V4L2_BUF_FLAG_IN_FENCE, that should be used
when sending an in-fence to the kernel to be waited on, and
V
From: Gustavo Padovan
Instead of putting V4L2_CAP_STREAMING everywhere, set device_caps
earlier with this value.
v2: move cap->capabilities assignment down (Hans Verkuil)
Signed-off-by: Gustavo Padovan
---
drivers/media/platform/omap3isp/ispvideo.c | 10 ++
1 file changed, 6 insertion
Hi all,
Gustavo has asked to me to take care of the final
issues with this series.
I'm working on adding some fences tests to v4l2-compliance,
which I'll be posting shortly.
So, here's a new version of the "video4linux meet fences"
series. This new round hopefully addresses all the feedback
rece
Hi guys,
I've a couple questions.
On 9 March 2018 at 14:49, Gustavo Padovan wrote:
> From: Gustavo Padovan
>
> If V4L2_BUF_FLAG_OUT_FENCE flag is present on the QBUF call we create
> an out_fence and send its fd to userspace on the fence_fd field as a
> return arg for the QBUF call.
>
> The fen
On 14 March 2018 at 12:55, Hans Verkuil wrote:
> On 03/09/2018 09:49 AM, Gustavo Padovan wrote:
>> From: Gustavo Padovan
>>
>> Receive in-fence from userspace and add support for waiting on them
>> before queueing the buffer to the driver. Buffers can't be queued to the
>> driver before its fence
req);
> +int clk_mux_determine_rate_flags(struct clk_hw *hw,
> +struct clk_rate_request *req,
> + unsigned long flags);
> void clk_hw_reparent(struct clk_hw *hw, struct clk_hw *new_parent);
> void clk_hw_set_rate_range(struct clk_hw *hw, unsigned long min_rate,
>unsigned long max_rate);
> --
> 2.14.3
>
Reviewed-by: Ezequiel Garcia
Thanks!
--
Ezequiel García, VanguardiaSur
www.vanguardiasur.com.ar
On Mon, 2018-04-23 at 12:44 +0200, Ulf Hansson wrote:
> On 19 April 2018 at 12:40, Enric Balletbo i Serra
> wrote:
> > From: Lin Huang
> >
> > We just return -EPROBE_DEFER error code to caller and do not
> > print error message when try to get center logic regulator
> > and DMC clock defer.
> >
Hi Sebastian,
On Fri, 2018-04-20 at 19:24 +0200, Sebastian Reichel wrote:
> The current reset-gpio support triggers an interrupt storm on platforms
> using the maxtouch with level based interrupt. The Motorola Droid 4,
> which I used for some of the tests is not affected, since it uses a level
> b
<&gpio5 19 GPIO_ACTIVE_HIGH>;
> reg = <0x4b>;
> interrupt-parent = <&gpio5>;
> - interrupts = <4 0x8>;
> + interrupts = <4 IRQ_TYPE_LEVEL_LOW>;
> };
> };
>
>
Looks good to me:
R
On Thu, 2018-04-05 at 11:49 +0200, Enric Balletbo i Serra wrote:
> From: "Kristian H. Kristensen"
>
> To improve PSR exit latency, we speculatively start exiting when we
> receive input events. Occasionally, this may lead to false positives,
> but most of the time we get a head start on coming ou
Hi Andy,
Just a very minor nit.
On 8 February 2018 at 09:18, Andy Yan wrote:
[..]
> +
> +static int get_if_type(struct rockchip_sfc *sfc, enum spi_nor_protocol proto)
> +{
I understand that this got copy-pasted from some other driver,
but please change this function name to something like
rockc
On 22 December 2017 at 12:53, Miquel RAYNAL
wrote:
> Hello Chris,
>
> On Fri, 22 Dec 2017 12:19:04 +1300
> Chris Packham wrote:
>
>> From: Kalyan Kinthada
>>
>> The Armada-370 based SoCs support arbitration between the NAND Flash
>> interface and NOR (i.e. devbus) on the same chip select. Howeve
On 17 December 2017 at 16:00, Willy Tarreau wrote:
> On Sun, Dec 17, 2017 at 07:07:46PM +0100, Boris Brezillon wrote:
>> > > This would guarantee that devices with factory bad blocks,
>> > > (and no BBT), would be OK with this patch.
>> >
>> > I see. I'm fine with trying provided I have reasonably
On 17 December 2017 at 12:00, Willy Tarreau wrote:
> On Sun, Dec 17, 2017 at 03:53:05PM +0100, Boris Brezillon wrote:
>> On Sun, 17 Dec 2017 11:27:51 -0300
>> Ezequiel Garcia wrote:
>>
>> > On 17 December 2017 at 09:05, Willy Tarreau wrote:
>> > >
On 17 December 2017 at 09:05, Willy Tarreau wrote:
> Hello,
>
> I recently bought a Linksys WRT1900ACS which hosts an Armada 385 and a
> NAND flash. While I could get OpenWRT to work flawlessly on it using
> kernel 4.4, mainline 4.14.6 fails with a lot of such messages :
>
> pxa3xx-nand f10d00
On 17 December 2017 at 10:17, Willy Tarreau wrote:
> Hi Boris!
>
> On Sun, Dec 17, 2017 at 01:33:55PM +0100, Boris Brezillon wrote:
>> You should have a look at this thread [1], and in case you don't want
>> to read everything,
>
> I've read it entirely, it was very instructive!
>
>> you can just
This commit makes use of the axp209.dtsi file to define the
AXP209 PMIC. While here, define the rails that are enabled on
this board.
Tested checking the regulator voltage varies according to the
CPU frequency.
Signed-off-by: Ezequiel Garcia
---
arch/arm/boot/dts/sun7i-a20-olinuxino-micro.dts
On 2 January 2017 at 13:37, Quentin Schulz
wrote:
[...]
> +
> +#define AXP20X_PWR_STATUS_BAT_CHARGING BIT(2)
> +
> +#define AXP20X_PWR_OP_BATT_PRESENT BIT(5)
> +#define AXP20X_PWR_OP_BATT_ACTIVATED BIT(3)
> +
> +#define AXP209_FG_PERCENT GENMASK(6, 0)
> +#define AXP22X_FG_VALID
On 15 September 2016 at 12:41, Arnd Bergmann wrote:
> The newly added broadcom qspi driver in drivers/spi produces a build
> warning when CONFIG_MTD is disabled:
>
> include/linux/mtd/cfi.h:76:2: #warning No CONFIG_MTD_CFI_Ix selected. No NOR
> chip support can work. [-Werror=cpp]
>
> Since drive
he gfx driver too.
Also, do we know which CPUs are affect by this issue?
and which are NOT affected :) - would be quite relevant
in picking a CPU for a product.
[1] https://bugzilla.kernel.org/show_bug.cgi?id=109051
--
Ezequiel Garcia, VanguardiaSur
www.vanguardiasur.com.ar
Hi Amitoj,
Thanks for your patch.
On 28 May 2016 at 13:41, Amitoj Kaur Chawla wrote:
> Replace if condition and BUG() with a BUG_ON having the conditional
> expression of the if statement as argument.
>
We usually want commit messages that tell us *why* you are doing the
change: what are you fi
On 6 May 2016 at 06:03, Jacek Anaszewski wrote:
> On 04/29/2016 09:20 AM, Jacek Anaszewski wrote:
>>
>> Hi Ezequiel,
>>
>> Thanks for the update. It's indeed reasonable to have all the
>> switching infrastructure in ledtrig-panic.c.
>>
>> I've noticed two minor issues below.
>
>
> Since the merge
It's desirable to specify which LEDs are to be blinked on a kernel
panic. Therefore, introduce a devicetree boolean property to mark
which LEDs should be treated this way, if possible.
Acked-by: Rob Herring
Signed-off-by: Ezequiel Garcia
---
Documentation/devicetree/bindings/leds/commo
clear the blink_delay_{on, off} when the panic is notified.
This results in less changes.
* Changed the flag to LED_PANIC_INDICATOR, as requested by Jacek.
* Changed the firmware property name to "panic-indicator", as
requested by Jacek.
Ezequiel Garcia (3):
leds
This commit adds a new led_cdev flag LED_PANIC_INDICATOR, which
allows to mark a specific LED to be switched to the "panic"
trigger, on a kernel panic.
This is useful to allow the user to assign a regular trigger
to a given LED, and still blink that LED on a kernel panic.
Signed-off-by
Calling a GPIO LEDs is quite likely to work even if the kernel
has paniced, so they are ideal to blink in this situation.
This commit adds support for the new "panic-indicator"
firmware property, allowing to mark a given LED to blink on
a kernel panic.
Signed-off-by: Ezequ
On 26 April 2016 at 04:15, Jacek Anaszewski wrote:
> Hi Ezequiel,
>
> On 04/25/2016 06:27 PM, Ezequiel Garcia wrote:
>>
>> On 25 April 2016 at 03:56, Jacek Anaszewski
>> wrote:
>>>
>>> On 04/24/2016 11:29 AM, Pavel Machek wrote:
>>>>
On 25 April 2016 at 03:56, Jacek Anaszewski wrote:
> On 04/24/2016 11:29 AM, Pavel Machek wrote:
>>
>> On Sun 2016-04-24 11:25:51, Pavel Machek wrote:
>>>
>>> On Mon 2016-04-04 17:22:02, Ezequiel Garcia wrote:
>>>>
>>>> This commit adds a n
Hi Jacek,
On 14 April 2016 at 05:57, Jacek Anaszewski wrote:
> Hi Ezequiel,
>
> It would be good to update also leds-gpio bindings,
> of course in a separate patch:
>
> Documentation/devicetree/bindings/leds/leds-gpio.txt
>
Yes, you are right. I will send a new series adding this.
Thanks,
--
E
Calling a GPIO LEDs is quite likely to work even if the kernel
has paniced, so they are ideal to blink in this situation.
This commit adds support for the new "panic-indicator"
firmware property, allowing to mark a given LED to blink on
a kernel panic.
Signed-off-by: Ezequiel Garcia
--
This commit adds a new led_cdev flag LED_PANIC_INDICATOR, which
allows to mark a specific LED to be switched to the "panic"
trigger, on a kernel panic.
This is useful to allow the user to assign a regular trigger
to a given LED, and still blink that LED on a kernel panic.
Signed-off-by
It's desirable to specify which LEDs are to be blinked on a kernel
panic. Therefore, introduce a devicetree boolean property to mark
which LEDs should be treated this way, if possible.
Signed-off-by: Ezequiel Garcia
---
Documentation/devicetree/bindings/leds/common.txt | 3 +++
1 file ch
he flag to LED_PANIC_INDICATOR, as requested by Jacek.
* Changed the firmware property name to "panic-indicator", as
requested by Jacek.
Ezequiel Garcia (3):
leds: triggers: Allow to switch the trigger to "panic" on a kernel
panic
devicetree: leds: Introduce "panic-indica
ezillon
Acked-by: Ezequiel Garcia
Thanks,
> ---
> drivers/mtd/nand/pxa3xx_nand.c | 28 +++-
> 1 file changed, 11 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/mtd/nand/pxa3xx_nand.c b/drivers/mtd/nand/pxa3xx_nand.c
> index d650885..38d
On 6 April 2016 at 12:12, Rob Herring wrote:
> On Mon, Apr 4, 2016 at 3:22 PM, Ezequiel Garcia
> wrote:
>> It's desirable to specify which LEDs are to be blinked on a kernel
>> panic. Therefore, introduce a devicetree boolean property to mark
>> which LE
On 5 April 2016 at 18:37, Jacek Anaszewski wrote:
> Hi Ezequiel,
>
> On 04/04/2016 10:22 PM, Ezequiel Garcia wrote:
>>
>> It's desirable to specify which LEDs are to be blinked on a kernel
>> panic. Therefore, introduce a devicetree boolean property to mark
>
On 5 April 2016 at 18:36, Jacek Anaszewski wrote:
> Hi Ezequiel,
>
>
> On 04/04/2016 10:22 PM, Ezequiel Garcia wrote:
>>
>> Now that we can mark any LED (even those in use by delayed blink
>> triggers) to trigger on a kernel panic, let's introduce a nosleep
&
layed blink trigger.
This will be used by the panic LED trigger.
Signed-off-by: Ezequiel Garcia
---
drivers/leds/led-triggers.c | 26 ++
include/linux/leds.h| 4
2 files changed, 26 insertions(+), 4 deletions(-)
diff --git a/drivers/leds/led-triggers.c b/dr
This commit adds a new led_cdev flag LED_BLINK_AT_PANIC, which
allows to mark a specific LED to be switched to the "panic"
trigger, on a kernel panic.
This is useful to allow the user to assign a regular trigger
to a given LED, and still blink that LED on a kernel panic.
Signed-off-by
GPIO LEDs are relatively cheap, and so are ideal to blink on
a kernel panic. This commit adds support for the new "panic-blink"
firmware property, allowing to mark a given LED to blink on
a kernel panic.
Signed-off-by: Ezequiel Garcia
---
drivers/leds/leds-gpio.c | 4
include/li
leds-gpio driver.
Feedback and other ideas on how to implement this are most welcomed.
Ezequiel Garcia (5):
leds: triggers: Allow to switch the trigger to "panic" on a kernel
panic
leds: triggers: Add a led_trigger_event_nosleep API
leds: trigger: panic: Use led_trigger_event_
Calling led_trigger_event may schedule a delayed LED set,
if the LED was being used by a delayed blink trigger when
the kernel paniced.
Therefore, we must use led_trigger_event_nosleep to override
this situation, and set the LED unconditionally.
Signed-off-by: Ezequiel Garcia
---
drivers/leds
It's desirable to specify which LEDs are to be blinked on a kernel
panic. Therefore, introduce a devicetree boolean property to mark
which LEDs should be treated this way.
Signed-off-by: Ezequiel Garcia
---
Documentation/devicetree/bindings/leds/common.txt | 2 ++
1 file changed, 2 inser
lassdev *led_cdev);
void led_stop_software_blink(struct led_classdev *led_cdev);
void led_set_brightness_nopm(struct led_classdev *led_cdev,
--
2.7.0
--
Ezequiel Garcia, VanguardiaSur
www.vanguardiasur.com.ar
Hello,
On 13 March 2016 at 23:47, Peter Pan wrote:
> Sorry for send the v3 out late. I went through a busy time in the past
> two month.
>
> Currently nand_bbt.c is tied with struct nand_chip, and it makes other
> NAND family chips hard to use nand_bbt.c. Maybe it's the reason why
> onenand has o
On 22 Mar 01:42 AM, Vladimir Zapolskiy wrote:
> Use signed integer output in the pr_err() string format, here
> PTR_ERR() value is negative and it should be reported in human
> readable way.
>
> Signed-off-by: Vladimir Zapolskiy
Acked-by: Ezequiel Garcia
Thanks for the fi
Hi Jiancheng,
On 26 February 2016 at 05:11, Jiancheng Xue wrote:
[..]
> diff --git a/drivers/mtd/spi-nor/Kconfig b/drivers/mtd/spi-nor/Kconfig
> index 0dc9275..c86d7cf 100644
> --- a/drivers/mtd/spi-nor/Kconfig
> +++ b/drivers/mtd/spi-nor/Kconfig
> @@ -37,6 +37,12 @@ config SPI_FSL_QUADSPI
>
Hi Brian,
On 29 January 2016 at 16:25, Brian Norris wrote:
> Some flash support a bit in the status register that inverts protection
> so that it applies to the bottom of the flash, not the top. This yields
> additions to the protection range table, as noted in the comments.
>
> Because this feat
w flag for it.
>
> Signed-off-by: Brian Norris
> Reviewed-by: Ezequiel Garcia
> ---
> v2: no change
>
> drivers/mtd/spi-nor/spi-nor.c | 7 +--
> 1 file changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-n
On 27 February 2016 at 07:45, Robert Jarzmik wrote:
> Ezequiel Garcia writes:
>
>> On 12 February 2016 at 19:29, Robert Jarzmik wrote:
>>> When the driver is initialized in a pure device-tree platform, the
>>> driver's probe fails allocating the dma chann
> Appending badly-written shell test script. Requires latest mtd-utils
> (flash_lock / flash_unlock).
>
Thanks for the cool script. I've tested it on Armada XP GP board,
which has a n25q128a13 flash. Tests passed, the results are
attached.
Tested-by: Ezequiel Garcia
--
Ezequiel Ga
On 12 February 2016 at 19:29, Robert Jarzmik wrote:
> When the driver is initialized in a pure device-tree platform, the
> driver's probe fails allocating the dma channel :
> [ 525.624435] pxa3xx-nand 4310.nand: no resource defined for data DMA
> [ 525.632088] pxa3xx-nand 4310.nand: allo
On 4 February 2016 at 23:25, Jiancheng Xue wrote:
> Add hisilicon spi-nor flash controller driver
>
> Signed-off-by: Jiancheng Xue
> Acked-by: Rob Herring
> ---
> change log
> v6:
> Based on v4.5-rc2
> Fixed issues pointed by Ezequiel Garcia.
> v5:
> Fixed a
and_writel(0x820, 0x0048)
[ 99.910037] pxa3xx-nand f10d.nand: pxa3xx_nand_irq():793
nand_readl(0x0014): 0x2
Maybe it would look clearer with:
[ 99.910037] pxa3xx-nand f10d.nand: pxa3xx_nand_irq():793
nand_readl(0x0014) = 0x2
But if you feel it's just bikeshedding then:
Acked-by: Ezequiel Garcia
--
Ezequiel Garcia, VanguardiaSur
www.vanguardiasur.com.ar
fail;
> +
> + i++;
> + host->num_chip++;
> + if (i == HIFMC_MAX_CHIP_NUM)
Maybe a warning here to let the user know about this?
> + break;
> + }
> +
> + return 0;
> +
> +fail:
> + for (i = 0; i < host->num_chip; i++)
> + mtd_device_unregister(&host->nor[i].mtd);
> +
> + clk_disable_unprepare(host->clk);
> + mutex_destroy(&host->lock);
> +
> + return ret;
> +}
> +
> +static int hisi_spi_nor_remove(struct platform_device *pdev)
> +{
> + struct hifmc_host *host = platform_get_drvdata(pdev);
> + int i;
> +
> + for (i = 0; i < host->num_chip; i++)
> + mtd_device_unregister(&host->nor[i].mtd);
> +
> + clk_disable_unprepare(host->clk);
> + mutex_destroy(&host->lock);
> +
> + return 0;
> +}
> +
> +static const struct of_device_id hisi_spi_nor_dt_ids[] = {
> + { .compatible = "hisilicon,hisi-sfc"},
This one is fine.
> + { .compatible = "hisilicon,hi3519-sfc"},
This makes no sense. The idea about this generic and specific
compatible strings is to leave the door open for future quirks
or different implementations for slightly different hardware.
So, you currently will use a devicetree like this:
flash@addr {
compatible = "hisilicon,hi3519-sfc", "hisilicon,hisi-sfc";
};
And the driver currently need only match "hisilicon,hisi-sfc",
since you it doesn't currently distinguish between specific SoCs.
In the future, let's imagine that you find an errata in some hypothetical
SoC hi3520. In that case, you can add a new compatible to your binding
so your devicetree will look like:
flash@addr {
compatible = "hisilicon,hi3520-sfc", "hisilicon,hisi-sfc";
};
And the driver will somehow distinguish betwen the two compatibles
and apply a quirk on the new one.
Does it make sense?
> + { /* sentinel */ }
> +};
> +MODULE_DEVICE_TABLE(of, hisi_spi_nor_dt_ids);
> +
> +static struct platform_driver hisi_spi_nor_driver = {
> + .driver = {
> + .name = "hisi-sfc",
> + .of_match_table = hisi_spi_nor_dt_ids,
> + },
> + .probe = hisi_spi_nor_probe,
> + .remove = hisi_spi_nor_remove,
> +};
> +module_platform_driver(hisi_spi_nor_driver);
> +
> +MODULE_LICENSE("GPL");
> +MODULE_DESCRIPTION("HiSilicon SPI Nor Flash Controller Driver");
> --
> 1.9.1
>
--
Ezequiel Garcia, VanguardiaSur
www.vanguardiasur.com.ar
On 28 January 2016 at 16:48, Brian Norris wrote:
> On Thu, Jan 28, 2016 at 04:24:50PM -0300, Ezequiel Garcia wrote:
>> On 28 January 2016 at 14:59, Brian Norris
>> wrote:
>> > So, maybe we want to clear SR_SRWD only when we unlock the *entire*
>> > flash? Wha
On 28 January 2016 at 14:59, Brian Norris wrote:
> Hi Ezequiel,
>
> Thanks for the review.
>
> On Thu, Jan 28, 2016 at 11:36:13AM -0300, Ezequiel Garcia wrote:
>> On 28 January 2016 at 02:51, Brian Norris
>> wrote:
>> > Locking the flash is most useful i
ready locked/unlocked
> region
> mtd: spi-nor: disallow further writes to SR if WP# is low
> mtd: spi-nor: use BIT() for flash_info flags
> mtd: spi-nor: add SPI_NOR_HAS_LOCK flag
> mtd: spi-nor: add TB (Top/Bottom) protect support
> mtd: spi-nor: support lock/unlo
On 28 January 2016 at 02:51, Brian Norris wrote:
> Locking the flash is most useful if it provides real hardware security.
> Otherwise, it's little more than a software permission bit.
>
> A reasonable use case that provides real HW security might be like
> follows:
>
> (1) hardware WP# is deasser
On 29 December 2015 at 06:35, Boris Brezillon
wrote:
> Hi,
>
> On Mon, 28 Dec 2015 17:42:50 -0300
> Ezequiel Garcia wrote:
>
>> This is looking a lot better, thanks for the good work!
>>
>> On 15 December 2015 at 02:59, Peter Pan wrote:
>> > Currentl
This is looking a lot better, thanks for the good work!
On 15 December 2015 at 02:59, Peter Pan wrote:
> Currently nand_bbt.c is tied with struct nand_chip, and it makes other
> NAND family chips hard to use nand_bbt.c. Maybe it's the reason why
> onenand has own bbt(onenand_bbt.c).
>
> Separate
601 - 700 of 1235 matches
Mail list logo
