lkml.org 
[lkml]   [2010]   [Mar]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH v3 1/6] hid: new driver for PicoLCD device
    On Fri, 26 March 2010 Dmitry Torokhov <dmitry.torokhov@gmail.com> wrote:
    > On Friday 26 March 2010 01:59:19 pm Jiri Kosina wrote:
    > > On Fri, 26 Mar 2010, Bruno Prémont wrote:
    > > > > > + for (i = 0; i < PICOLCD_KEYS; i++) {
    > > > > > + int key = ((int *)idev->keycode)[i];
    > > > >
    > > > > Keycodes are now short, not int. Also, just do:
    > > > > input_set_capability(idev, EV_KEY, data->keycode[i]);
    > > > >
    > > > > > + if (key < KEY_MAX && key >= 0)
    > > > > > + input_set_capability(idev, EV_KEY, key);
    > > >
    > > > Oops, I was not careful enough when switching over...
    > >
    > > Dmitry, thanks a lot for rapid review the driver.
    > >
    > > Bruno, could you please fix this and submit a followup 1/6 patch, so that
    > > I could queue the driver in my tree?
    > >
    > > I have almost finished going over the driver and haven't encountered any
    > > other issues that would require immediate fixing.
    > >
    > > Still, it would be nice to have the framebuffer/LCD/backlight bits
    > > reviewed by respective subsystem maintainers. But I'll probably queue the
    > > driver nevertheless and add potential ACKs later.
    >
    > FWIW I am not entrely happy with the whole send-and_wait implementation -
    > it looks like it is not being called concurrently so we don't need mutex
    > there... I'd do something like:

    It can be called concurrently, not within patch 1/6 but it definitely
    can once patch 6/6 is applied (concurrent access to debugfs files for
    EEPROM and/or FLASH).
    Even later on when FLASH (and EEPROM) access get moved to a better home
    concurrent access will still exist.


    > send_nand_wait() {
    >
    > set_bit(WAITING_RESPONSE, data->state);
    > prepare message
    > send message
    > wait_for_event_interruptible_timeout(&data->wait,
    > !test_bit(WAITING_RESPONSE, data->state));
    > if (!test_bit()) {
    > process
    > return 0;
    > }
    >
    > return -ETIME;
    > }
    >
    > irq(...) {
    >
    > else if (test_bit(WAITING_RESPONSE, data->state)) {
    > copy response...
    > clear_bit(WAITING_RESPONSE, data->state);
    > wake_up(&data->wait);
    > }
    > }
    >
    > and not bother with kmallocing pending structure, but it should not
    > stop from merging driver.

    It might be an option to not allocate the pending structure but as
    the whole "pending" access is definitely not a hot path (flashing
    firmware or splash and changing EEPROM values will most probably
    not be done very often). The only more common use is version check
    on probe.

    So what is more expensive, the used memory or the CPU usage to
    allocate/release the struct? That probably depends on reader's taste.

    Bruno
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2010-03-26 22:43    [W:3.235 / U:0.724 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site