On Tue, Jun 10, 2025 at 10:39:31PM +0300, Andy Shevchenko wrote:
> On Fri, Apr 25, 2025 at 08:07:32PM +0300, Laurent Pinchart wrote:
> > On Fri, Apr 25, 2025 at 06:30:10PM +0300, Dan Carpenter wrote:
> > > Whatever happened with this thread from Feb.
> > >
gt; 'dev->of_node' was not incremented
> drivers/regulator/tps6594-regulator.c:618 tps6594_regulator_probe() warn:
> 'tps->dev->of_node' was not incremented
--
Regards,
Laurent Pinchart
On Tue, Feb 11, 2025 at 07:26:18PM +0800, zhangzekun (A) wrote:
> 在 2025/2/10 18:03, Laurent Pinchart 写道:
> > On Mon, Feb 10, 2025 at 02:47:28PM +0800, zhangzekun (A) wrote:
> >>> I think we all agree that of_find_node_by_name() is miused, and that it
> >>> sho
eeded to improve
things :-) In most cases, as DT bindings are available, it shouldn't be
very difficult.
> >
> > - If there are other callers that need to find indirect children,
> >introduce a new of_get_child_by_name_recursive() function.
> >
> > At that point, the only remaining caller of of_find_node_by_name()
> > (beside its usage in the for_each_node_by_name() macro) will be
> > drivers/clk/ti/clk.c, which uses the function correctly.
> >
> > I'm tempted to then rename of_find_node_by_name() to
> > __of_find_node_by_name() to indicate it's an internal function not meant
> > to be called except in special cases. It could all be renamed to
> > __of_find_next_node_by_name() to make its behaviour clearer.
> >
>
> The actual code logic of of_find_node_by_name() is more suitable to be
> used in a loop.So,rename of_find_node_by_name() to
> __of_find_next_node_by_name() seems to be a good idea.
--
Regards,
Laurent Pinchart
t fix here is to
- Replace of_find_node_by_name(root, ...) with
of_find_node_by_name(NULL, ...) in arch/powerpc/platforms/chrp/pci.c
(if my understanding of the code is correct).
- Replace of_find_node_by_name() with of_get_child_by_name() in callers
that need to search immediate children only (I expected that to be the
majority of the above call sites).
- If there are other callers that need to find indirect children,
introduce a new of_get_child_by_name_recursive() function.
At that point, the only remaining caller of of_find_node_by_name()
(beside its usage in the for_each_node_by_name() macro) will be
drivers/clk/ti/clk.c, which uses the function correctly.
I'm tempted to then rename of_find_node_by_name() to
__of_find_node_by_name() to indicate it's an internal function not meant
to be called except in special cases. It could all be renamed to
__of_find_next_node_by_name() to make its behaviour clearer.
--
Regards,
Laurent Pinchart
a named node. I haven't checked all
patches, but other ones seem to suffer from the same misuse.
Assuming that the named node those drivers are looking for is a direct
child of the node passed as argument to of_find_node_by_name(), the
right fix would tbe to use of_get_child_by_name(). If it's not a direct
child, a recursive version of of_get_child_by_name() could be useful.
--
Regards,
Laurent Pinchart
served[32];
> + __u32fraction_bits;
Thinking forward, what if the control uses a different type of
quantization, for instance if the control is exponential instead of
linear ? Is this something we want to plan for already (without
necessarily implementing it yet) ? For instance, the CCS spec defines a
linear gain model where the gain is expressed as
gain = (m0 * x + c0) / (m1 * x + c1)
where x is the control value, gain is the real gain, and m0, c0, m1 and
c1 are device-specific 16-bit integer constants (with the constraint
that one of m0 and m1 has to be zero, but not both).
There's also an exponential model in CCS, with
gain = linear_gain * 2 ^ exponential_gain
where linear_gain and exponential_gain are U8.8 values.
> + __u32reserved[31];
> };
>
> +static inline __s64 v4l2_fp_compose(__s64 i, __s64 f, unsigned int
> fraction_bits)
> +{
> + return (i << fraction_bits) + f;
> +}
> +
> +static inline __s64 v4l2_fp_integer(__s64 v, unsigned int fraction_bits)
> +{
> + return v / (1LL << fraction_bits);
> +}
> +
> +static inline __s64 v4l2_fp_fraction(__s64 v, unsigned int fraction_bits)
> +{
> + __u64 mask = (1ULL << fraction_bits) - 1;
> +
> + return v < 0 ? -((-v) & mask) : (v & mask);
> +}
I woudln't add static inline functions to the UAPI. They cause licensing
issues, and increase the UAPI surface, thus making UAPI evolutions more
difficult.
> +
> /* Used in the VIDIOC_QUERYMENU ioctl for querying menu items */
> struct v4l2_querymenu {
> __u32 id;
--
Regards,
Laurent Pinchart
Hi Tomasz,
On Thu, Nov 16, 2023 at 04:31:41PM +0900, Tomasz Figa wrote:
> On Wed, Nov 15, 2023 at 8:49 PM Laurent Pinchart wrote:
> > On Wed, Nov 15, 2023 at 12:19:31PM +0100, Hans Verkuil wrote:
> > > On 11/15/23 11:55, Laurent Pinchart wrote:
> > > > On Wed, No
Hi Hans,
On Wed, Nov 15, 2023 at 12:19:31PM +0100, Hans Verkuil wrote:
> On 11/15/23 11:55, Laurent Pinchart wrote:
> > On Wed, Nov 15, 2023 at 09:09:42AM +0100, Hans Verkuil wrote:
> >> On 13/11/2023 13:44, Laurent Pinchart wrote:
> >>> On Mon, Nov 13, 2023 at
Hi Hans,
On Wed, Nov 15, 2023 at 09:09:42AM +0100, Hans Verkuil wrote:
> On 13/11/2023 13:44, Laurent Pinchart wrote:
> > On Mon, Nov 13, 2023 at 01:05:12PM +0100, Hans Verkuil wrote:
> >> On 13/11/2023 12:43, Laurent Pinchart wrote:
> >>> On Mon, Nov 13, 2023 at
Hi Hans,
On Mon, Nov 13, 2023 at 01:05:12PM +0100, Hans Verkuil wrote:
> On 13/11/2023 12:43, Laurent Pinchart wrote:
> > On Mon, Nov 13, 2023 at 11:28:51AM +, Sakari Ailus wrote:
> >> On Mon, Nov 13, 2023 at 12:24:14PM +0100, Hans Verkuil wrote:
> >>> On 13/1
On Mon, Nov 13, 2023 at 11:28:51AM +, Sakari Ailus wrote:
> Hi Hans,
>
> On Mon, Nov 13, 2023 at 12:24:14PM +0100, Hans Verkuil wrote:
> > On 13/11/2023 12:07, Laurent Pinchart wrote:
> > > On Mon, Nov 13, 2023 at 11:56:49AM +0100, Hans Verkuil wrote:
> > &
On Mon, Nov 13, 2023 at 11:56:49AM +0100, Hans Verkuil wrote:
> On 13/11/2023 11:42, Laurent Pinchart wrote:
> > On Mon, Nov 13, 2023 at 11:29:09AM +0100, Hans Verkuil wrote:
> >> Hi Shengjiu,
> >>
> >> On 10/11/2023 06:48, Shengjiu Wang wrote:
> >>&
> * the u64 divide that needs special care.
> > @@ -1779,6 +1780,7 @@ static struct v4l2_ctrl *v4l2_ctrl_new(struct
> > v4l2_ctrl_handler *hdl,
> > /* Prefill elem_size for all types handled by std_type_ops */
> > switch ((u32)type) {
> > case V4L2_CTRL_TYPE_INTEGER64:
> > + case V4L2_CTRL_TYPE_FIXED_POINT:
> > elem_size = sizeof(s64);
> > break;
> > case V4L2_CTRL_TYPE_STRING:
> > diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
> > index cf8c44595a1d..9482ac66a675 100644
> > --- a/include/uapi/linux/videodev2.h
> > +++ b/include/uapi/linux/videodev2.h
> > @@ -1903,6 +1903,7 @@ enum v4l2_ctrl_type {
> > V4L2_CTRL_TYPE_STRING= 7,
> > V4L2_CTRL_TYPE_BITMASK = 8,
> > V4L2_CTRL_TYPE_INTEGER_MENU = 9,
> > + V4L2_CTRL_TYPE_FIXED_POINT = 10,
> >
> > /* Compound types are >= 0x0100 */
> > V4L2_CTRL_COMPOUND_TYPES = 0x0100,
--
Regards,
Laurent Pinchart
Hi Enrico,
On Wed, Dec 09, 2020 at 12:11:36PM +0100, Enrico Weigelt, metux IT consult
wrote:
> On 08.12.20 16:54, Laurent Pinchart wrote:
> >> diff --git a/drivers/usb/gadget/udc/atmel_usba_udc.c
> >> b/drivers/usb/gadget/udc/atmel_usba_udc.c
> >> index 2b8
_HS_LPM_INT\n");
> }
>
> if (int_grp1 & FUSB300_IGR1_DEV_MODE_CHG_INT) {
> @@ -1195,11 +1195,11 @@ static irqreturn_t fusb300_irq(int irq, void
> *_fusb300)
>
> if (int_grp1 & FUSB300_IGR1_CX_COMFAIL_INT) {
> fusb300_se
#ifdef CONFIG_ARM_DMA_USE_IOMMU
> > > #include
> > > #endif
> >
> > Why does this file need at all?
> > It doesn't call any of the flush_*() functions, and seems to compile fine
> > without (on arm32).
> >
> > Perhaps it was included at the top intentionally, to override the
> > definitions
> > of copy_{to,from}_user_page()? Fortunately that doesn't seem to be the
> > case, from a quick look at the assembler output.
> >
> > So let's just remove the #include instead?
>
> Sounds good to me. I can send a patch if needed or I suppose Andrew can
> just make a small fixup patch for it. Let me know what I should do.
--
Regards,
Laurent Pinchart
(32);
> bypasses the architectures check on the DMA mask. It can be replaced
> with dma_coerce_mask_and_coherent(), avoiding the direct initialization
> of this mask.
>
> Signed-off-by: Russell King
Acked-by: Laurent Pinchart
> ---
> drivers/media/platform/omap3isp/isp.c
Hi Felipe,
On Monday 22 October 2012 13:56:01 Felipe Balbi wrote:
> On Mon, Oct 22, 2012 at 12:47:21PM +0200, Laurent Pinchart wrote:
> > On Monday 22 October 2012 03:33:19 Li Yang-R58472 wrote:
> > > On Saturday, October 20, 2012 1:37 AM Felipe Balbi wrote:
> > > >
Hi Simon,
On Monday 22 October 2012 12:49:51 Simon Haggett wrote:
> On 22/10/12 11:47, Laurent Pinchart wrote:
> > On Monday 22 October 2012 03:33:19 Li Yang-R58472 wrote:
> >> On Saturday, October 20, 2012 1:37 AM Felipe Balbi wrote:
> >>> On Fri, Oct 19, 2012 at 0
index 6ae70cb..acd513b 100644
> > > --- a/drivers/usb/gadget/fsl_udc_core.c
> > > +++ b/drivers/usb/gadget/fsl_udc_core.c
> > > @@ -955,7 +955,10 @@ static int fsl_ep_dequeue(struct usb_ep *_ep,
> > struct usb_request *_req)
> >
> > > int ep_num, stopped, r
Hi Jean-Michel,
On Friday 13 March 2009 15:20:24 Jean-Michel Hautbois wrote:
> 2009/3/13 Laurent Pinchart :
> > Support for the modem control lines has been added in v2.6.27-rc2. You
> > will need to declare the modem control lines in your device tree. See
> > Documentation
ow control is not supported by the CPM UART driver
yet.
Best regards,
--
Laurent Pinchart
CSE Semaphore Belgium
Waterloo Office Park
Building M
Dreve Richelle, 161
B-1410 Waterloo
Belgium
T +32 (2) 387 42 59
F +32 (2) 387 42 75
signature.asc
Description: This is a digitally signed mess
oes not like fast PIO transfers */
> #define SDHCI_QUIRK_PIO_NEEDS_DELAY (1<<20)
> +/* Controller losing signal/interrupt enable states after reset */
> +#define SDHCI_QUIRK_RESTORE_IRQS_AFTER_RESET (1<<21)
>
> int irq;
selected the closest-matching
> Kernel config option 'LXT970'.
>
> The primary ethernet uses FCC2.
Make sure FS_ENET_HAS_FCC is set in your kernel configuration.
[snip]
> The fs_enet probe() function doesn't seem to get called (I had put a
> panic() in it). Should i
On Thursday 15 January 2009 19:57:44 Kumar Gala wrote:
> On Jan 15, 2009, at 11:54 AM, Scott Wood wrote:
> > On Thu, Jan 15, 2009 at 03:58:50PM +0100, Laurent Pinchart wrote:
> >> On Thursday 15 January 2009 15:42:14 Kumar Gala wrote:
> >>> On Jan 15, 2009, at 7
On Thursday 15 January 2009 15:42:14 Kumar Gala wrote:
> On Jan 15, 2009, at 7:18 AM, Laurent Pinchart wrote:
> >
> > 2.6.29-rc1 is out and I haven't seen the patch being applied
> > anywhere. Is there any blocking issue ?
>
> I wasn't sure if you and Scott h
Hi Kumar,
On Thursday 20 November 2008 17:00:54 Kumar Gala wrote:
> On Nov 20, 2008, at 9:57 AM, Laurent Pinchart wrote:
> > On Thursday 20 November 2008 16:32:21 Kumar Gala wrote:
> >> On Nov 20, 2008, at 6:32 AM, Laurent Pinchart wrote:
> >>> Instead of rounding
e for specific applications.
>
> Do you remember the throughput you were able to reach with this cpu
> overhead ?
I'm sorry I don't.
Best regards,
--
Laurent Pinchart
CSE Semaphore Belgium
Chaussee de Bruxelles, 732A
B-1410 Waterloo
Belgium
T +32 (2) 387 42 59
F +32 (2) 387 42
Hi Mike,
On Tuesday 02 December 2008 00:28:23 Mike Ditto wrote:
> Laurent Pinchart <[EMAIL PROTECTED]> wrote:
> > Transmission timeout after one second. The first TX buffer descriptor
> > status hasn't been modified by the CPM. The CPM state dump shows that
> >
Hi Joakim,
On Tuesday 02 December 2008 09:39:59 Joakim Tjernlund wrote:
> On Mon, 2008-12-01 at 15:28 -0800, Mike Ditto wrote:
> > Laurent Pinchart <[EMAIL PROTECTED]> wrote:
> > > Transmission timeout after one second. The first TX buffer descriptor
> > > statu
red on the road to 2.6.27 and have
> > now resurfaced.
>
> Now == current linus.git?
Now = both 2.6.27 and 2.6.28-rc8.
Best regards,
--
Laurent Pinchart
CSE Semaphore Belgium
Chaussee de Bruxelles, 732A
B-1410 Waterloo
Belgium
T +32 (2) 387 42 59
F +32 (2) 387 42 75
__
issues come to mind, but what I've found really puzzling is that the
above log shows that the interrupt handler hasn't been called at all
(confirmed by /proc/interrupts). Why would a call to dev_dbg() in a function
that is never called modify execution timings ? This might just be a
coinci
Hi Scott,
On Thursday 20 November 2008, Scott Wood wrote:
> On Thu, Nov 20, 2008 at 01:32:23PM +0100, Laurent Pinchart wrote:
> > Instead of rounding the divider down, improve the baud-rate generators
> > accuracy by rounding to the nearest integer.
> >
> > Signed-off-b
On Thursday 20 November 2008 17:00:54 Kumar Gala wrote:
> On Nov 20, 2008, at 9:57 AM, Laurent Pinchart wrote:
> > On Thursday 20 November 2008 16:32:21 Kumar Gala wrote:
> >> On Nov 20, 2008, at 6:32 AM, Laurent Pinchart wrote:
> >>> Instead of rounding the divid
Hi Kumar,
On Thursday 20 November 2008 16:32:21 Kumar Gala wrote:
> On Nov 20, 2008, at 6:32 AM, Laurent Pinchart wrote:
> > Instead of rounding the divider down, improve the baud-rate generators
> > accuracy by rounding to the nearest integer.
> >
> > Signed-off-b
Instead of rounding the divider down, improve the baud-rate generators
accuracy by rounding to the nearest integer.
Signed-off-by: Laurent Pinchart <[EMAIL PROTECTED]>
---
arch/powerpc/sysdev/cpm2.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/
have liked to avoid that if possible.
Best regards, and thanks for your help.
--
Laurent Pinchart
CSE Semaphore Belgium
Chaussee de Bruxelles, 732A
B-1410 Waterloo
Belgium
T +32 (2) 387 42 59
F +32 (2) 387 42 75
signature.asc
Description: This is a digitally signed message part.
___
Hi Leon,
On Monday 13 October 2008, Leon Woestenberg wrote:
> Hello Laurent,
>
> On Mon, Oct 13, 2008 at 11:56 AM, Laurent Pinchart
> <[EMAIL PROTECTED]> wrote:
> > our hardware engineer asked me to make sure all unused GPIO pins are
> > configured as outputs to
Hi Geert,
On Monday 13 October 2008, Geert Uytterhoeven wrote:
> On Mon, 13 Oct 2008, Laurent Pinchart wrote:
> > our hardware engineer asked me to make sure all unused GPIO pins are
> > configured as outputs to avoid floating inputs. He got theory on his side
> > (floati
t for practical feedback.
I haven't been able to find any mention of floating input protection in the
MPC8248 documents. Has anyone here experienced issues with floating inputs in
real-life designs ? Do you setup your board with all unused GPIO pins
configured as outputs ?
Best regards,
-
On Friday 03 October 2008, Lennert Buytenhek wrote:
> On Fri, Oct 03, 2008 at 11:36:01AM +0200, Laurent Pinchart wrote:
>
> > Hi Lennert,
>
> Hi Laurent,
>
>
> > > You're listed as maintainer of one of the network drivers in the tree
> > > th
i_bus::dev to mii_bus::parent"
seems to do a lot more than just renaming mii_bus::dev to mii_bus::parent in
drivers/net/mv643xx_eth.c. You might have inadvertently committed unrelated
changes.
> drivers/net/phy/fixed.c | 29 --
> drivers/net/phy/mdio-bitbang.c
Hi Scott,
On Thursday 28 August 2008, Scott Wood wrote:
> Laurent Pinchart wrote:
> > On Thursday 28 August 2008, Scott Wood wrote:
> >> On Thu, Aug 28, 2008 at 05:57:13PM +0200, Laurent Pinchart wrote:
> >>> I'm facing a situation where I need to call cpm2_clk
On Thursday 28 August 2008, Scott Wood wrote:
> On Thu, Aug 28, 2008 at 05:57:13PM +0200, Laurent Pinchart wrote:
> > I'm facing a situation where I need to call cpm2_clk_setup and
> > cpm2_set_pin from a device driver compiled as a module. Before
> > submitting a patc
ns as floating inputs, or could that potentially damage the
MPC8248 ?
Thanks for your help.
Best regards,
--
Laurent Pinchart
CSE Semaphore Belgium
Chaussee de Bruxelles, 732A
B-1410 Waterloo
Belgium
T +32 (2) 387 42 59
F +32 (2) 387 42 75
signature.asc
Description: This is a digi
The CPM2 GPIO library code uses the non thread-safe clrbits32/setbits32
macros. This patch protects them with a spinlock.
Signed-off-by: Laurent Pinchart <[EMAIL PROTECTED]>
---
arch/powerpc/sysdev/cpm_common.c | 37 ++---
1 files changed, 26 insertions(
On Monday 18 August 2008, Anton Vorontsov wrote:
> On Mon, Aug 18, 2008 at 04:44:36PM +0200, Laurent Pinchart wrote:
> > On Monday 18 August 2008, Anton Vorontsov wrote:
> > > On Mon, Aug 18, 2008 at 03:58:46PM +0200, Laurent Pinchart wrote:
> > > [...]
> > >
On Monday 18 August 2008, Anton Vorontsov wrote:
> On Mon, Aug 18, 2008 at 03:58:46PM +0200, Laurent Pinchart wrote:
> [...]
> > > Not exactly. But you can do this way, if you need to preserve
> > > a direction. What I did is a bit different though.
> > >
>
On Thursday 14 August 2008, Anton Vorontsov wrote:
> On Thu, Aug 14, 2008 at 04:45:52PM +0200, Laurent Pinchart wrote:
> > On Thursday 14 August 2008, Anton Vorontsov wrote:
> > > On Thu, Aug 14, 2008 at 04:04:18PM +0200, Laurent Pinchart wrote:
> > > > On Friday 0
On Thursday 14 August 2008, Anton Vorontsov wrote:
> On Thu, Aug 14, 2008 at 04:04:18PM +0200, Laurent Pinchart wrote:
> > On Friday 08 August 2008, Anton Vorontsov wrote:
> > > We'll need this function to write platform-specific hooks to deal
> > > with pin's
@@ -81,6 +81,7 @@ struct gpio_chip {
> unsignedexported:1;
> };
>
> +extern struct gpio_chip *gpio_to_chip(unsigned gpio);
> extern const char *gpiochip_is_requested(struct gpio_chip *chip,
> unsigned offset);
> extern int __
function, just as
> a stopgap for a proper api?
I need gpio_to_chip() (or another 'proper API') as well for RTS/CTS based flow
control in the CPM/CPM2 UART driver.
Best regards,
--
Laurent Pinchart
CSE Semaphore Belgium
Chaussee de Bruxelles, 732A
B-1410 Waterloo
Belgium
T +32
Based on earlier work by Laurent Pinchart.
This patch implement GPIO LIB support for the CPM2 GPIOs.
Signed-off-by: Jochen Friedrich <[EMAIL PROTECTED]>
Cc: Laurent Pinchart <[EMAIL PROTECTED]>
---
arch/powerpc/platforms/Kconfig |2 +
arch/powerpc/sysdev/cpm2.c | 1
}
+ pinfo->brg = *data;
}
- pinfo->brg = *data;
data = of_get_property(np, "fsl,cpm-command", &len);
if (!data || len != 4) {
--
1.5.0
--
Laurent Pinchart
CSE Semaphore Belgium
Chaussee de Bruxelles, 732A
B-1410 Waterloo
Belg
lines can be left out.
Signed-off-by: Laurent Pinchart <[EMAIL PROTECTED]>
---
Documentation/powerpc/booting-without-of.txt | 10 ++
drivers/serial/cpm_uart/cpm_uart.h | 10 ++
drivers/serial/cpm_uart/cpm_uart_core.c | 40 --
3 files c
This patch implement GPIO LIB support for the CPM2 GPIOs. The code can also be
used for CPM1 GPIO port E, as both cores are compatible at the register level.
Based on earlier work by Jochen Friedrich.
Signed-off-by: Laurent Pinchart <[EMAIL PROTECTED]>
Cc: Jochen Friedrich <[EMAIL
On Thursday 24 July 2008, Kumar Gala wrote:
>
> On Jul 24, 2008, at 9:21 AM, Laurent Pinchart wrote:
>
> > When generating a break condition on a serial port, the CPM must be
> > told beforehand how long the break should be. Unfortunately, this
> > information i
Hi Kumar,
On Friday 18 July 2008, Kumar Gala wrote:
> On Jul 18, 2008, at 10:30 AM, Jochen Friedrich wrote:
> >> On Jun 18, 2008, at 12:08 PM, Laurent Pinchart wrote:
> >>
> >>> +#if defined(CONFIG_CPM2) || defined(CONFIG_8xx_GPIO)
> >>> +
> >
line_cr_cmd(pinfo, CPM_CR_STOP_TX);
cpm_line_cr_cmd(pinfo, CPM_CR_RESTART_TX);
+ }
}
/*
--
1.5.0
--
Laurent Pinchart
CSE Semaphore Belgium
Chaussee de Bruxelles, 732A
B-1410 Waterloo
Belgium
T +32 (2) 387 42 59
F +32 (2) 387 42 75
___
Linuxppc-dev mailing l
ntk(KERN_ERR "CPM UART %s has no/invalid "
+ "fsl,cpm-brg property.\n", np->name);
+ return -EINVAL;
+ }
+ pinfo->brg = *data;
}
- pinfo->brg = *data;
data =
nline wrappers
around __cpm2_setbrg.
Signed-off-by: Laurent Pinchart <[EMAIL PROTECTED]>
---
arch/powerpc/sysdev/cpm2.c | 34 +++
include/asm-powerpc/cpm2.h | 46 +++
2 files changed, 37 insertions(+), 43 deletions(-)
d
The mdio_port, mdio_bit, mdc_port and mdc_bit fields in the
fs_mii_bb_platform_info structure are left-overs from the move to the Phy
Abstraction Layer subsystem. They are not used anymore and can be safely
removed.
Signed-off-by: Laurent Pinchart <[EMAIL PROTECTED]>
---
include
On Friday 18 July 2008, Kumar Gala wrote:
>
> On Jul 18, 2008, at 9:38 AM, Laurent Pinchart wrote:
>
> > On Friday 27 June 2008, Jochen Friedrich wrote:
> >> Hi Laurent,
> >>
> >>> Is there any pending issue or can this be applied to powerpc-next ?
On Friday 27 June 2008, Jochen Friedrich wrote:
> Hi Laurent,
>
> > Is there any pending issue or can this be applied to powerpc-next ?
>
> Looks OK to me.
>
> >> Signed-off-by: Laurent Pinchart <[EMAIL PROTECTED]>
> >> Cc: Jochen Friedrich <
On Thursday 26 June 2008, Vitaly Bordug wrote:
> On Thu, 26 Jun 2008 13:21:23 +0200
> Laurent Pinchart <[EMAIL PROTECTED]> wrote:
>
> > > There should be no dependencies. When the OF GPIO support is not
> > > selected linux/of_gpio.h will define of_get_gpio(
Set port->fifosize to the software FIFO size, and update the port timeout
when the baud rate is modified. SCC ports have an optional 32 byte hardware
FIFO which is currently not taken into account, as there is no documented way
to check when the FIFO becomes empty.
Signed-off-by: Laurent Pinch
On Wednesday 02 July 2008, Kumar Gala wrote:
>
> On Jul 1, 2008, at 3:49 AM, Laurent Pinchart wrote:
>
> > Hi Paul,
> >
> > On Tuesday 01 July 2008, Paul Mackerras wrote:
> >> The following commits have been added to the master and powerpc-next
> >>
//patchwork.ozlabs.org/linuxppc/patch?person=968&id=17928
[PATCH] cpm_uart: Support uart_wait_until_sent()
http://patchwork.ozlabs.org/linuxppc/patch?person=968&id=19233
--
Laurent Pinchart
CSE Semaphore Belgium
Chaussee de Bruxelles, 732A
B-1410 Waterloo
Belgium
T +32 (2)
zlabs.org/linuxppc/patch?person=968&id=17928
[PATCH] cpm_uart: Support uart_wait_until_sent()
http://patchwork.ozlabs.org/linuxppc/patch?person=968&id=19233
Best regards,
--
Laurent Pinchart
CSE Semaphore Belgium
Chaussee de Bruxelles, 732A
B-1410 Waterloo
Belgium
Set port->fifosize to the software FIFO size, and update the port timeout
when the baud rate is modified. SCC ports have an optional 32 byte hardware
FIFO which is currently not taken into account, as there is no documented way
to check when the FIFO becomes empty.
Signed-off-by: Laurent Pinch
;
cpm_line_cr_cmd(pinfo, CPM_CR_STOP_TX);
+ }
else
+ {
+ *brkcr = 0;
+ cpm_line_cr_cmd(pinfo, CPM_CR_STOP_TX);
cpm_line_cr_cmd(pinfo, CPM_CR_RESTART_TX);
+ }
}
/*
--
1.5.0
--
Laurent Pinchart
CSE Semaphore Belgi
Jeff, Scott,
On Wednesday 18 June 2008 17:16, Laurent Pinchart wrote:
> On Wednesday 18 June 2008 17:00, Jeff Garzik wrote:
> > Laurent Pinchart wrote:
> > > Hi Scott,
> > >
> > > On Monday 16 June 2008 18:34, Scott Wood wrote:
> > >> On Mon, Ju
On Monday 26 May 2008 11:58, Laurent Pinchart wrote:
> On Wednesday 16 April 2008 11:10, Laurent Pinchart wrote:
> > This patch replaces the get_mctrl/set_mctrl stubs with modem control line
> > read/write access through the GPIO lib.
> >
> > Available modem control
On Wednesday 18 June 2008 19:08, Laurent Pinchart wrote:
> Based on earlier work by Jochen Friedrich.
>
> This patch implement GPIO LIB support for the CPM2 GPIOs.
Is there any pending issue or can this be applied to powerpc-next ?
> Signed-off-by: Laurent Pinchart <[EMAIL P
The restart() function is called when the link state changes and resets
multicast and promiscuous settings. This patch restores those settings at the
end of restart().
Signed-off-by: Laurent Pinchart <[EMAIL PROTECTED]>
---
drivers/net/fs_enet/mac-fcc.c |3 +++
1 files changed, 3 inse
l make a difference, but you're right, restoring the
multicast and promiscuous settings is better done before turning the receiver
and transmitter on.
I'll send a new patch.
--
Laurent Pinchart
CSE Semaphore Belgium
Chaussee de Bruxelles, 732A
B-1410 Waterloo
Belgium
T +32 (2) 387 42
On Friday 20 June 2008 05:01, Bill Fink wrote:
> On Wed, 18 Jun 2008, Laurent Pinchart wrote:
>
> > The restart() function is called when the link state changes and resets
> > multicast and promiscous settings. This patch restores those settings at
the
> > end of restar
Based on earlier work by Jochen Friedrich.
This patch implement GPIO LIB support for the CPM2 GPIOs.
Signed-off-by: Laurent Pinchart <[EMAIL PROTECTED]>
Cc: Jochen Friedrich <[EMAIL PROTECTED]>
---
arch/powerpc/platforms/Kconfig |2 +
arch/powerpc/sysdev/cpm2.c | 1
ers around __cpm2_setbrg.
Signed-off-by: Laurent Pinchart <[EMAIL PROTECTED]>
---
arch/powerpc/sysdev/cpm2.c | 34 +++
include/asm-powerpc/cpm2.h | 46 +++
2 files changed, 37 insertions(+), 43 deletions(-)
diff --git a/arch/power
On Wednesday 18 June 2008 17:00, Jeff Garzik wrote:
> Laurent Pinchart wrote:
> > Hi Scott,
> >
> > On Monday 16 June 2008 18:34, Scott Wood wrote:
> >> On Mon, Jun 16, 2008 at 10:57:02AM +0200, Laurent Pinchart wrote:
> >>> On Monday 26 May 2008 11:5
The restart() function is called when the link state changes and resets
multicast and promiscous settings. This patch restores those settings at the
end of restart().
Signed-off-by: Laurent Pinchart <[EMAIL PROTECTED]>
---
drivers/net/fs_enet/mac-fcc.c |3 +++
2 files chan
Hi Scott,
On Monday 16 June 2008 18:34, Scott Wood wrote:
> On Mon, Jun 16, 2008 at 10:57:02AM +0200, Laurent Pinchart wrote:
> > On Monday 26 May 2008 11:53, Laurent Pinchart wrote:
> > > Port the fs_enet driver to support the MDIO on GPIO driver for PHY
> > > ac
t; >
> > > Is their a cleaner way I should look at?
> >
> > Using the GPIO lib might be cleaner. Have a look at
> > http://www.nabble.com/-PATCH-0-2--MDIO-on-GPIO-support-for-the
> > -fs_enet-driver-ts17468958.html
> > for a patch.
> >
>
>
On Monday 26 May 2008 11:53, Laurent Pinchart wrote:
> Port the fs_enet driver to support the MDIO on GPIO driver for PHY access
> in addition to the mii-bitbang driver.
Now that 1/2 has been applied by Jeff, could this one make it to
powerpc-next ?
> Signed-off-by: Laurent Pinchar
/netdev/msg45778.html
http://www.spinics.net/lists/netdev/msg47159.html
> Is their a cleaner way I should look at?
Using the GPIO lib might be cleaner. Have a look at
http://www.nabble.com/-PATCH-0-2--MDIO-on-GPIO-support-for-the-fs_enet-driver-ts17468958.html
for a patch.
Best regards,
--
La
On Friday 13 June 2008 16:57, Anton Vorontsov wrote:
> On Fri, Jun 13, 2008 at 02:46:20PM +0200, Laurent Pinchart wrote:
> > On Friday 18 April 2008 19:16, Jochen Friedrich wrote:
> > > Based on earlier work by Laurent Pinchart.
> > >
> > > This patch implement
On Friday 18 April 2008 19:16, Jochen Friedrich wrote:
> Based on earlier work by Laurent Pinchart.
>
> This patch implement GPIO LIB support for the CPM2 GPIOs.
>
> Signed-off-by: Jochen Friedrich <[EMAIL PROTECTED]>
> Cc: Laurent Pinchart <[EMAIL PROTECTED]>
S
On Tuesday 20 May 2008 02:31, David Brownell wrote:
> On Tuesday 15 April 2008, Laurent Pinchart wrote:
> > Or maybe some kind of gpio_set_option() with flags specific to the
> > controller ? This could be used to enable open-drain outputs or internal
> > pull-ups fo
Hi David,
On Tuesday 20 May 2008 02:25, David Brownell wrote:
> On Tuesday 15 April 2008, Laurent Pinchart wrote:
> > I'm implementing flow control and modem control lines support in the
> > cpm_uart driver.
> >
> > The implementation is based on the G
e required memory node is present in the device
tree). This arguably makes sense, but adds more platform-specific code.
So, no need for a patch so far.
--
Laurent Pinchart
CSE Semaphore Belgium
Chaussee de Bruxelles, 732A
B-1410 Waterloo
Belgium
T +32 (2) 387 42 59
F +32 (2) 387 42 75
pgp3fLPl
On Wednesday 23 April 2008 14:47, Jean Delvare wrote:
> On Wed, 23 Apr 2008 14:12:37 +0200, Laurent Pinchart wrote:
> > On Wednesday 23 April 2008 13:16, Jean Delvare wrote:
> > > I still don't know exactly what happened there... I think I saw some
> > > "
Hi Jean,
On Wednesday 23 April 2008 13:16, Jean Delvare wrote:
> Hi Laurent,
>
> On Tue, 22 Apr 2008 16:11:56 +0200, Laurent Pinchart wrote:
> > Hi Jean,
> >
> > On Saturday 19 April 2008 18:43, Jochen Friedrich wrote:
> > > Jean Delvare wrote:
> > &
y LED GPIO.
> +
> + Example:
> +
> + [EMAIL PROTECTED] {
> + compatible = "linux,gpio-led";
> + linux,name = "pwr";
> + linux,brightness = <1>;
> + linux,active-low;
> + gpios = <&mcu
On Tuesday 22 April 2008 17:36, Scott Wood wrote:
> On Tue, Apr 22, 2008 at 05:21:49PM +0200, Laurent Pinchart wrote:
> > As the openfirmware + gpio + mdio driver might benefit non-powerpc
> > platforms, I plan to create a new driver (probably
> > drivers/net/phy/mdio-ofgpio
On Tuesday 22 April 2008 17:08, Scott Wood wrote:
> On Tue, Apr 22, 2008 at 10:55:06AM +0200, Laurent Pinchart wrote:
> > On Monday 21 April 2008 19:56, Scott Wood wrote:
> > > The memory-constrained platform I had in mind was 8xx, which doesn't use
> > > bitbanged
list some time ago:
>
> http://patchwork.ozlabs.org/linuxppc/patch?id=16282
> http://patchwork.ozlabs.org/linuxppc/patch?id=16283
Given that the required patches are just forward-ported versions of patches
you sent (and thus probably reviewed as well :-)), what's the best
On Monday 21 April 2008 19:56, Scott Wood wrote:
> On Fri, Apr 18, 2008 at 01:34:29PM +0200, Laurent Pinchart wrote:
> > Scott Wood was concerned in
> > http://patchwork.ozlabs.org/linuxppc/patch?id=17490 that the gpio lib
> > might be an unnecessary burden for memory-constra
chwork.ozlabs.org/linuxppc/patch?id=17833
> http://patchwork.ozlabs.org/linuxppc/patch?id=17834
>
> which are just the forward ported patches you sent to the poweprc mailing
> list some time ago:
>
> http://patchwork.ozlabs.org/linuxppc/patch?id=16282
> http://patchwork
On Wednesday 16 April 2008 18:09, Laurent Pinchart wrote:
> On Wednesday 16 April 2008 18:05, Anton Vorontsov wrote:
> > On Wed, Apr 16, 2008 at 04:40:42PM +0200, Laurent Pinchart wrote:
> > > This patch converts the MII bitband driver to use GPIO lib for GPIO
> > >
1 - 100 of 203 matches
Mail list logo
