All of lore.kernel.org
 help / color / mirror / Atom feed
From: Felipe Balbi <felipe.balbi@nokia.com>
To: ext Sebastien Jan <s-jan@ti.com>
Cc: "linux-omap@vger.kernel.org" <linux-omap@vger.kernel.org>,
	"Chinea Carlos (Nokia-D/Helsinki)" <Carlos.Chinea@nokia.com>
Subject: Re: [RFC PATCH 1/9] HSI: Low Level Driver interface
Date: Fri, 30 Oct 2009 14:49:07 +0200	[thread overview]
Message-ID: <20091030124907.GJ31472@nokia.com> (raw)
In-Reply-To: <1256896808-20152-2-git-send-email-s-jan@ti.com>

Hi,

On Fri, Oct 30, 2009 at 11:00:00AM +0100, ext Sebastien Jan wrote:
> diff --git a/drivers/Makefile b/drivers/Makefile
> index 086857c..05b4190 100644
> --- a/drivers/Makefile
> +++ b/drivers/Makefile
> @@ -111,3 +111,4 @@ obj-$(CONFIG_VLYNQ)         += vlynq/
>  obj-$(CONFIG_STAGING)          += staging/
>  obj-y                          += platform/
>  obj-y                          += ieee802154/
> +obj-$(CONFIG_OMAP_HSI)         += hsi/

not omap specific.

> diff --git a/drivers/hsi/Kconfig b/drivers/hsi/Kconfig
> new file mode 100644
> index 0000000..e10b522
> --- /dev/null
> +++ b/drivers/hsi/Kconfig
> @@ -0,0 +1,44 @@
> +#
> +# OMAP HSI driver configuration

this shouldn't be omap specific. The comment is misleading.

> diff --git a/drivers/hsi/Makefile b/drivers/hsi/Makefile
> new file mode 100644
> index 0000000..a7f579b
> --- /dev/null
> +++ b/drivers/hsi/Makefile
> @@ -0,0 +1,14 @@
> +#
> +# Makefile for HSI drivers
> +#
> +EXTRA_CFLAGS :=
> +
> +omap_hsi-objs  :=      hsi_driver.o hsi_driver_dma.o hsi_driver_int.o \
> +                       hsi_driver_if.o hsi_driver_bus.o hsi_driver_gpio.o \
> +                       hsi_driver_fifo.o

this should a more generic bus driver and it shouldn't know about how
the hardware handles e.g. reset signals.

What I suggest you to do is:

Bus Layer
hsi.ko -> MIPI HSI Bus Driver (like i2c-core.c or usbcore, etc etc)

HW Layer
hsi-omap.ko-> OMAP HSI Controller (like i2c-omap.c)

Clients Layer
any protocol driver using the HSI bus

> diff --git a/drivers/hsi/hsi_driver_if.c b/drivers/hsi/hsi_driver_if.c
> new file mode 100644
> index 0000000..fb0035d
> --- /dev/null
> +++ b/drivers/hsi/hsi_driver_if.c
> @@ -0,0 +1,657 @@
> +/*
> + * hsi_driver_if.c
> + *
> + * Implements HSI hardware driver interfaces for the upper layers.
> + *
> + * Copyright (C) 2007-2008 Nokia Corporation. All rights reserved.
> + * Copyright (C) 2009 Texas Instruments, Inc.
> + *
> + * Author: Carlos Chinea <carlos.chinea@nokia.com>
> + * Author: Sebastien JAN <s-jan@ti.com>
> + *
> + * This package is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + * THIS PACKAGE IS PROVIDED ``AS IS'' AND WITHOUT ANY EXPRESS OR
> + * IMPLIED WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED
> + * WARRANTIES OF MERCHANTIBILITY AND FITNESS FOR A PARTICULAR PURPOSE.
> + */
> +
> +#include "hsi_driver.h"

should be including something like:

#include <linux/hsi/driver.h>

or even

#include <linux/hsi.h>

> +int hsi_register_driver(struct hsi_device_driver *driver);
> +void hsi_unregister_driver(struct hsi_device_driver *driver);

> +int hsi_open(struct hsi_device *dev);
> +int hsi_write(struct hsi_device *dev, u32 *addr, unsigned int size);
> +void hsi_write_cancel(struct hsi_device *dev);
> +int hsi_read(struct hsi_device *dev, u32 *addr, unsigned int size);
> +void hsi_read_cancel(struct hsi_device *dev);
> +int hsi_poll(struct hsi_device *dev);
> +int hsi_ioctl(struct hsi_device *dev, unsigned int command, void *arg);
> +void hsi_close(struct hsi_device *dev);

are these used on some file_operations structure ?

they should be implemented by the client driver if when it needs instead
of letting the bus driver dictacte so much of the design.

> +void hsi_set_read_cb(struct hsi_device *dev,
> +               void (*read_cb)(struct hsi_device *dev, unsigned int size));
> +void hsi_set_write_cb(struct hsi_device *dev,
> +               void (*write_cb)(struct hsi_device *dev, unsigned int size));
> +void hsi_set_port_event_cb(struct hsi_device *dev,
> +                               void (*port_event_cb)(struct hsi_device *dev,
> +                                       unsigned int event, void *arg));

I wouldn't do it like this. If this is what I'm guessing, you're using
these functions to be sure when a transfer has completed like ?

I remember suggesting this to be done more like the usb gadget
framework:

struct hsi_request {
	void		*buf;
	dma_addr_t	dma;
	unsigned	length;
	unsigned	direction;

	void		(*complete)(struct hsi_device *hsi, struct
					hsi_channel *channel, struct
					hsi_request *req);
};

then, you send the data and when you get a complete irq, you call
request->complete();

maybe that would be better ??

-- 
balbi

  reply	other threads:[~2009-10-30 12:49 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-10-30  9:59 [RFC PATCH 0/9] MIPI HSI device support for OMAP platforms Sebastien Jan
2009-10-30 10:00 ` [RFC PATCH 1/9] HSI: Low Level Driver interface Sebastien Jan
2009-10-30 12:49   ` Felipe Balbi [this message]
2009-10-30 10:00 ` [RFC PATCH 2/9] HSI: Low Level Driver core Sebastien Jan
2009-10-30 12:56   ` Felipe Balbi
2009-10-30 10:00 ` [RFC PATCH 3/9] HSI: Low Level Driver device management Sebastien Jan
2009-10-30 10:00 ` [RFC PATCH 4/9] HSI: Low Level Driver debugfs support Sebastien Jan
2009-10-30 10:00 ` [RFC PATCH 5/9] HSI: Low Level Driver documentation Sebastien Jan
2009-10-30 10:00 ` [RFC PATCH 6/9] HSI: character driver interface Sebastien Jan
2009-10-30 10:00 ` [RFC PATCH 7/9] HSI: character driver low level interface Sebastien Jan
2009-10-30 10:00 ` [RFC PATCH 8/9] HSI: HSI device support Sebastien Jan
2009-10-30 10:00 ` [RFC PATCH 9/9] HSI: SSI device support and integration on 3430SDP platform Sebastien Jan
2009-10-30 12:57 ` [RFC PATCH 0/9] MIPI HSI device support for OMAP platforms Felipe Balbi
2009-10-30 14:32   ` Sebastien Jan
2009-10-30 17:58     ` Felipe Balbi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20091030124907.GJ31472@nokia.com \
    --to=felipe.balbi@nokia.com \
    --cc=Carlos.Chinea@nokia.com \
    --cc=linux-omap@vger.kernel.org \
    --cc=s-jan@ti.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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.